Malicious Apache Module: a clarification

[Update: here's a comment just added to his original blog by Pierre-Marc. As pointed out here it appears that what we call Linux/Chapro.A has already been publicly discussed here by UnmaskParasites.We were not aware of this material before publishing this blog.  Thank you Eric Romang for pointing this out.]

The very classy recent blog from Pierre-Marc on ESET Canada's recent work on Linux/Chapro.A has generated lots of interest and some questions, including some from the press. We wanted to clarifiy that, as far as we're aware, no Apache vulnerability is currently associated with this malware or the other threats highlighted in the post, though the Sweet Orange exploit pack does attempt to exploit some known browser and plug-in vulnerabilities, as Pierre-Marc already noted:

• CVE-2012-5076: Java JAX-WS Class Handling
• CVE-2012-4681: Java getField Method Class Invocation Privilege Escalation
• CVE-2006-0003: Internet Explorer MDAC
• CVE-2010-0188: Adobe Reader LibTiff Integer Overflow

Our friends and colleagues at Kaspersky did, when they kindly flagged our article, use the term 'Apache exploit' but I suspect they were using it in the looser sense of exploiting the Apache mechanism for adding modules that aren't part of the standard distribution, rather than implying a vulnerability in Apache code. Apache modules are add-on code taking advantage of the Apache module API to extend the functionality of the standard Apache distro. In this case, the binary's functionality was malicious.

When we discussed this internally, ESET Canada's Sébastien Duquette said:

We don’t know the specific way the module was loaded on the server from which we got the binary. The module was loaded in Apache via the standard method: in the instance we analyzed, the module was named “mod_chart_proxy” but it could be called anything. Users should keep an eye on the modules they have loaded in Apache and investigate modules they don’t recognize.

As far as I can tell, no module of that name has been registered with Apache's modules database, and to the best of my knowledge Apache has not commented on the issue. There's probably no reason why they should.

Pierre-Marc commented:

“No idea how the chapro module got onto the server in the first place, could be weak password, vulnerable web application, etc. The user needs high privileges to load the module so.. he most probably had root on the machine.”

“We don't know who is spreading this but probably a gang specializing in such attacks, then renting "traffic" to other groups, I assume in this case a group that uses sweet orange to install zbot.”

Cameron Camp said:

It seems very unlikely that the module would have come from an official distro’s repositories, or the problems would be far more widespread. It is much more likely that the rogue code just got uploaded someplace on a server and apache is/was just doing what it was told.

Stephen Cobb added:

However, we also need to consider the module could have been part of a corrupted Linux distribution or application package.

Here, once again, are the MD5 hashes for the code that ESET Canada analysed. However, it's more than possible that the same or similar code will turn up again with a different hash.

David Harley CITP FBCS CISSP
ESET Senior Research Fellow