Alex Kay

“So you all add his name to your mod_sec rules, no news about him can be served by your webservers.”

This is completely incorrect with the rule I suggested.

The rule I suggested only stops incoming requests that contain the string AFTER the question mark (?) in the request line.

So, outbound pages containing “abdullkarem” will serve fine. Requests for a page like site.com/abdullkarem.html would serve fine.

All that would be blocked is a request like:

site.com/something.php?abdullkarem

I do not feel like this is “helping” the hackers at all. However, if you want to be transparent, you could change the drop command to deny,status:404 and the requests would just be denied with a forced 404 response no matter what (even if the target file did exist).

Sure enough Devin, that is finding stuff that my grep, and clamav, and maldet missed. Thanks 🙂

If anyone finds malware like this that maldet is not finding, please report it with maldet -c $filename, this will send it to them so it can be added to future definitions.

You should be able to do a combined egrep (yay regex):

egrep -Rl '\$GLOBALS.*\\x|function.*for.*strlen.*isset' /home/username/public_html

Or if you’re bored and need to scan every .php file on a cPanel box,

find /home/*/public_html/ -type f -name "*php" -exec egrep -l '\$GLOBALS.*\\x|function.*for.*strlen.*isset' "{}" \;

I have noticed a few false positives from the GLOBALS check, but I’d rather review some clean files than miss some nasty ones.

No problem dylanbenq, glad to help. This one was really confusing and honestly malware was my last suspect until I remembered cleaning a hack for a customer who also happened to have this issue.

csasse, what I am trying to say is the renaming of link-template.php itself is not a hack/vulnerability, but rather it is a very odd thing being done by hackers who have left behind malware from past exploits.

Alright, maybe not a plugin. I cannot figure out why a hacker would do this (other than maybe an easy google dork?), but every site I’ve investigated has malware on it.

I found 3 files all ending in .suspected on one particular site. 2/3 were new enough for me to have domlogs… all of them had a post request about 4 seconds before they were renamed, and the POST went to a malicious file.

I’ve decoded the malware code, but it’s just one of those shells that decrypts and evals any code POST’ed to it. Without capturing the POST payload, I cannot be 100% sure.

Another edit (I love edits!)

Finding malware on affected sites, as are my co-workers (I work in a pretty busy help desk).

This grep command is turning up the malware. Lots of it is dynamic so I had to resort to a grep that uses the PHP functions, since the custom functions used in the code are dynamically named.

Affected users please try this (assuming you have linux CLI foo:)

egrep -Rl 'function.*for.*strlen.*isset' /home/username/public_html/

It should turn up a list of bad files if my hypothesis is correct. So far multiple techs working on this same issue have all come back with malware from that search. I cannot guarantee a total lack of false positives, but it did not return anything on my clean WP sites.

Just found this exploit working on another server. Same deal, really old “default” theme present. Replacing the 2007 or 2008 version of “default” with this http://wordpress.org/extend/themes/default stops the payload from executing. I can confirm the payload matches the strings in the OP’s logs.

You would think it wouldn’t work, but I saw it. It was indeed WP 3.4.2 running the 2007 default theme.

The POST Requests came back today, but they’re failing to generate any e-mail now that the theme was updated. The payload of the POST has two parts; one being a cookie used to help decrypt the other part, wich has file=(some long base64 string)

The request was definitely executing code using the $file variable before the theme was updated, and it’s definitiely failing to execute now. All’s well that ends well I suppose. Hopefully this helps someone in the future. I’ll refrain from posting the exploit code here as I think there are forum rules against it.

That exploit doesn’t work on cPanel servers, cPanel wraps the requests for CGI handlers and strips any command line options.

Server is using SuPHP for PHP handling.

(edit for reference) http://cpanel.net/cpanel-protects-against-php-vulnerability/