19

Tripwire type intrusion detection systems supposedly protect your system from rootkits, by monitoring the checksums of important binaries for changes.

Let's say I have tripwire configured to run nightly and installed it on a fresh non-rootkitted system.
Then at noon today a skilled intruder installs a rootkit to my system.

How do I know their rootkit hasn't replaced my tripwire with a tripwire impersonator; using a different set of public/private keys (and fake authentication binaries) that more or less replays the last files (readable with public key) to assure me that no checksums are changing (essentially just replaying known log files). I guess I could notice that my private passphrase no longer works to open the private key; but I don't think it would be that difficult to let any password work (or just the first one typed in). I guess I should be checking the file sizes/shasum/md5sum of tripwire with known values, but on my rootkitted system all those utilities could be compromised.

I'm looking at the documentation from http://sourceforge.net/projects/tripwire/files/tripwire-src/2.3.0-docs-pdf/ and don't see how tripwire provides any extra security -- besides making the rootkit developers have to work a little harder (to mimic one extra utility as configured by the user).

In practice, I doubt I'd ever routinely boot off a live cd to check hashes safely; so I am wondering if it provides any safety or if its just security theater.

Improve this question
1
  • 2
    Interesting conversation on this at antionline.com/archive/index.php/t-250279.html. TLDR is "Tripwire etc, detects changes in files. A kernel-based rootkit is capable to masking those changes, to make the files appear unchanged, thus defeating Tripwire." Maybe a more apt question is, are there any rootkits already out there that defeat tripwire?
    – Mark E. Haase
    Commented Aug 15, 2012 at 1:15

7 Answers 7

Reset to default
17

I think there's something to be said for setting a bar, regardless of how low it is. Can Tripwire be bypassed? Sure. Will it catch things that you wouldn't otherwise? Yes it will.

The main problem I've seen in a Tripwire installation is tuning it to where it isn't false-positive laden to the point of ignoring it. If it blows up every time someone changes something in their home dir, you'll ignore it. If it blows up every time your web people change your site, you'll ignore it. If it blows up every time someone upgrades a package... you get it. However, if you've got a good workflow around it where it only complains when something abnormal is happening, you'll pay attention to it, and that certainly has value.

Improve this answer
1
  • There is something to be said about having a idea of where the bar is, too. (I am even not mentioning the potential illusion of security, I don't think it is important here.)
    – curiousguy
    Commented Aug 19, 2012 at 17:10
9

Tripwires are very useful for defending against userland rootkits. Kernelland rookits do not need to replace binaries to subvert the behavior of the system, usually these rootkits are just a Linux Kernel Module (LKM). In fact when you control the kernel like this any executable's behavior can be influenced without needing to modify the binary its self. (Although this usually isn't needed).

Kerneland rootkits for Linux are very uncommon these days as kernel devs are quick to patch these vulnerabilities. I am sure someone has an 0-day Linux kernel rootkit, but you are more likely to encounter a userland rootkit in the wild.

The most recent Linux rootkit Kbeast which was released in 2012 and affects up to Linux 2.6.32 (released in 2009), current at the time of writing the latest version is 2.6.39. I don't know how many of you really appreciate this event because the last LKM rootkit was the Eyne LKM rookit released in 2009. Needless to say such attacks are few and far between.

Improve this answer
14
  • 5
    Kernel rootkits can install through means other than vulnerabilities. Sure, you need the root password; but most non-programmer users cough that up without looking at who's asking.
    – Billy ONeal
    Commented Jan 4, 2012 at 2:34
  • 9
    A rootkit is not a vulnerability. It is not an attack. It is merely a driver using it's privileges (as ring 0 code) to modify the memory structures of the kernel. Nothing the kernel can do can prevent such modification, because a malicious kernel module is around pulling the strings.
    – Billy ONeal
    Commented Jan 4, 2012 at 8:28
  • 2
    @Rook I think you may be confusing rootkits and exploits/vulnerabilities. As Billy ONeal stated above a (kernel-mode) rootkit is a Kernel Module that modifies memory structures. It is not used to gain access, it is implanted on the system after some exploit has been used to gain access. Another way to put it is the rootkit is the payload, not the exploit. As such, there is nothing to "patch"; LKM's ability to modify memory is a core part of how linux works.
    – devnul3
    Commented Jan 4, 2012 at 16:00
  • 2
    This discussion seems very interesting and I am curious to see some sort of resolution. Blunders asked a spin-off question on this, which may be a better place to discuss. I'm specifically wondering as to whether the linux kernel has any security features that prevent (kernel/ring-0) rootkits from being installed by someone who has acquired root; at least on a live system by a remote user.
    – dr jimbob
    Commented Jan 4, 2012 at 17:01
  • 2
    @Rook: I'm not intimately familiar with the Linux Kernel to the point to be able to point out specific rootkits. Yes, vulnerabilities are uncommon in the kernel. But this isn't a vulnerability. Once a driver (or kernel module) is running, it runs with the highest privilege level available on the CPU. Period. No operating system can enforce checks on code running in kernel mode on the processor. This is one of the reasons most of the Unix community places so much value on running in usermode. Here is a list of kernel rootkits I found though.
    – Billy ONeal
    Commented Jan 4, 2012 at 18:07
7

In addition to the answers from Rook and Jeff, Tripwire and similar solutions also have real time alerting value. To subvert a Tripwire system that is also monitoring its own files you need to prevent it alerting during the subversion process.

Not as straightforward an attack any more.

So in summary - you can get around any controls given enough time/effort/skill etc but Tripwire helps make it much more difficult for an attacker.

Improve this answer
2
  • 2
    Do typical configurations of tripwire compute hashes of files on a scale where installation of a rootkit would be noticed (where an installation may take minutes)? I was under the impression the hash of any particular file would be checked at most hourly; but more likely daily/weekly.
    – dr jimbob
    Commented Jan 4, 2012 at 17:03
  • 1
    I have seen many installations check real-time (or as close to it as to make the delay unnoticable) - it depends how widespread your Tripwire needs to be. If you are monitoring millions of files you can't do this.
    – Rory Alsop ♦
    Commented Jan 4, 2012 at 17:28
3

As Rook said, Tripwire does help for userland compromises. It also requires that some kernel attacks factor this detection method in, raising the bar a bit. We see plenty of cases here where websites are compromised, but likely not entire systems. Tripwire would provide a method of detection and faster recovery there as well.

Offline comparisons are the most reliable detection methods, but online comparisons are a great tool in the collection of things that help make one secure.

Improve this answer
1
  • 1
    "does help for userland compromises" - but only if the rootkit runs as a non-root user.
    – D.W.
    Commented Feb 6, 2012 at 7:25
1

As an experiment I installed tripwire and then installed a rootkit (KBeast) to see if tripwire would catch it. In fact, tripwire does complain:

-------------------------------------------------------------------------------
# Section: Unix File System
-------------------------------------------------------------------------------

-------------------------------------------------------------------------------
Rule Name: Other configuration files (/etc)
Severity Level: 66
-------------------------------------------------------------------------------

Modified:
"/etc"
"/etc/resolv.conf"

-------------------------------------------------------------------------------
Rule Name: Devices & Kernel information (/dev)
Severity Level: 100
-------------------------------------------------------------------------------

Modified:
"/dev/.udev/queue.bin"

The modified /etc/resolv.conf isn't very suspicious (it's easy to check) but the queue.bin is conspicuous:

mhaase@debian:~$ cat /dev/.udev/queue.bin
??9/devices/pci0000:00/0000:00:11.0/0000:02:02.0/sound/card0??/devices/virtual/v
c/vcs2?/devices/virtual/vc/vcsa2???/devices/virtual/vc/vcs3?/devices/virtual/vc/
vcsa3???/devices/virtual/vc/vcs4?/devices/virtual/vc/vcsa4???/devices/virtual/vc
/vcs5?/devices/virtual/vc/vcsa5???/devices/virtual/vc/vcs6?/devices/virtual/vc/v
csa6???I/devices/pci0000:00/0000:00:10.0/host2/target2:0:0/2:0:0:0/block/sda/sda
1??/module/loop??/devices/virtual/block/loop0?/devices/virtual/bdi/7:0??/devices
/virtual/block/loop1?/devices/virtual/bdi/7:1??/devices/virtual/block/loop2?/dev
ices/virtual/bdi/7:2??/devices/virtual/block/loop3?/devices/virtual/bdi/7:3??/de
vices/virtual/block/loop4?/devices/virtual/bdi/7:4??/devices/virtual/block/loop5
?/devices/virtual/bdi/7:5??/devices/virtual/block/loop6?/devices/virtual/bdi/7:6
??/devices/virtual/block/loop7?/devices/virtual/bdi/7:7??????????/module/ipsecs_
kbeast_v1?

This is a pretty effective warning. I'm sure there are other root kits out there that are better at evading detection, and I'm sure a more skilled attacker could configure KBeast to be more evasive, but I think this is a good indication that Tripwire definitely complicates the attacker's job and raises the bar at least a little bit.

Improve this answer
1
  • Wait, the string "kbeast" actually shows up inside queue.bin? Makes me wonder if you could just grep your machine for the string "kbeast" to search for this rootkit?
    – Kellen Stuart
    Commented Nov 1, 2016 at 15:02
0

I think the value of security monitors is more that they are part of a process that leads to better security practices. If a tripwire alerts you to an actual intrusion, you've already lost the game. You would have figured that out, sooner or later, so the benefit is marginal. On the other hand, if a monitor alerts you to an actual attack that was unsuccessful, or a false positive due to a security practice that is questionable, you're on notice to check your software and improve your practices.

Improve this answer
-3

My experience in dealing with rootkits compromising security is the user placing it in the master boot record of the drive. Another misconception that needs to be addressed is that the firewall itself provides zero security for the host system. A firewalls primary function is to direct traffic. So that means there is less than zero security for the files that manage the firewall itself. Remember there will always be backdoors and blank passwords. The most clever rootkits I have seen have an encrypted partition in the swap space, identified as .gvfs for the folder. On a windows machine go to the folder options in the control panel and select show hidden files and folders. Go to the c:\ and check for hidden .DAT files that are roughly the same size as the pagefile.sys cache file.

Improve this answer
1
  • 4
    Shawn - most of those statements are provably untrue. Quick examples: Rootkits are usually not placed by the user, but inserted by an attacker. Firewall config files are usually well segregated from traffic through the firewall. Backdoors and blank passwords - sometimes, but generally these are found and rectified...
    – Rory Alsop ♦
    Commented Feb 6, 2012 at 9:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .