What Desktop Innovation Needs to Succeed
Open Source Feminism: The Unfinished Revolution
Why Debian Is the Gold Standard of Upstream Desktop Linux
Yesterday's Man: The Fall of Richard Stallman
What's the Future of Free Software?
April 13th, 2015

WordPress Plugin ‘Simple Ads Manager’ Exploit

Anyone who runs sites using the WordPress platform and the plugin Simple Ads Manager will want to read this and learn from our mistake. Even those not using this particular plugin, but who have deactivated plugins not being used but still residing on their servers might find this useful. Luckily, in our case no harm was done, but that’s only because the incident occurred on a test site, so we were able to just take the site down. Lucky for us, it wasn’t FOSS Force or one of our other active sites.

Early Saturday evening we began receiving numerous email notices with two worrisome subject lines from our server. One subject was “LOCALRELAY Alert for sitename,” being sent to us at the rate of about every five minutes, with each showing info on the “first ten of 101 emails” that had been sent by the server since the last email notification. The other subject, “Script Alert for /path/to/script” was coming with the same frequency. To make a long story short, someone had hacked into a site we use to evaluate and test WordPress plugins before possibly deploying them on active sites, and was using it to send spam. Our test site had been turned into a spambot in other words.

As always, our host’s technical support responded in minutes. They found and quarantined four PHP files that a scanner identified as malware — three in a graphics directory that should have contained nothing but JPEGs and PNGs, and the other in the admin directory. In addition, they found another PHP file that “appears to be malware” in the directory for the WordPress plugin “Simple Ads Manager” and advised us to remove it if we didn’t place it there.

Simple Ads Manager is a plugin that we’d evaluated about a year ago. It was deactivated, but we’d failed to remove it from the server after we’d determined that it wouldn’t meet our needs. Bad move. The cracker/hackers had found it.

A quick search revealed that a proof of concept SQL injection exploit for this plugin had been widely published only a few weeks ago, on April 2, so we blew up the plugin directory and its contents. We then took a look at the graphics directory and saw that the file name extensions had been removed from every file in every sub-directory. At this point we quickly decided it would be prudent to just bring the site down, since it was merely being used for testing and could be easily reinstalled. We removed the WordPress installation and all other files.

The lesson here, of course, is one that everyone running a WordPress site should already know: Don’t leave plugins on your server that you’re not using. Just because a plugin has been deactivated doesn’t mean it can’t be exploited. The black hats can and will still be able to find it and exploit it. We knew this, but through an oversight had failed to follow our own best practices. We got lucky — it was on a site that doesn’t matter to us. It could have been much worse.

Christine Hall has been a journalist since 1971. In 2001, she began writing a weekly consumer computer column and started covering Linux and FOSS in 2002 after making the switch to GNU/Linux. Follow her on Twitter: @BrideOfLinux

Comments are closed.