There’s a rootkit in the closet | Hacker News Reader

There’s a rootkit in the closet

void.gr

127 pointsposthumangr10 comments

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)

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.

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

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.

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.

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.

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.

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

If the attacker were a little more clever, they could have faked bogus ldd output too.

Running ldd can also invoke arbitrary code: http://www.catonmat.net/blog/ldd-arbitrary-code-execution/

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?

Reply on news.ycombinator.com