Some Recent WordPress Theme Hacking Issues (Mass Emails To Non-Existent Domain Name Addresses) And A Couple Of Things To Look ForSaturday, August 1st, 2015
I’ve spent the past few weeks making several new email client filters each day, with subject lists that look like the following:
Saturday and Sunday Only! Today’s Special Buy of the Day! One day sale event – today only, [ insert date here ] [ insert name here ], check out this weeks specials – up to 75% off on selected items [ Insert name here ], 10% discount for Brand or Generics for purchases placed before [ insert date here ] We appreciate your past business with us [ insert name here ], some of your items are back in stock now – complete your order today [ insert date here ] deals and savings from your supplier
We’re talking between 2000 and 5000 emails a day of the following mishmash, with various random email addresses used, random first names and message content (always with a link or two, plus unsubscribe links), and all to email addresses that look like
This was occurring from the website despite having many popular site-security-related PlugIns running: Including Wordfence, Sucuri Scanner, and Jetpack (not that Jetpack would protect from site problems). As it turns out, Sucuri *might* have found the problem had I installed it (at least) 6 months ago.
The amount of email has gotten so bad I the past few weeks that the site itself has been taken down thrice by my +10-year-long hosting company (web.com. Can’t blame them for this one). Before telling you about where the problem eventually settled, I’ll note the following attempts to find the problem, listed below.
Steps To Diagnose The Problem
1. Taking the site down – which worked
2. Running diffs on all of of the files in the WordPress install (against a freshly downloaded copy from wordpress.org) – this helped greatly
3. Deleting the many files no longer use by wordpress (having run it since 2.1.something and allowing WordPress to do auto-updates) – no affect
4. Scouring my hosting folder for hidden files, modified .htaccess files, or anything else – nothing found
5. Looking for date changes on .jpg files to see if malicious code had been embedded into one of the images that always loads with the site – nothing found
6. The big one – switching from my primary theme (a heavily modified version of relaxation 3 column from 2006) to one of the provided WordPress themes.
The Problem, Localized
The problem, then, was localized to my old theme – which could have meant one of two things
1. Something in the php was causing the problem by being too old (a piece of php that WordPress recommended removing from all themes – that I never read about)
2. Something was, despite having my permissions set for read-only on the server (because this theme is never updated by WordPress), tweaked in one of the theme files (which turned out to be the case)
In my case, a few modifications had been made to theme files over 6 months ago that sat dormant in the .php files until something eventually came along to start spitting out beaucoup spam.
NOTE: Everywhere you see “->” and “< -", these have been replaced from "<" and ">” to keep anything from being read by your browser)
1. This nasty piece of work was deposited into an index.php file many moons ago (but the file date had not changed, so it went unnoticed)
The following had made into ALL of the theme index.php files in my WordPress install
These are to be contrasted with the following, more generic look for the top of an index.php file:
?php get_header(); ?
These are both interesting, but turned out to not be the problems. Instead, my relaxation-3-column theme had its 404.php, archive.php, and index.php files modified at some point in the distant past (at least as early as November of last year) with the following new lines:
->?php // relaxation 3 column ->?php get_header(); ?< -
->div id="content"< -
->?php function arphabet_widgets_init() ...
These beg the question – how does one find out that this stuff isn’t supposed to be in a theme file?
The answer, assuming you know a little php, is to compare and contrast you potentially older theme files with new theme files (such as those pre-installed in WordPress). In all the above cases, available themes look like the “after” files above, with unreadable code not present in the tops of the files.
So, long-short, if you find your inbox stuffed with hundreds or thousands of spam samples coming from your own domain, a good first place to look is your running theme. Much like the BSG Episode “33”, you may find yourself NOT getting spam after a certain period of time if you make a simple change from one theme to another (certainly a simple way to determine if the attack is from the theme or not).
Solution And Testing
The test for the modifications was simple:
First, backup your theme files to your local machine (or make a folder in your directory tree somewhere)
Second, after checking and (if necessary) making modifications, replace your index.php file FIRST, as this is the basis for your theme (and what WordPress looks for first in the theme). Your site will load, although it may look like hell.
Third, replace all those theme files which didn’t have something odd in them (like the gobbledegook above) and reload you site. Then, WAIT to see if you get spam (for my problems above, this took about, honestly, 33 seconds). Your site may still look like hell depending.
Fourth, change other problem files and upload them 1-at-a-time, then reload and wait to see if the spam starts.
Fifth – repeat #4 until your theme is all back up
Sixth – when all uploaded, change your theme permissions to READ-ONLY (although this did not help me)
With luck, your spamming problem fit the mold of the above and google brought you to a page that would help. So say we all.