Windows malware is not something that Linux users and administrators
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
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
requests with a
redirect to a site of the attacker's choice—likely one that serves up
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
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.
to post comments)