Re: [vox-tech] Verify Ubuntu files
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [vox-tech] Verify Ubuntu files
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.
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
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