Security [LWN.net]

Infected Linux web servers pushing malware

By Jake Edge
May 15, 2013

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.

Comments (2 posted)

Brief items

Security quotes of the week

If I'm really honest with myself, though, my interest in the preservation of 0day was also because there was something fun about an insecure internet at the time, particularly since that insecurity predominately tended to be leveraged by a class of people that I generally liked against a class of people that I generally disliked.

[...]

Somewhere between then and now, however, there was an inflection point. It's hard to say exactly when it happened, but these days, the insecurity of the internet is now more predominantly leveraged by people that I dislike against people that I like. More often than not, that's by governments against people.

— Moxie Marlinspike (Thanks to Paul Wise.)

As we respond to the threat of terrorism, we must remember that there are other threats as well. A society without transparency and accountability is the very definition of a police state. And while a police state might have a low crime rate -- especially if you don't define police corruption and other abuses of power as crime -- and an even lower terrorism rate, it's not a society that most of us would willingly choose to live in.

We already give law enforcement enormous power to intrude into our lives. We do this because we know they need this power to catch criminals, and we're all safer thereby. But because we recognize that a powerful police force is itself a danger to society, we must temper this power with transparency and accountability.

Security

Infected Linux web servers pushing malware

Security quotes of the week

Hack.lu call for papers

Local root vulnerability in the kernel

firefox: multiple vulnerabilities

firefox: multiple vulnerabilities

gpsd: code execution

httpd: command execution

java: multiple unspecified vulnerabilities

kdelibs: username and password disclosure

kernel: multiple vulnerabilities

libtiff: two vulnerabilities

openstack-keystone: password disclosure

owncloud: multiple vulnerabilities

php-geshi: multiple vulnerabilities

php-sabredav-Sabre_DAV: local file exposure

python-httplib2: SSL certificate verification failure

xen: denial of service