Security

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.

Making Drupal More Secure

This site is running in a CMS called Drupal. It, like most CMS systems, allows users to easily create, edit, and delete content and manage many features of a website. But, like most, it is not without a few security flaws. Me, being a geek, and having more than a passing interest in security, decided to try to make this site a little more secure, and possibly even PCI Compliant.

Mod Security is good for you!

Since I'm back, I've got a few days worth of log files to dig through. A couple of years ago an old legacy PHP script Pleth was running wasn't very secure, but was critical to the operations of a particular customer. It got hacked (well, they used it to upload a C99Shell) a couple of times before the vendor released an update. Scouring the internet for a solution, I learned of Mod Mod Security, an application firewall of sorts. It runs as a module in your Apache configuration and uses a set of user-configurable rules files to detect and prevent a number of attacks against a website. The rules list has a huge community backing, and people have written rules for about every vulnerability out there. Open Source is good no? Anyway, as I was digging through those files today it kinda shocked me to see just how much stuff mod_sec blocked. The internet is a dangerous place.....

Syndicate content