Darkleech Apache attacks on the rise, but is it really that hard to detect?

Reports of CDorked.A infections are still on the rise by the looks of things. The attack is reported as 'hard-to-detect', but this should only be true for the more naive sysadmins out there.

Whilst it's true that CDorked changes nothing on disk, except the HTTPD binary, this change alone should be triggering alerts. On a production server, you should be storing checksums of known good files and comparing these regularly to see if anything's changed.

As some obviously aren't following this basic step, in this post we'll look at what you need to do to at least be made aware if CDorked gets onto your system - it'd be nice to be able to do a post on avoiding it, but the attack vector is still unknown!

 

What is CDorked

CDorked is a lovely piece of code, as the nasties go. It's primary purpose, at least for the moment, seems to be to redirect visitors to the Blackhole Exploit kit. Unlike some other malware, though, it's pretty slick in it's operation.

If you visit a page on an infected server that CDorked believes is related to administration (for example /cpanel, page.adm /administrator/), it sets a cookie to ensure that you're never redirected. This, presumably, happens to reduce the likelihood of the administrator knowing about the redirection.

All HTTP command & control requested are encrypted and don't appear in the Apache logs, meaning that there's nothing in there to warrant attention. The slight exception to this being the reverse-shell functionality. The request won't appear in the logs, but the process doesn't fork so you'll likely see a long-running HTTP process - if the shell is in use!

All of CDorked's information is stored in about 6MB of shared memory, so the only evidence you're going to find on disk is the modified binary.

 

Detecting CDorked.A

If you've read this far, you've probably not been storing hashes for your system. There's absolutely no point in us just running one now, as we don't know whether the system is already compromised. So to begin, we'll run the Python script provided by WeLiveSecurity to check for the Shared memory area that CDorked created.

You'll need to install P7zip to extract the file,

# *buntu
apt-get install p7zip-full

# CentOS
yum install p7zip

Extract the file with

p7a dump_cdorked_config.7z

Now we just need to run the check

python dump_cdorked_config.py

If you receive a syntax error relating to the line containing the octal 0o666 it's likely you're running a version of Python younger than 2.6. Just edit the file and change that line so it's 0666 instead

You may also encounter an error relating to ctypes:

# CentOS
yum install python-ctypes

Once the script runs without error, you should hopefully receive 'System Not Infected'.

 

Now we're clean

Now that we're reasonable confident that we're clean, it's time to look at adding some measures to give advance notice. We can of course create a cronjob to run that script regularly and email us the result, but that's a very malware specific precaution!

There are a number of routes we can go, and it partially depends on your setup. If all software is installed from repositories, then we can use 

rpm -v
debsums -c

If, however, you use CPanel and Apache was compiled using EasyApache you're out of luck - The one file we want to check, won't be as it was compiled from source. There's absolutely no harm in verifying your other packages, but be aware that Apache and PHP won't be included!

It's generally wise to use several methods, so I've a tendancy to install and configure

Essentially, all that we're interested in, is being notified when the checksum of a file changes. This is a tad irritating after a system wide update has been run, but is invaluable when nasties like CDorked appear. There are certain binaries which we can reasonably expect never to change (or, very rarely anyway) and the HTTPD binary falls firmly in that category.

The first time you find out a server has been infected by CDorked.a shouldn't be when you run that Python script, it should be when you receive an email telling you that the checksum of /usr/sbin/httpd has changed.

One thing to note though, if the checksums for your 'known clean' system are only ever stored on the server, there's no guarantee they won't have been tampered with. So you should look at isolating a copy of the hashes for an occasional manual check as well.