On Thu, Nov 30, 2000 at 11:38:09PM -0600, Michael Janssen (CS/MATH stud.) wrote: > > Hi! > > I was wondering, in my thought ramblings, if there was a easy way to > replace ALL binaries that are in a installed package with their > (hoprfully) original states. i.e. If a machine was to fall victim to > a rootkit attack, how could I effectively re-install all the "debian > original" binaries to de-rootkit it?
As others have said, you really should re-install if an attacker gets root. If you don't, you'll have to find a way to replace the files on your system without placing any trust in any of them until they have been verified. This includes the kernel image and modules, and lots of config files, as well as binaries and libraries. Anyway, it's nasty. You'd probably need to boot from a trusted floppy, etc. OTOH, if you tried something that didn't work (hdparm, in my case, since the W83769F IDE controller isn't known to the kernel :-(, and corrupted your filesystem, then you can assume that any modified files will be not be trojan, but simply broken. This can be different for config files, and they're harder to restore as well. Make sure you have backups of /etc (and /home, of course). The rest of the system is usually programmatically verifiable (except /usr/local and /usr/src/linux/.config, and a lot of other stuff that I'm forgetting about...). Most debian packages (but not all by any means) keep md5sums of their files in /var/lib/dpkg/info/*.md5sums. I verified the md5sums of packages that had them by doing: cd / for i in /var/lib/dpkg/info/*.md5sums do if ! md5sum -c $i;then echo $i;fi;done > /root/badmd5.pkg apt-get --reinstall install $(sed -e 'sX^/.*/XX' -e 's/\.md5sums$//' badmd5.pkg ) (something like that, I pulled that out of my .bash_history) If you got random data written to inodes, you can find files that got messed up by doing find / -nouid -o -nogid | xargs ls -l, then | xargs rm, since it's likely that a random UID and GID won't match anything in /etc/passwd or /etc/group. Some of the files had gotten their immutable ext2 attribute set, so unlink() wouldn't work. For a few of the files like that, the inodes listed a file size so big the kernel refused to open() it (on my IA32). This wouldn't be a problem, except that chattr has to open() the file to ioctl() it to change the attributes! Fortunately, there is a way out of this mess. Unmount the filesystem (or mount it read-only if it is the root), and run debugfs on it. Run fsck after using it to delete the offending files. (If it was the root FS, reboot right away. The kernel doesn't like having its block devices changed underneath its feet. Make sure you come up in single user mode, since the filesystem will probably be marked clean, but you want to fsck it before full system boot.) You'll probably want to do this step _before_ checking md5sums, actually, since then the md5sum check will catch packages that had files removed from this. To verify the existence of all the files in all the packages, but not necessarily their contents, check the *.list files. for i in /var/lib/dpkg/info/*.list; do if ! \ls -dfnN $(<$i) > /dev/null;then echo $i ;fi ;done | less (BTW, I found that tetex-base.list and tetex-extra.list are too long for ls's command line. Check any packages you get arg list too long for separately.) Use a similar apt-get $(sed ...) construct to reinstall broken packages. The options on ls are to make it not do anything more than verify existence. (it uses lstat). I use \ls so bash doesn't alias expand it. (I think my system was trying to tell me something, since one of the missing files is /sbin/hdparm itself :) Happy hacking, -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE
