[vox-tech] Verify Ubuntu files

[Bill Broadley]

To avoid an exponential explosion in the length of the message I'm going to 
try to explain a few ideas that might avoid many of the line by line Q&A.

When a hacker gets control of your machine it's usually because of a trust 
relationship (i.e. keylogged password, shoulder surfing, guess password) or a 
buffer overflow.  At that point if it's root or can be escalated to root the 
hacker then controls the machine.  Often the buffer overlow leaves no obvious 
logs.  This does not require any file to be changed and allows the kernel to 
be hacked.

Granted, if the hacker changes no files, then anything in memory will be wiped 
on reboot... but at that point the original exploit still exists, there is no 
need for a backdoor... yet.  So the hacker can just reactivate the tweak of 
memory occasionally.

The available kernel rootkits are very invasive, they can hide files, 
processes, network connections, even parts of files.  Of course rebooting
trusted media exposes these files.  So if one needs to be sneaky and doesn't 
just want to setup a warez site but say setup the theft of social security 
numbers, passwords, and credit card numbers for the long term they would 
instrument the system so that when you run yum upgrade, apt-get upgrade,
or related that the system ends up writing compromised binaries/kernel modules 
to the filesystem.

So the question is, how do you get the 1000's of file chances per month 
securely to tripwire?

Sure old school attacks were obvious, often disks filled with porn or warez,
was more about a hackers ego than some malicious intelligent attack.  Things 
often broke because script kiddies replaced system binaries with incompatible 
trojanned binaries.  These days it's a completely different story, the kernel 
hacks seem to be the default, and the threat from organized crime that wants 
to steal identities, credit cards, or even blackmail users for their own data 
is more common.  These attacks are much harder to detect, and even a rather 
conscientious system admin may well not notice.  Instead of filled disks and a 
zillion network clients saturating the link it might just be a compressed and 
encrypted blob that uploads a payload to a blackhat once a day/week/month.

I've taught a lab at the security symposium twice, completely compromised the 
systems in numerous ways and it was shockingly easy to hide from the rootkit 
scanners, lsof, ps, and friends.  I had to resort to oldschool hacks like 
trojanning system binaries before people started catching on.  Basically in 
99% of cases once you are hacked it's too late.  I'd like to think that the 
folks that attended the Security Symposium were more security conscious than 
the average admin.  Plenty of folks disagreed with me before my lab, and none 
after.  Not that it's theoretically impossible, just that it's not practical.

After all from what little I can tell warez/porn/movies on compromized 
machines isn't particularly popular anymore, usually just handled in private 
networks or torrents.

So while it's possible to recover, especially if you prepared BEFORE the 
compromise with todays churn rates, huge filesystems, zillions of packages, 
rather complex layers of security (apparmor, selinux, kernel modules, ACLs, 
unix security) that it's really for a hacker to hide in the normal noise of
a system.  While it's true nothing survives a reboot that isn't on the 
filesystem IMO for 99% of sysadmins tripwire is not a practical way to detect 
or recover from a compromise.

CDR makes that much more practical because there is no longer churn to worry 
about, from a LVM snapshot or a boot from a secure media you can scan for 
every binary and file that is part of a valid package.  So with CDR the diff 
from a secure/valid system is radically smaller than tripwire (which is every 
patch and package install) so it's dramatically more practical to audit the 
changes.

In a quick check of some august patches it looks like 1000's of files of 
changed so far (for just the packages I have installed on my home desktop).

On, on the successful tweak... I've never maliciously compromised a system,
I've tracked down many hacked system, and even hacker who had compromised
the kernel.  But the successful tweak in my case was something along the lines
insmod floppy.ko, if I had really wanted to be secretive I would have turn off 
shell history, remove my history, make a ram disk, mount it, transfer a binary 
called floppy.ko, insmoding it, and then set a trap for disk/tripwire updates 
to make my hack permanent.  Then I hid the mount, started a port knocker 
pointed at a config file on the ramdisk.  The portknocker would start an sshd 
on request pointing at a config file on the ramdisk.  Then to make it 
completely obvious I had a random site on the internet login as root, touch a 
file and then asked the class to see if they could track it down.

Many downloaded "trusted" binaries that were statically linked.... it didn't 
help of course.  I'm not sure I can find it, but there's a pretty common 
document floating around the hacker sites that basically goes over the 10-15
things to do when you compromise the host, covering log cleaning (if local),
history cleaning (again if local), hiding files, and of course not making your 
filesystem changes permanent until one of two things happens, the sysadmin
patches/updates, or the sysadmin updates his tripwire database.  In the 
meantime tripwire is just given the old version of executable if they are 
foolish enough to run tripwire on the compromised system.

The only way I see to protect against it is to reboot and patch and tripwire 
only from secure media, ideally without a net connection.

As for ranum's patching, I'm curious about what he's running.  I guess I can't 
imagine my world of managing lots of unix systems without running sshd.  Sure
minimizing network facing services is great.  But if you run many servers, 
service, and *gasp* have users you end up setting up complicate environments.
Sure I don't spend much time patching because apt-get update, apt-get upgrade
doesn't take long especially with a local mirror (which I have).... but that's
because I trust that the system I am on is already secure.  If I tried to use
tripwire I couldn't do that... and the thing I would be doing wrong if I'm
spending significant amounts of time patching would be using tripwire.

Hmm, I had hoped this would be much shorter... well hopefully it's at least a 
little easier to read then a long point/counter point discussion.