

Rootkit infects Linux web servers - tangue
http://www.h-online.com/open/news/item/Rootkit-infects-Linux-web-servers-1753969.html

======
drostie
More details at:

CrowdStrike: [http://blog.crowdstrike.com/2012/11/http-iframe-injecting-
li...](http://blog.crowdstrike.com/2012/11/http-iframe-injecting-linux-
rootkit.html)

Kaspersky:
[https://www.securelist.com/en/blog/208193935/New_64_bit_Linu...](https://www.securelist.com/en/blog/208193935/New_64_bit_Linux_Rootkit_Doing_iFrame_Injections)

Both links were submitted to HN but didn't make the front page; I guess the
third time's the charm?

CrowdStrike in particular concludes, "Based on the Tools, Techniques, and
Procedures employed and some background information we cannot publicly
disclose, a Russia-based attacker is likely. It remains an open question
regarding how the attackers have gained the root privileges to install the
rootkit. However, considering the code quality, a custom privilege escalation
exploit seems very unlikely."

~~~
antihero
Thanks. It only targets a specific version of 2.6, which is comforting.

------
tangue
Basically it targets Nginx and seems to substitute some tcp functions to
inject an iframe.

<http://seclists.org/fulldisclosure/2012/Nov/94>

~~~
TranceMan
Moreover it also seems to target a specific kernel version [which is used by
the latest debian 4bit] , from the securelist [1] article:

'The malware module was specially designed for the kernel version
2.6.32-5-amd64, which happens to be the latest kernel used in 64-bit Debian
Squeezy. The binary is more than 500k, but its size is due to the fact that it
hasn't been stripped (i.e. it was compiled with the debugging information).
Perhaps it's still in the development stage, because some of the functions
don’t seem to be fully working or they are not fully implemented yet.'

1\.
[https://www.securelist.com/en/blog/208193935/New_64_bit_Linu...](https://www.securelist.com/en/blog/208193935/New_64_bit_Linux_Rootkit_Doing_iFrame_Injections)

------
jonpaul
Unless I missed it, the article doesn't mention exactly how it gets on your
web server in the first place, or what vulnerability it exploits. I presume
some vulnerability in Nginx? This would be the most important part, how can I
prevent my web server from getting infected with this specific rootkit. Did I
miss this part?

~~~
tangue
Nobody knows. But the attacker has to have root privileges to install the
rootkit. So the usual suspects are weak password and unpatched software.

------
sethg
The article says the rootkit works by inserting a line into /etc/rc.local. If
my /etc/rc.local file looks OK, can I assume I haven’t been infected, or does
the rootkit use more sophisticated means to hide its presence?

~~~
0x0
No, one of the earlier reports showed how the rootkit detects reads of
/etc/rc.local and feeds you a file that looks like it doesn't contain the
rootkit loading insmod calls.

~~~
csense
Disclaimer: I don't have a copy of the rootkit to experiment with; all of this
is pure speculation.

My guess is you could detect the rootkit by booting to a known-clean system --
for example a distro install CD -- and checking the contents of rc.local by
mounting the questionable system's fs.

This examination could probably be performed without downtime by taking an LVM
snapshot and downloading it to a known-clean machine. The rootkit _could_ fake
the contents of the LVM snapshot as well, but it seems like this would be much
harder for the rootkit authors and they probably didn't bother.

You might also be able to disable it by modifying your startup scripts to
ignore rc.local (perhaps you could put a replacement in a non-standard
location if you need the functionality).

------
46Bit
No mention of infection stats, mechanisms, etc. I surmise this isn't a rootkit
to worry about (beyond the usual daily scanners, etc) and the writer is a
Windows guy who thinks "*nix doesn't get viruses."

~~~
dguido
"Oh, this will never happen to me!" -everyone before they get hacked

~~~
cheeseprocedure
...Or, in the case of rootkits:

> "Oh, this will never happen to me!" -everyone, long after they were hacked

------
etherealG
no mention of delivery mechanism. anyone know more?

------
pschlump
Just in case this is a real problem I have put together some quick scripts
that check for and can remove this. The code is up on github.com as
<https://github.com/pschlump/linux-rootkit-expunger.git>

~~~
javajosh
I looked at your script at [https://github.com/pschlump/linux-rootkit-
expunger/blob/mast...](https://github.com/pschlump/linux-rootkit-
expunger/blob/master/find-rookit.sh) and you're just doing a simple file read
of /etc/rc.local. This will not work as the rootkit hides itself.

I suggest you do not claim that your removal tool works until you have tested
it successfully. this is true for all software, but is even more critical for
something like this, since a false sense of security is actually far worse
than just being infected.

~~~
mercurial
Actually, this may be a way of detecting it. If you ls -l rc.local, ls should
read the file size out of its inode (ie, not by reading the file itself).
Which means that saving the buffer you get while reading rc.local in vim to
another file will result create a file with a different size than the real
rc.local.

