Infected Linux web servers pushing malware

Windows malware is not something that Linux users and administrators typically need to be concerned about. Though our systems can't be infected by such code, it's unlikely we want them to be used as a vector for its transmission, but that's just what's happening with the Linux/Cdorked.A malware. Originally linked to Apache web servers, the malware has now been found in both lighttpd and Nginx web servers as well. While there is a fair amount known about how Cdorked works, it is still an open question as to how it is getting installed onto Linux systems.

The scope of the problem has widened a few times. At first it seemed that only cPanel-based servers were affected by the malware when it was first reported in late April. By early May, it was clear that "it cannot be attributed solely to installations of cPanel because only a fraction of the infected servers are using this management software", according to a report from ESET, an anti-virus company. That report was also the one that pointed out that it was more than just Apache web servers being affected.

Essentially, infected systems have a malicious version of the web server binary installed. That is the only difference that shows up on the disk of affected systems. All of the configuration information for the malware is pushed into a shared memory segment via unlogged HTTP requests sent by the attacker. Typically, the compromised web server is configured to serve some subset of incoming HTTP requests with a redirect to a site of the attacker's choice—likely one that serves up malware.

The subset of requests is fairly carefully chosen. Cdorked avoids redirecting any request that looks like it might be accessing an administrative page, presumably to avoid doing anything suspicious to anyone likely to be technically sophisticated. It also sets a cookie when it does the redirection, so that it doesn't do so again.

The redirections are mainly done to sites that host the Blackhole exploit kit, which tries to use a wide variety of browser holes and plugin exploits to infect a victim's system. Typical configurations noted by ESET redirect Windows Firefox and Internet Explorer users to the Blackhole sites, while sending iPhone and iPad users to a pornographic site, presumably trying to monetize requests that would not be affected by the Blackhole exploits.

There are some other interesting restrictions on who gets redirected. Roughly half of the IPv4 address space has been blacklisted (or whitelisted depending on how you look at it) and will not get redirected. There is no obvious pattern to the IP address ranges. Similarly, there are restrictions based on the language configured for the browser, so browsers set to Japanese, Finnish, Russian, Ukrainian, Belarusian, and Kazakh are immune as well.

ESET has discovered a sophisticated set of commands that can be issued to the trojanized web server binaries. That includes a command to create a connection to the specified address with a shell attached. That would allow the attacker full access as the UID that is running the web server, as described in an earlier ESET blog post. As might be expected, the other commands (all of which are sent via obfuscated URLs to the infected host) manipulate the IP blacklist, language list, URL to redirect to, and so on.

The fact that the attackers have created trojanized binaries for three separate web servers (at least so far), the extensive "command and control" mechanism, and the stealthy nature of the attack, all add up to a fairly sophisticated set of attackers. ESET has also found evidence of subverted nameservers at the shared hosting sites that are (presumably unknowingly) serving the Blackhole kits.

The most puzzling aspect, perhaps, is how the initial infection of the web servers is happening. "One thing is clear, this malware does not propagate by itself and it does not exploit a vulnerability in a specific software", according to ESET. It will be interesting to see what set of vulnerabilities was actually used here; hopefully that will be determined soon. In the meantime, for detecting compromised systems there is a tool to look for the shared memory segments, though checking the integrity of web server binaries is another possibility. On the worrisome side, though, is that whatever vulnerability was used, it can presumably be used again. This one seems worth keeping an eye on.