18

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.

dr jimbob
  • 38,768
  • 8
  • 92
  • 161
  • 2
    Interesting conversation on this at http://www.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 Aug 15 '12 at 01:15

7 Answers7

16

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.

Bill Weiss
  • 777
  • 3
  • 15
  • 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 Aug 19 '12 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.

rook
  • 46,916
  • 10
  • 92
  • 181
  • 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 Jan 04 '12 at 02:34
  • @Billy ONeal Maybe for another kernel, but not under Linux. Any kerneland rootkit would be taken very seriously and patched and issued a CVE. Although this is a more recent development, I admit Linux devs didn't take this attack seriously for long time. – rook Jan 04 '12 at 08:01
  • 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 Jan 04 '12 at 08:28
  • @Billy ONeal link me to a Linux Rootkit I can install on 2.6.38. I am not saying you are wrong, I am saying that I can't do this on my system because I don't know how. As far as I am aware these vulnerabilities are very uncommon. – rook Jan 04 '12 at 08:47
  • 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 Jan 04 '12 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](http://security.stackexchange.com/questions/10369/what-is-a-rootkit), 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 Jan 04 '12 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](http://www.la-samhna.de/library/rootkits/list.html). – Billy ONeal Jan 04 '12 at 18:07
  • @Billy ONeal You are mistaken. That is the old view of the LKM api. A lot has changed, you can't simply subvert any function call anymore. And look at you now! You are spreading incorrect information and linking me to exploits that are more than 5 years old. – rook Jan 04 '12 at 18:39
  • @devnul3 Prove it. Link me to a rootkit that i can install on 2.6.38. No one has provided any proof of their speculation on this comment thread. – rook Jan 04 '12 at 18:41
  • 1
    What changes do you think were made in your version of the Kernel that prevent arbitrary kernel modules from being loaded by root? – devnul3 Jan 04 '12 at 19:48
  • @devnul3 I never said that. The LKM API has changed to limit what functions can be hooked and that is why no one has written a linux rootkit in 3 years. – rook Jan 04 '12 at 19:50
  • 2
    @Rook: This is not an API issue. This is a processor issue. Rootkits work by modifying kernel memory structures that are not exposed by any API. – Billy ONeal Jan 04 '12 at 19:58
  • 1
    It's not an API. It's direct access to memory. If you can find the system call table, you can override it to do anything you want when those system functions are called. Since you seem to be hung up on dates and new versions, here you go! http://www.zyztematik.com/?p=65 – devnul3 Jan 05 '12 at 03:21
  • 1
    @Rook a lot of rootkits exist and have been written during the last 2 years - using new techniques too. They are just not public. Well known rootkits (e.g. phalanx) are still being developed and there are new (private) versions. Also various kinds of debug register rootkits are also used. All of those install even at the very latest kernel versions. – john Feb 06 '12 at 00:27
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.

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
  • 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 Jan 04 '12 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 Jan 04 '12 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.

Jeff Ferland
  • 38,090
  • 9
  • 93
  • 171
  • 1
    "does help for userland compromises" - but only if the rootkit runs as a non-root user. – D.W. Feb 06 '12 at 07: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.

Mark E. Haase
  • 1,902
  • 2
  • 15
  • 24
  • 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 Nov 01 '16 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.

ddyer
  • 1,974
  • 1
  • 12
  • 20
-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.

Shawn Knight
  • 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 Feb 06 '12 at 09:21