11 ms·

Rootkit infects Linux web servers

110 points by tangue 14y ago

etherealG 14y ago
no mention of delivery mechanism. anyone know more?
46Bit 14y ago
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 14y ago
  "Oh, this will never happen to me!" -everyone before they get hacked
  - cheeseprocedure 14y ago
    ...Or, in the case of rootkits: > "Oh, this will never happen to me!" -everyone, long after they were hacked
  - olalonde 14y ago
    99% of them are right.
- stinos 14y ago
  "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?
  - shdon 14y ago
    I think you consider the writer of the virus, whereas 46bit means the writer of the article
    - stinos 14y ago
      ah, seems reasonable
      - 46Bit 14y ago
        Yep, sorry stinos. Bad phrasing on my part.
deleted 14y ago
[deleted]
chuppo 14y ago
They still dont say how it installs itself in the first place, what vulnerabilities it exploits nor how do we stop it.
tangue 14y ago
Basically it targets Nginx and seems to substitute some tcp functions to inject an iframe. http://seclists.org/fulldisclosure/2012/Nov/94 http://seclists.org/fulldisclosure/2012/Nov/94
- TranceMan 14y ago
  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_Linux_Rootkit_Doing_iFrame_Injections https://www.securelist.com/en/blog/208193935/New_64_bit_Linu...
drostie 14y ago
More details at: CrowdStrike: http://blog.crowdstrike.com/2012/11/http-iframe-injecting-linux-rootkit.html http://blog.crowdstrike.com/2012/11/http-iframe-injecting-li... Kaspersky: https://www.securelist.com/en/blog/208193935/New_64_bit_Linux_Rootkit_Doing_iFrame_Injections 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."
- antihero 14y ago
  Thanks. It only targets a specific version of 2.6, which is comforting.
sethg 14y ago
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?
- deweerdt 14y ago
  According to http://seclists.org/fulldisclosure/2012/Nov/94 http://seclists.org/fulldisclosure/2012/Nov/94 it would inject an iframe in each http response.
- 0x0 14y ago
  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 14y ago
    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).
  - wulczer 14y ago
    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.
- stusmall 14y ago
jonpaul 14y ago
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?
- Nursie 14y ago
  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.
- tangue 14y ago
  Nobody knows. But the attacker has to have root privileges to install the rootkit. So the usual suspects are weak password and unpatched software.
pschlump 14y ago
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 https://github.com/pschlump/linux-rootkit-expunger.git
- javajosh 14y ago
  I looked at your script at https://github.com/pschlump/linux-rootkit-expunger/blob/master/find-rookit.sh 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.
  - mercurial 14y ago
    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.
- aeontech 14y ago
  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-linux-rootkit.html http://blog.crowdstrike.com/2012/11/http-iframe-injecting-li...
- gasda 14y ago

110 points by tangue 14y ago

no mention of delivery mechanism. anyone know more?

46Bit 14y ago

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 14y ago
"Oh, this will never happen to me!" -everyone before they get hacked
- cheeseprocedure 14y ago
  ...Or, in the case of rootkits: > "Oh, this will never happen to me!" -everyone, long after they were hacked
- olalonde 14y ago
  99% of them are right.
stinos 14y ago
"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?
- shdon 14y ago
  I think you consider the writer of the virus, whereas 46bit means the writer of the article
  - stinos 14y ago
    ah, seems reasonable
    - 46Bit 14y ago
      Yep, sorry stinos. Bad phrasing on my part.

deleted 14y ago

[deleted]

chuppo 14y ago

They still dont say how it installs itself in the first place, what vulnerabilities it exploits nor how do we stop it.

tangue 14y ago

Basically it targets Nginx and seems to substitute some tcp functions to inject an iframe. http://seclists.org/fulldisclosure/2012/Nov/94 http://seclists.org/fulldisclosure/2012/Nov/94

TranceMan 14y ago
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_Linux_Rootkit_Doing_iFrame_Injections https://www.securelist.com/en/blog/208193935/New_64_bit_Linu...

drostie 14y ago

More details at: CrowdStrike: http://blog.crowdstrike.com/2012/11/http-iframe-injecting-linux-rootkit.html http://blog.crowdstrike.com/2012/11/http-iframe-injecting-li... Kaspersky: https://www.securelist.com/en/blog/208193935/New_64_bit_Linux_Rootkit_Doing_iFrame_Injections 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."

antihero 14y ago
Thanks. It only targets a specific version of 2.6, which is comforting.

sethg 14y ago

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?

deweerdt 14y ago
According to http://seclists.org/fulldisclosure/2012/Nov/94 http://seclists.org/fulldisclosure/2012/Nov/94 it would inject an iframe in each http response.
0x0 14y ago
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 14y ago
  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).
- wulczer 14y ago
  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.
stusmall 14y ago

jonpaul 14y ago

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?

Nursie 14y ago
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.
tangue 14y ago
Nobody knows. But the attacker has to have root privileges to install the rootkit. So the usual suspects are weak password and unpatched software.

pschlump 14y ago

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 https://github.com/pschlump/linux-rootkit-expunger.git

javajosh 14y ago
I looked at your script at https://github.com/pschlump/linux-rootkit-expunger/blob/master/find-rookit.sh 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.
- mercurial 14y ago
  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.
aeontech 14y ago
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-linux-rootkit.html http://blog.crowdstrike.com/2012/11/http-iframe-injecting-li...
gasda 14y ago