Since a few weeks SWITCH-CERT has observed a dramatic increase in sophisticated attacks on Swiss web servers. The compromised servers will then be used to distribute malware through drive-by attacks. We currently observe two different, although related, linux based attacks. Both deploy the black hole exploit kit as the actual drive-by infrastructure.
Both attacks are extremely difficult to detect for website owners, because:
- The attacker code is in the server config, through modules, not in the content part
- The black hole exploit kit returns malicious content only once per day and IP
The two attack waves have been dubbed darkleech and Cdorked respectively. Most attacks go after cPanel managed systems and target Apache. But this is not always the case: There are reports, that versions exist that target Lighttpd and nginx. Many of the compromised systems seem to also have a modified sshd, containing a backdoor installed. So if a compromise is detected, sshd must be cleaned, too. Sometimes it’s possible to spot tampered binaries through an integrity check, that various package managers offer. This obviously only works if a packet has been installed through a package manager. On cPanel based systems the webserver is not installed by this mechanism.
Below we give some information how website owner can identify an infection and possibly remove it. In all cases root access is necessary to the system, so web site owners are advised to contact their hosters.
According to Sucuri who published first about darkleech, an affected apache binary contains the string open_tty, so the command
grep -r open_tty /path/to/apache/
will find infected servers or modules. If positive, you must replace the entire installation to be sure that nothing is left. The attacker also change the attributes of the binary, so if the command
returns anything but ‘————- /path/to/httpd’ a problem might exist.
Checking integrity of installed software
RPM based systems
First check if the original package is installed. Issue
rpm -qi package| grep Signature
where ‘package’ is the name of software package in question. Compare the Key ID with the one given by your OS Vendor. If it is ok, issue a
rpm -V package
It lists all manipulated files.
For example to check the sshd on a CentOS 5 installation you would see:
[root@server ~]# rpm -qi openssh-server | grep Signature Signature : DSA/SHA1, Wed 22 Feb 2012 07:46:31 PM CET, Key ID a8a447dce8562897 [root@server ~]# rpm -V openssh-server
The key matches with the one given on the CentOS page and only the config file has been changed. So this seems ok, if you indeed changed the config.