[plug] TCP connections refused [rootkit]

[Ryan]

On Thu, 2003-04-17 at 11:05, Craig Ringer wrote:
> >> Anybody have any idea what it could be doing based on the basic info
> >> I've given?  It is a remote machine, and I can't connect to it any time
> >> soon to see what is going on.
> 
> >> I'm guessing some dodgy RAM or something, has anyone seen this behaviour
> >> before and could put a different slant on it?  There are no IDS things
> >> running on it.
> 
> If something kills userland, but the kernel keeps running OK, you can 
> get behaviour like that.
> 
> > I had a machine here do a similar thing where the kernel "died" with an 
> > oops. This stopped ALL userland programs from running, and thus 
> > accepting connections, but the in-kernel stuff like NAT and normal 
> > routing continued along quite happily.
> 
> Yep. Kernel oops-es but doesn't do a full panic causing a system halt. 
> The kernel keeps on NATing packets etc but userland doesn't respond at 
> at all. However, the fact that it still responds to UDP queries is 
> interesting, as it suggests that /something/ is alive in there.
> 
> I've also had disk failures do this - things like apache and sshd that 
> look at the disk die, but anything running in RAM only just keeps on 
> plodding, including xinetd, bind, etc. Could it be that your HDD is 
> going dogdy?

Okay, I finally got this hard drive back from its remote home.  It was a r00t kit of some sort.  

The symptoms again so you might recognise it in the future were:

 - Booted up fine
 - External ports, (except ftp and mail *sometimes*) refused all connections.
 - Logging in to FTP showed all the files, but any attempt to download
   and of them resulted in file not found.
 - No obvious increase in traffic
 - Port 2415 opened for SSH, port 22 service killed.
 - SNMP still worked as if nothing was wrong
 - All internal interfaces taken down and set to promiscuous (maybe it used the routing 
   table to try and determine which interfaces were local - the box had 3 NICs, one for 
   an ISDN router, the rest for the LAN.  It didn't take down the interface that was 
   gatewayed to the ISDN router.
 
The culprit appears to be from: *.icafe.bacau.rdsnet.ro.  That makes it the Romanian kit right? :) 
This is from a few connection logs in syslog.  I guess it didn't clean up after itself as well as 
it should have.  The system is too screwed to install chkrootkit and I can't be bothered fixing it
all to install it and confirm what I already know.

I suspect it was proftpd that opened the door, it had 1.2.5-rc1 on there.  Funnily
enough this version seems to have come from security.debian.org on March 15 2003, even though 
1.2.5-final was released mid 2002.  From the looks of the proftpd homepage it is a lost 
cause and they have stopped updating it?  For the record, proftpd was installed on there 
2 days before to test some things and was left running.  That won't happen again :)

Anyway, the exploit did the usual and replaced a whole bunch of stuff in /bin, changed the
root password, zeroed the ftp and mail logs, diverted /var/messages and /var/wtmp to 
/dev/null, set all the internal interfaces to promiscuous mode, and spawned all manner of 
things under the process name sp0.

I'm still having an interesting time looking at what else it did.  It has it's very own config file
and ssh backdoor on port 2415.  If the hard drive is mounted on another Linux machine as the non
primary disk, nothing can be read from it, fsck checks out fine on 5 pass runs, but the data can
only be seen if the drive is booted on its own accord.  Once it does, the hard drive is fine, all
data is accessible and if you were not on console and ssh hadn't been disabled, you'd never know as
you wouldn't see the hundreds of eth0 promiscuous messages on the console after every command you 
type.

Out of interest, has anyone else seen this root kit and know what else it does?  I'll have a better
play later on for myself and suss it out a bit more.  Could it have arrived via any other means 
than proftpd?

Ryan