[vox-tech] Verify Ubuntu files

[Bill Broadley]

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.