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."
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.'
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.
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?
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).
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
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."
"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?
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"
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.
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.
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."