In the last few months, we have witnessed a rise in the number of cases of modified Web servers that inject malicious redirections into every website that it hosts. One example was the malicious Apache module (Linux.Chapro and Trojan.Apmod) that we blogged about recently. A newer example is Linux.Cdorked, about which our friends at ESET also wrote.
With Linux.Cdorked, instead of adding a malicious Apache module to the configuration list, the attackers instead replaced the main httpd binary file with a modified version. This allows the Trojan to react to special requests and modify the responses.
The modified http daemon file allows control through a classic reverse connection shell or through special HTTP requests that modifies the configuration that is stored entirely in shared memory. We have identified 23 different command tokens such as “DU”, “ST”, “T1” and “D1”, which are parsed from the request string. These commands then modify sections of the shared memory in order to modify the black list, change the redirection address, or perform other functions. The main goal with this Trojan, as mentioned above, is to redirect all visitors of any hosted website to a different site. This redirection can lead to drive-by download sites that host exploit toolkits or spam sites in order to generate traffic. Of course, the targets of the redirection are updated frequently in order to stay out of blacklists.
The redirection only occurs if certain criteria are met: the visiting IP address is not on a blacklist; the URI does not match specific keywords related to administration pages; the user-agent is not on a blacklist; and the client does not have a cookie from a previous redirection. As the administrator’s local IP is often on the blacklist, and the URI visited is also on the blacklist, the administrator will not be redirected to the malicious site making it more difficult for the administrator of the website to spot the infection.
Figure 1. Characteristics of the attack
These attacks are definitely more sophisticated than the usual insertion of a malicious iframe into a static HTML website by, for example, using an SQLinjection attack on the Content Management System (CMS) of a website. Since the Web page is modified on the fly, logging into the server through FTP in order to verify that the files have not been modified will not provide any evidence that any tampering has occurred, as there is none at that level, thereby making it difficult to identify any existing infection.
Furthermore, the attacker has an excellent multiplier with this strategy, since every website hosted on this server will by infected by default. This can lead to a large number of victims in a short space of time. Also, Linux.Cdorked is quite stealthy as it keeps all of the configuration information in a shared memory section and the special command requests are not logged by the Web server. Therefore, an infection has the potential to go unnoticed for quite a long time. We expect to see more of this type of attack in the future.
The question of how the attackers manage to access the Web server in the first place has many possible answers. In the past, we have observed cases whereby vulnerabilities in management frameworks like cPanel or Plesk have been misused to gain access. Of course, password guessing on those panels or even on SSH is a possible option that can work for the attackers in many cases. As always, the advice for administrators is to keep their systems updated and monitored. We recommend verifying the binary of the Web server, for example, by comparing the MD5 hashes to a list of clean binaries from the vendor or with commands like ‘rpm-verify’ on the Debian platform. However, keep in mind that since the attacker has access to the server, they may also modify any traces left behind on the system.
Symantec has various IPS & AV signatures in place in order to protect our customers from these malicious redirection attacks.