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