Rootkit infects Linux web servers | Hacker News Reader

Rootkit infects Linux web servers

h-online.com

110 pointstangue28 comments

More details at:

CrowdStrike: http://blog.crowdstrike.com/2012/11/http-iframe-injecting-li...

Kaspersky: https://www.securelist.com/en/blog/208193935/New_64_bit_Linu...

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."

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

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

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

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...

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?

The 'vulnerability' is in the kernel, it replaces some of the tcp send functionality and is at a much lower level than nginx. It looks for outgoing http traffic and injects a bad iframe.

No idea on how it gets there though, no details from any source I've seen.

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

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?

According to http://seclists.org/fulldisclosure/2012/Nov/94 it would inject an iframe in each http response.

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.

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).

CrowdStrike says that it hooks vfs_read and if the data read contains the line it injects into /etc/rc.local, it is removed from the read buffer.

This means you could just read the file byte-by-byte (I guess runnin dd a couple of times would work), though I haven't tried myself.

In this article it shows a few ways to check. Apparently they did a poor job of covering their tracks and ps will show you a kernel thread of get_http_inj_fr

http://blog.crowdstrike.com/2012/11/http-iframe-injecting-li...

The best part about that is that it appends a startup call at the end of /etc/rc.local- which, by default, ends with 'exit 0'.

So its rc.local functionality is actually totally ineffectual.

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."

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

...Or, in the case of rootkits:

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

99% of them are right.

"and the writer is a Windows guy who thinks "*nix doesn't get viruses."

this is the part of your statement I don't get (the other part, I'm not sure if it is well-grounded). Do you mean the guy wants to prove otherwise? Also, if the guy is a ;Windows guy' wouldn't he be much better at writing Windows targets?

I think you consider the writer of the virus, whereas 46bit means the writer of the article

ah, seems reasonable

Yep, sorry stinos. Bad phrasing on my part.

no mention of delivery mechanism. anyone know more?

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

I looked at your script at https://github.com/pschlump/linux-rootkit-expunger/blob/mast... 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.

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.

Did you read the post on crowdstrike in detail? I suggest you do, your script will not work because

- rootkit re-adds itself to the /etc/rc.local

- it patches the filesystem functions to hide itself when you read the file, so I am not convined grep will pick it up anyway

- you do not unload the actual kernel module if it is running, nor destroy the rootkit kernel module

- did you test it by installing the rootkit in a vm, and confirm that your code will detect and remove it? if not, i do not think you should publish such code just to give people a false sense of security when they run it and says "rootkit not present"

http://blog.crowdstrike.com/2012/11/http-iframe-injecting-li...

I don't have access to a system with the root kit, but something like comparing the reported size of the file and the number of bytes you can read might work

if ls -l /etc/rc.local | awk '{print $5}' != \ cat /etc/rc.local | wc -c

Also looks like you might be able to see it running with a ps also.

Reply on news.ycombinator.com