Some Recent WordPress Theme Hacking Issues (Mass Emails To Non-Existent Domain Name Addresses) And A Couple Of Things To Look For

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

[ person’s first name ] + @ + somewhereville.com

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)

2015august27_infected_1

The following had made into ALL of the theme index.php files in my WordPress install

2015august27_infected_2

These are to be contrasted with the following, more generic look for the top of an index.php file:

?php get_header(); ?

Decidedly different.

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:

404.php

2015august27_infected_3

vs.

->?php // relaxation 3 column

->?php get_header(); ?< -

archive.php

2015august27_infected_4
vs.
->div id="content"< -

index.php

2015august27_infected_5
vs.
->?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.

Led Astray By (A) Photon – WordPress, Jetpack, and The Perils Of Embedded Clear Sky Charts (And Other)

A re-post from the CNY Observers website (www.cnyo.org).

Greetings fellow astrophiles,

CNYO has been anticipating our first observing session at Beaver Lake for this year, with the first of our two Spring dates (April 23rd) already clouded/snowed out. The forecast for April 30th hadn’t looked too much better based on Monday estimates, leaving us to wonder if attendees would be stuck indoors with a lecture instead of outdoors with the rest of the universe.

I woke up early on the 30th to blue skies and a very bright Sun, certainly already exceeding the expectations of the past few days. But what of the afternoon and evening?

As I am prone to do on the day of an observing session, I headed right for the CNYO Cheat Sheet, where one can find the sky conditions for a large part of Central New York in the form of several Clear Sky Charts (CSCs – and, based on the different cloud cover at different locations, even begin to piece together how the skies at your location may change). The morning’s CSCs are shown in the image below.

2015april30_photon_before

You will note that the bars to the far left (representing the morning) are not the dark blue squares that would indicate an almost cloud-less sky. As the red text at the bottom notes, sometimes the CSC images from a previous session are still sitting in your browser’s cache and, to make sure you’re looking at the newest data, you should hit Page Reload. Well, 5 or 10 of those didn’t change matters at all. I clicked on the Downtown Syracuse image in order to see what the actual CSC website said about today. An almost perfect band of dark blue – prime observing weather (when the wind is mild, that is).

So, what happened?

The first clue came when I right-clicked on one of the images in order to see just the image in my browser. When you do this, you should see something like: cleardarksky.com/c/SyrcsNYcs0.gif?1

What I saw for the link was the following: i1.wp.com/cleardarksky.com/c/SyrcsNYcs0.gif?1

Something is afoot in Boötes.

A quick google search indicated that the i1.wp.com (which might also be i0.wp.com, i2.wp.com, maybe more) site is, in fact, an image (maybe other) repository for wordpress.com that is supposed to speed up your page downloading process (by being faster than the same image you might load somewhere else) and is called upon, specifically, by Photon – one of the functions built into Jetpack (itself a large suite of plugins for WordPress that very generally make my life much easier by providing Site Stats, Contact Forms, etc.). That said, this is no good for the Clear Sky Chart, as you don’t know how many days ago that i1.wp.com image was saved (and it clearly ain’t today’s!).

To disable this feature (if it was turned on, anyway), go to your WordPress Dashboard and click on Jetpack on the right-hand side.

2015april30_photon_jetback

At present, Photon is the first clickable item at upper left. Click on “Photon” to reveal the following image:

2015april30_photon_deactivate

Click on Deactivate and go back to your Clear Sky Chart-containing page:

2015april30_photon_after

You’ll note that the Clear Sky Charts are fixed (revealing an excellent day for Solar and Night Observing) and you’ll also see that the NASA/SOHO image is different, the SWPC/NOAA image is different, and event the Wunderground logo is different. Quite the site fix!

If you have the same problem, I hope the above fixes it. If you know of a site running the Clear Sky Chart and it doesn’t reflect what you see outside, let the site admin know.

“From Kurdistan With Love” or Some Things To Do Before And/Or After Your WordPress Site Gets Hacked

“Hopefully, because he’s busy.” – Commissioner Gordon, The Dark Knight

On the plus side, www.somewhereville.com received its first update in just over 5 months. On the minus side, the new post was less than useful in many ways. I received a timely email from Dr. Obi Griffith of the Washington University in St. Louis Division of Oncology noting that my entire site was differently-down (thanks to the hijacking of my Sanger (And Illumina 1.3+ (And Solexa)) Phred Score (Q) ASCII Glyph Base Error Conversion Tables page that he linked to on a biostars site thread – so my thanks to Obi for catching something I likely would have gone weeks without noticing!).

The snapshot below shows the state of swv as of 3 December 2014. On the bright side (minus a friendly conspiracy to get someone else in trouble), I can say with some certainty that Serwan performed the content-ectomy (twitter: @S3RW4N, current email (although I suspect it won’t last long): serwan_007 – at cymbal – hotmail.com, on the Facebook, etc. All sites subject to change as people try to track him/her down post-attack (he/she’s been prolific if nothing else)).

2013dec11_serwan_hack

Exhibit A. Flag is waving in the actual version.

Several problems. To begin, it’s a gaudy hack, complete with rolling text and techno music. Second, the Television New Zealand (TVNZ) news service thought this hack to be significant enough to warrant actual coverage on their website when a similar file-swap on a WordPress (or WordPress-esque) site brought down the Health and Sports Fitness Club in Sandringham (syracuse.com didn’t give me the time of day). I commend this Kurdish hacker group for their ratings. Third, the manner in which files were replaced in the blog (specifically meaning the index.php file) blocked every other post on the site from being accessed, so every link anyone had posted to a page anywhere else on the Internets was made useless.

That said, I appreciate that Serwan generally performs fairly benign attacks on websites. File replacements were clearly identified from a simple date sorting, the important MySQL database content wasn’t touched, and Serwan even went as far as to set up a second Admin account so that I could quickly retake control of the site.

So, in light of the plight of the Kurdish people, I left the hacked version up for a few hours as I pondered what to do, which I discuss below.

My Spotty Procedure For Recovery:

What follows is a list of obvious and less obvious things to consider when recovering your WordPress blog from a hack. There are plenty of websites that show how to protect your site in the first place, then others that explain how to revive it (provided you do your own due diligence and back your site up regularly enough). What’s below is not complete, but you can rest assured that google is your friend in such matters, so keep your keywords targeted and see what comes up.

General Considerations:

1. Don’t use your blog. My last post at the time dated back to June 25th, during which time I’ve made several full backups (and kept WordPress up-to-date, the last time being 7 November 2013) of my entire site. In this respect, I was well set up to quickly recover from a hacking incident.

2. Keep a copy of your current running version of WordPress handy for file replacements. In my case, index.php was written over. All I had to do to recover was uncompress my WordPress  3.7.1 download, upload index.php to my server, and the site was back and running.

3. Have you backed up lately? This phrase has been in the .sig of my emails for many, many years. If your entire life is lived in the Googleverse (email, images, documents, etc.), then you’re fine until the Earth’s magnetic poles shift and wipe all the hard drives out (just kidding. I think). If you’re a computational scientist and have TBs of data, it’s up to you to make sure you have access to it all again. Same applies to WordPress. I’ve a biweekly alarm that tells me to back up several websites and I’ve an encrypted .txt file with all of the login info and steps needed to perform this backup. You should absolutely be doing the same if you’re not.

4. Set up an additional Administrator. In my case, my admin account was hacked to change the associated user email address to Serwan’s email. Obviously, attempting to log in, change the password, or what have you simply sent little pings of your futile attempts to the hacker. Having that second admin account will allow you to reroute your login efforts (and if they’re both hacked into, there’s still a way around. Will get to below).

5. Make a real password. At the risk of de-securing my sites by providing personal info, my typical password looks something like this:

d@!25fj014or&ydoSDfu

20 characters long, upper and lower, numbers, and non-alphanumeric characters. If you care about your site security, stay the hell away from the dictionary.

6. Dry-run your SHTF moment. Are you a survivalist? Can you identify edible berries by sight, build a lean-to, or stitch an open wound? Or are you the Marty Stouffer of the camping section at Target? If you’ve never had to work your way back from a complete disaster, you likely won’t know how to do it either quickly, efficiently, or securely.

Ergo, do another WordPress installation in a sub-folder of your main installation, create a new database, make your site pretty, perform a full backup of your database and uploaded media, then break it, either by deleting core files or corrupting your database (deleting a table would do the trick). If you can put the site back together again (the uploading of the database back onto your server likely being the worst part of the whole process), you’re likely in good shape for the real deal.

7. Harden WordPress. The good people at WordPress even tell you how to (although, admittedly, I thought I did all of this, so maybe there’s something being missed that will go into a future iteration of this page).

8. Get rid of “admin.” Several of the sites discussing WordPress hacks report that having this default account (or account default’ed) is a top-5 problem when trying to keep people out of your site. So get rid of it. Easily. Set up a new account, give it administrative privileges, then delete the admin account, which will ask you to attribute the current admin posts to another admin account.

9. Delete deactivated plugins if you’re not going to use them. Plugins are developed by people. People often have lives that keep them from timely updates of security exploits. If you’re using a plugin, that’s one thing. If a deactivated plugin languishes in your plugins folder, never gets updated, and some hacker writes something specifically to exploit a security flaw in that old, poorly maintained plugin, that’s all on you. So don’t risk your pocket knife being a projectile as you walk into the MRI room and get rid of the knife before it comes a problem.

10. I know nothing about it yet, but am giving Wordfence a whirl presently.

11. Hey, check your blog every once in a while to make sure it’s still you and not Serwan.

For The Specific Attack (From Easy To Harder):

1. FTP in and check file dates. The offending .php files (index.php and a hello.php containing the techno) were both dated 3 December 2013. Everything else was, at its newest, 7 November 2013 (from my last WordPress update). This made finding the hacked and previously not-present files easy. A cluster of important files with identically modification times and dates is an easy giveaway.

2. FTP in and check ALL the file dates. One never knows when something else is going to be placed into a themes folder, plugin folder, etc., to keep track of site access (that’s why I delete all deactivated plugins). So, sort by date and scour the whole site for modifications and new files.

3. If you make it into your site, go right to your User Settings, change the email address, then change your password.

4. Check out something like Sucuri SiteCheck. Hopefully, this search will complement your initial search as well as test against known threats. I ran a Sucuri on a similarly-hacked site (in this case, indoorstinkbugtrap.com) and received the following notification of defacement (so the check worked).

2013dec11_securi_results

securi.net results for fellow victim indoorstinkbugtrap.com.

5. If you can’t make it in the front door, crawl through the plumbing. You can change your admin account from within MySQL using, for instance, phpMyAdmin (check your hosting provider for details if this is new information to you). In the case of phpMyAdmin, you can modify the admin account in six easy steps.

1. Log in to phpMyAdmin

2. Click on the Structure Button in wp_users (red circle)

2013dec11_serwan_hack_mysql_1

3. Click on Browse (told you this was easy)

2013dec11_serwan_hack_mysql_2

4. Click the edit button for your administrative account (red circle)

2013dec11_serwan_hack_mysql_3

5. Change the email address back to your email and delete the current password.

2013dec11_serwan_hack_mysql_4

6. Save and go back to our WordPress site, then request a new password.

And, While We’re At It:

Serwan’s twitter image currently features a white hat (the Gandalf-ian sign of a good guy/gal hacker) and a long list of sites that have been defaced with otherwise useless, feral medadata promoting Kurdish Hackers for google to get confused by. A search for somewhereville.com in google left the following bad taste in its results page for a week after:

Hacked By Serwan. Allah Is Greatest. Long Live Kurdistan. Thanks To All Kurdish Hackers. Follow @S3RW4N FB.com/Mr.S995

If I may be so bold (and I’ve told Serwan the same), the Kurdish people had a long history of getting steamrolled by an oppressive regime that, regretfully, first-world countries didn’t put enough into stopping or acknowledging until the tanks rolled South into Kuwait. If you’re gong to label yourself an ethical hacker, fine. Mangle the front-end of someone’s WordPress site. That said, you could be educating others on the Kurdish people by including a few links into your hack. I live in America, where certain news services use “Muslim” and “Islam” in headlines purely for shock value when they want to appeal to an audience so narrow-minded that their hearing is susceptible to the Casimir Effect. I recommend adding the wikipedia article on Kurdistan and the Al-Anfal Campaign to future hacks (and I’m sure Serwan could find more) to provide a little substance to your efforts unless, of course, your goal is just to be a stupid-ass script-kiddie hacker.

If you’re gonna hack, at least try to be productive. Meantime, this was a valuable lesson for myself on what to do to try to keep WordPress from falling into the same limbo during a time when I might not have had an hour to fix it.