June 2011

Cleaning up the Wordpress Pharma Hack

Cotton Rohrscheib called me a few days back wanting help fixing an apparent defacement (of sorts) on his website. Normally when a site is defaced, the pictures, text and other content are modified to make some sort of statement (be it political or otherwise). This hack was different - it only modified page titles and/or meta tags in order to exploit a site's search engine ranking to advertise cheap pharmaceuticals. So, instead of seeing the page titles in the search results you get this instead:

Not exactly what you wanted to see huh? It's a pretty clever concept but I'm not sure just how effective it is in selling these meds. I guess their thought is that if they can get high ranking sites to "advertise" for them then their trusted readers will purchase these items. Pretty sorry if you ask me, but as long as someone is making a dollar off of it, stuff like this will just continue.

So - how do you get rid of it? Well, it ain't so easy. Let me state up front that I am no Wordpress expert nor am I overly familiar with it's internal workings so it's possible I'm taking the long-way around. We scoured the web reading a ton of sites (special props to Sucuri) all with bits-and-pieces of the answer. None seemed to have the entire solution, so we're going to try to present our findings here. The first time we "removed" it wasn't complete - so checking periodically to see if it stays clean is pretty much mandatory. All of our servers run suPHP, but the hack was able to run successfully. I'm also not exactly sure how they "got in" so to speak, but irregardless of what others may say I believe it was a bug in Wordpress that was exploited before we applied the patch for it. suPHP will not allow a file to be read/executed unless it has correct permissions, so Wordpress itself (or one of it's many plugins) had to be the culprit. The latest ModSecurity ruleset will also help prevent these sort of attacks, but is not a solution for not patching sites as soon as possible. Security is a continuous process, not a "set it and forget it" model.

Ravencore and PHP 5.3

If you use Ravencore (it's a pretty simple little web control panel) you've probably figured out by now that it doesn't work under PHP 5.3. The reason is that the author wrote a custom function called "goto." PHP never had a goto until 5.3. His custom goto conflicts with the standard one. PHP was attempting to interpret his function as the built-in. So, one quick command line and you can fix this

cd /usr/local/ravencore/httpdocs
find . -type f -exec sed -i "s/goto/openfile/g" '{}' \;

His function was basically "opening" these files, so I just renamed "goto" as "openfile." Now your nifty little control panel works like a charm and the customer who uses it is happy once more. btw - I prefer grep, awk, sed, and vi as my control panel...;)