Re: [OT?] Replacing hacked binaries
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(peter@llama.nslug. , 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
Reply to: