[vox-tech] Verify Ubuntu files

[Brian Lavender]

Thanks for the detailed analysis. I found your writeup. I am going to
have to take a closer look at it.

http://www.lugod.org/presentations/virt-lugod.pdf

There is a broken link to it on the website.
http://www.lugod.org/meeting/past/

It has the link as follows. Maybe Bill can fix it?

http://www.lugod.org/preentations/virt-lugod.pdf

It sounds like the reason that manufacturers turn on the vmx instruction
set in the BIOS is probably for this exact reason. My server at work and
my laptop had it turned off by Default.

Next year perhaps I will take in a few vulnerable VMs with some
vulnerabilities and see if I can detect someone cracking them. :)

brian

On Wed, Aug 13, 2008 at 12:43:11AM -0700, Bill Broadley wrote:
> 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
> vox-tech at lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech

-- 
Brian Lavender
http://www.brie.com/brian/