Brian Lavender wrote: > Is there a way to verify the integrity of binary files in an Ubuntu > system? I just back from Defcon and I was wondering if I can inventory > installed packages to make sure they are still the same. > > brian
Sorry for the delay, you might want to see the lugod talk I gave awhile back on CDR, Checksums Done Right. In any case binary rootkits are getting exceedingly rare, I had problems finding ones current enough to be practical, most of the recent work involves hacking the kernel, there are tons of actively maintained kernel hacks for linux, openbsd, solaris, windows and other OSs. They can use insmod, /dev/kmem, /dev/mem, hacking the filesystem kernel image, and piggy back on existing modules. So local tripwire, local package database, or even a remote network mount is basically useless. If you find anything it's likely just a distraction to help hide the serious stuff. Booting known good media is much better, although even then it's pretty trivial to subvert. CDR basically takes a centos/ubuntu mirror, loads every package, and builds a database out of all the md5/sha sums. That way you can query ANY binary. So basically if you feed every binary into it you have a decent chance of finding trojans. So even if /bin/login is valid, /bin/.hacked/login that is run in it's place once an evil module is loaded will show up as a package that isn't in the database. Of course you have to run a trusted kernel/boot media to have any chance of finding /bin/.hacked. One sneaky way to do this is check integrity from the dom0 and run your OS in a domU, so even if the domU is hacked it's impossible to lie to the dom0. Of course it's relatively trivial to hack a machine, not change a single binary, and open up a back door. In a intrusion detection and recovery class I taught I just copied /etc/ssh to /etc/ssh2 and added a config line entry for a different authorized key for root. Then I added a kernel module to hide processes, and then used a ubuntu supplied port knocker to launch a backdoor on demand (thus hiding from lsof, nmap, and related). Pretty easy/trivial stuff, wasn't particularly easy to find, and if I was more serious it would have been much harder. Auditing the boot process, every line of script, every binary is tough, and not every file on the files system is in the package database. One nice thing about CDR is that it auto updates, every patch happens securely, much better than running tripwire locally where step #3 for hackign a system is to find tripwire and include your backdoors when it's run so that the next time the admin runs a patch and approves 500 file update that the backdoor will be included. Assuming you took reasonable precautions, maintained physical security and had zero or just ssh port open you should be fine. Ideally with ssh not allowing root logins and not allowing passwords for users (only certificates). Of course assume every packet to the internet is sniffed, assume the DNS servers are lying to ya, and assume that any non-ssl content (like say packets to/from most web mail/rss feed reader/etc) is spoofed/malicious, etc. So with all that said, probably best to backup just what you need, i.e. ~ except for select known audited dot files, and select audited files from /etc so you can pick and choose. Anything less and if someone tried to hide it's damn hard to tell. Even installing from CD can be subverted if you are tricked into installing into a virtual machine. My talk referenced and attack where a machine that was running on the hardware is virtualized, then the hacker is free to setup his own custom unmonitored environment thats effectively invisible to the guest OS. _______________________________________________ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
