Malicious Apache Module: a clarification

[Update: here's a comment just added to his original blog by Pierre-Marc:

As pointed out here:  http://eromang.zataz.com/2012/12/20/isnt-linuxchapro-a-only-darkleech-apache-module/ it appears that what we call Linux/Chapro.A has already been publicly discussed here  http://blog.unmaskparasites.com/2012/09/10/malicious-apache-module-injects-iframes/ by UnaskParasites.

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.

There is, as far as we're aware, no Apache vulnerability 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:

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.

Description

MD5 Hash

Linux/Chapro.A

e022de72cce8129bd5ac8a0675996318

Injected iframe

111e3e0bf96b6ebda0aeffdb444bcf8d

Java exploit

2bd88b0f267e5aa5ec00d1452a63d9dc

Zeus binary

3840a6506d9d5c2443687d1cf07e25d0

David Harley CITP FBCS CISSP
ESET Senior Research Fellow

我来评几句
登录后评论

已发表评论数()