[plug] TCP connections refused [rootkit]

[Craig Foster]

Ryan wrote:
> 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

Sounds a little more like ELF/Osf.8751 or Linux.Jac.8759.
Apache/SSL chunked to drop this sucker suid.
Although this server had all of /var/log removed....

I have this perverse little program tarballed away on the Windows PC.
Nortons doesn't like it, and wont save it to the samba share. (although
the server will quarantine it too)

PS I have a recent chrootkit compiled on a clean PC, and saved in a
/Utils directory on a custom RedHat CD. Comes in quite handy in times
like this...

Regards,

Craig Foster
fostware at iinet.net.au (with SMIME)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3238 bytes
Desc: not available
URL: <http://lists.plug.org.au/pipermail/plug/attachments/20030505/acf1cb2e/attachment.bin>