Security Incidents mailing list archives
Recovering from a penetrator, the easy way
From: "Harrington, Perry" <pedward () WEBCOM COM>
Date: Tue, 10 Oct 2000 14:12:50 -0700
Hi all, I must confess that I recently had a home machine compromised. It was part my fault, and others. It was simply a box the hosts my personal web pages and some email. I noticed that it was hosed when I couldn't ping it from my inside network. It turns out that the cracker (orangehaw) had created an alias interface for every ip on my network. However I have a /29, and he created one for a /24, which didn't make it much happy. It didn't affect my ability to ssh into the box. First, I did a find of the drive, with -ls, to get a listing of the files. Installed was the t0rnkit, a sniffer and rogue sshd. He also left wuftpd-god on the box, of which I was not susceptible. He got into my box using an account that was vestigial from a previous machine I migrated to that box. It turns out he got root though old NFS utils. The purpose of my message is to detail how I found his 'updated' programs and how to replace them. First, there are 2 utils in RH that are really handy: find and stat. stat is a program that does a stat() for each file given and prints out the information. stat() returns 3 different times for each file, atime (last accessed), mtime (last modified), and ctime (last changed, or creation time). The atime and mtime are modifiable using touch or utime(). The ctime is not changable in userspace, because it's a function of the filesystem. It's this field that I used to track down the files. First, I ran 'stat' against all the important utilites, and found that these had been replaced: ifconfig ls ps netstat find nscd (rogue, didn't have it installed) inetd I renamed all of them and downloaded known good versions from another box. His version of ls, ps, find, and netstat were to hide his rootkit, ip addrs, and utils, in /usr/src. The find command is very helpful to locate rogue files, you specify a -ctime with the number of days since the breakin, it will print out all the files that have a ctime within that 24 hour period. I used this to pick up all his leftovers. This whole message is born out of the neccessity I had to keep the machine online and not reinstall the OS. If you know the breakin time and catch it soon enough, this will help you find the files. Now, this method is not without a couple of holes. You can modify the ctime of a file by directly modifying the filesystem internals, this requires a remount readonly to do, but it's possible. Also, It might work if you reset the system time every time you update a file, just before creation, this will have other affects to the system, so it can be tracked. On the latter, perhaps we really need a secure way to ensure the system time isn't mucked with, or use something like the 'timestamp' in Sybase; it doesn't fluctuate with the system time, it's an always incrementing timestamp. This method is used by programs that do journalling, perhaps the ext3 journalling extension does this too? --Perry PS, Orangehaw, I had that machine rate limited to 64Kbps on aDSL, why where you trying to launch a DDoS on it? Stachel. Grr. -- Perry Harrington Director of zelur xuniL () perry () webcom com System Architecture Think Blue. /\
Current thread:
- Recovering from a penetrator, the easy way Harrington, Perry (Oct 11)
- Re: Recovering from a penetrator, the easy way Dave Dittrich (Oct 12)