5 ms·

There’s a rootkit in the closet

127 points by posthumangr 17y ago

barrkel 17y ago
If this style of interception becomes popular, it seems to argue for a statically linked busybox or similar that uses syscalls directly.
- colonelxc 17y ago
  The nice thing about this method is that you don't have to muck about in the kernel with a kernel module or anything like that. Also, you don't have to replace any binaries on the system, so everything _looks_ fine to an md5 comparison. Also, if you've setup something like tripwire to only watch specific configuration files and services, it might not catch the newly created /etc/ld.so.preload file. Some programs (such as login), are already statically compiled to prevent this exact thing from happening.
  - viraptor 17y ago
    I think that the default tripwire config (and definitely the default samhain config) includes monitoring new files in /etc, so at least there's that protection. Unfortunately not many people use those applications in real deployments.
  - joeyh 17y ago
    Hmm, I have not encountered a suid login. Since login runs passwd, and passwd uses pam, and pam is heavily based on demand-loaded libraries, that would be rather hard and big. Static shell? Sure, sash. Also helpful when ldso or libc is busted via non-rootkit means.
- jrockway 17y ago
  He was able to find it for this reason; ldd is statically-linked: $ ldd `which ldd` not a dynamic executable But if you audit your /etc files or the list of files in the executable directory of your web app, you also would have noticed this. It's not really undetectable, as it doesn't hide itself or the things it needs to run at all. More people check /etc once in a while than check the md5sums of their binaries.
  - CUViper 17y ago
    It's not a static binary either, it's a script: $ file `which ldd` /usr/bin/ldd: Bourne-Again shell script text executable It's also worth reading up on LD_TRACE_LOADED_OBJECTS and the possible exploits therein, e.g. http://news.ycombinator.com/item?id=902958 http://news.ycombinator.com/item?id=902958 If the attacker were a little more clever, they could have faked bogus ldd output too.
  - barrkel 17y ago
    Running ldd can also invoke arbitrary code: http://www.catonmat.net/blog/ldd-arbitrary-code-execution/ http://www.catonmat.net/blog/ldd-arbitrary-code-execution/
ratsbane 17y ago
Upvoted both for the content and expository writing style. He did a nice job not just of solving the problem but also showing how he did it.
deleted 17y ago
[deleted]
vog 17y ago
There’s something that puzzles me. The author found a rootkit and saw that it was integrated very deeply in the system. Yet he tried to fix the system from within! Only after some failed attempts to download and install a new kernel, he finally did the Right Thing and shut down the server to analyze the hard disk from outside. To everyone who encounters such a rootkit, I strongly recommend to skip this second step. If you see such a deeply integrated rootkit, shut down the computer immediately! No fiddling! Then, take out the hard disk and copy and analyze it as described in the article. Otherwise, you’d enable the rootkit to hide its traces, and to maybe destroy some data. You don’t learn anything from that fiddling. Satisfy your curiosity only after perpetuating evidence! (i.e. after copying the hard disk’s data)
iman 17y ago
It's often said that privilege escalation under Linux is very easy. Why is Linux so insecure in this aspect? Why does OpenBSD not suffer from local root exploits?

127 points by posthumangr 17y ago

If this style of interception becomes popular, it seems to argue for a statically linked busybox or similar that uses syscalls directly.

colonelxc 17y ago
The nice thing about this method is that you don't have to muck about in the kernel with a kernel module or anything like that. Also, you don't have to replace any binaries on the system, so everything _looks_ fine to an md5 comparison. Also, if you've setup something like tripwire to only watch specific configuration files and services, it might not catch the newly created /etc/ld.so.preload file. Some programs (such as login), are already statically compiled to prevent this exact thing from happening.
- viraptor 17y ago
  I think that the default tripwire config (and definitely the default samhain config) includes monitoring new files in /etc, so at least there's that protection. Unfortunately not many people use those applications in real deployments.
- joeyh 17y ago
  Hmm, I have not encountered a suid login. Since login runs passwd, and passwd uses pam, and pam is heavily based on demand-loaded libraries, that would be rather hard and big. Static shell? Sure, sash. Also helpful when ldso or libc is busted via non-rootkit means.
jrockway 17y ago
He was able to find it for this reason; ldd is statically-linked: $ ldd `which ldd` not a dynamic executable But if you audit your /etc files or the list of files in the executable directory of your web app, you also would have noticed this. It's not really undetectable, as it doesn't hide itself or the things it needs to run at all. More people check /etc once in a while than check the md5sums of their binaries.
- CUViper 17y ago
  It's not a static binary either, it's a script: $ file `which ldd` /usr/bin/ldd: Bourne-Again shell script text executable It's also worth reading up on LD_TRACE_LOADED_OBJECTS and the possible exploits therein, e.g. http://news.ycombinator.com/item?id=902958 http://news.ycombinator.com/item?id=902958 If the attacker were a little more clever, they could have faked bogus ldd output too.
- barrkel 17y ago
  Running ldd can also invoke arbitrary code: http://www.catonmat.net/blog/ldd-arbitrary-code-execution/ http://www.catonmat.net/blog/ldd-arbitrary-code-execution/

ratsbane 17y ago

Upvoted both for the content and expository writing style. He did a nice job not just of solving the problem but also showing how he did it.

deleted 17y ago

[deleted]

vog 17y ago

There’s something that puzzles me. The author found a rootkit and saw that it was integrated very deeply in the system. Yet he tried to fix the system from within! Only after some failed attempts to download and install a new kernel, he finally did the Right Thing and shut down the server to analyze the hard disk from outside. To everyone who encounters such a rootkit, I strongly recommend to skip this second step. If you see such a deeply integrated rootkit, shut down the computer immediately! No fiddling! Then, take out the hard disk and copy and analyze it as described in the article. Otherwise, you’d enable the rootkit to hide its traces, and to maybe destroy some data. You don’t learn anything from that fiddling. Satisfy your curiosity only after perpetuating evidence! (i.e. after copying the hard disk’s data)

iman 17y ago

It's often said that privilege escalation under Linux is very easy. Why is Linux so insecure in this aspect? Why does OpenBSD not suffer from local root exploits?