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.
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)
11 comments
[ 2.9 ms ] story [ 28.4 ms ] threadSome programs (such as login), are already statically compiled to prevent this exact thing from happening.
Static shell? Sure, sash. Also helpful when ldso or libc is busted via non-rootkit means.
If the attacker were a little more clever, they could have faked bogus ldd output too.
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)
Why does OpenBSD not suffer from local root exploits?