welcome to somewhereville (.com)

From The "Hopelessly Hacked Help" Department

Below is the process I went through to clean up a WordPress site injection into www.cnyo.org – an old astronomy club I directed and a site (now unused) that I still maintain/keep active because there's lots of (a) good information and (b) CNY-based astronomy history to be read. There are many, many files in a WordPress install that can suffer an attack of some kind, many, many ways for a hacker/bot to make such an attack happen, but only a few things everyone seems to recommend doing to try to make the problem go away. In my case, the problem with the website went away after simply renaming two folders, uploading new versions of those folders, and then using the success of that replacement step to find the exact files in the site that were causing me issues. Consider this post a "First Step" if you find yourself similarly inconvenienced.

Some Light Reading (Background)

The CNYO website had, up until quite recently, a bug in the main menu that I initially chalked up to a very old (and free) theme (Vortex) running up against recent updates to WordPress. The romantic perspective on the maintaining of the site mentioned above aside, the site is really only still up because it (a) costs me nothing and (b) is now hosted in a subfolder of this website, and the site only gets a few visits each day (even with the upcoming solar eclipse in Western New York, cnyo.org is crickets). I hadn't much bothered exploring the menu issue further. The specific issue is shown below for the front page of the website, with the "About" menu much larger vertically than all the other menu items and the sub-menu items inside of "About" equally expanded.

Interestingly, this oddity started appearing in Firefox and then, after a year or more, began appearing in Chrome and Safari. Clicking on the About link produced the image at the link below, which was a full-blown insertion of unwanted content and a de-columning of the website (and, even worse, it shows two fewer people subscribed to the site!).

See: Link to a very long and unnecessary-to-render-here screencap of the old contaminated About page.

While making tweaks to the rochesterastronomy.org website and un-doing a menu expansion that shouldn't have been, I decided to check back on the CNYO site to see if I could play the same trick. And I couldn't. But, in exploring how to tailor the css in browser Developer Tools, I noticed a slew of embedded links and class="r67298bc6" calls that I had not previously for Klonopin/Clonazepam.

Klonopin is "used to treat panic disorder (including agoraphobia) in adults." I am 100% for adults overcoming anxiety about being outdoors (because I do astronomy) or with groups (because being outside in the middle of nowhere while observing by yourself can get old when the first howls are heard). That said, advertise by injecting something into someone else's WordPress, please.

Files And Tools To Have On Hand

It's a short list, things you probably have on hand or quick access to anyway if you're maintaining your own website (self-hosting or, at least, self-sufficient on your hosting service), and things you should probably always have at-the-ready for when (not if) the situation calls for them.

1. A local copy (on your computer) of the WordPress version your site is currently using. To be even more exhaustive, have copies of EVERYTHING installed on your site. Themes, plug-ins, custom css, media, etc.
2. An FTP client of some kind (such as Filezilla)
3. All the needed credentials to get into your site by (s)ftp
4. A browser's Developer Tools to do that cursory inspection of whatever looks off (all modern browsers have this option, snoop around the Tools menu)
5. Access to your site's database (likely phpmyadmin if you're running a WordPress site on a major hosting service)
6. A tool for comparing the contents of folder A and folder B – this is how you'll find the difference in the content of the before/after files to see which file or files has/have been modified
7. stackoverflow open. This link, this link, and this link were early first reads on my path (the third link was insightful, but it turns out my problem was in a WordPress core folder itself).

Step 1 – Replace WordPress Files (Carefully!)

A quick check that might save you several hours. This assumes you've done nothing to the contents of wp-admin and wp-includes, which is a pretty good assumption unless you dabble in .php files. All of your themes, plugins, and uploads are in wp-content.

1. Uncompress your local copy of WordPress to have all of the core files/folders accessible for uploading
2. Log out of your WordPress site if you're logged in (you probably don't have to do this)
3. Get into your site account's directory with your (s)ftp client
4. Rename wp-admin to wp-admin-old and wp-includes to wp-includes-old
5. Upload the local WordPress copy's wp-admin and wp-includes
6. When done, hit RELOAD on your problematic site.

For www.cnyo.org, my problem went away completely.

Step 2 – If Needed, Replace More WordPress Files (Very Carefully!)

My next step would have been to VERY CAREFULLY inspect and/or replace the .php files in the main directory (in the image above, index.php and downward, not touching .htaccess or .user.ini until a "Step 2b" when I found past versions to compare these to).

My next-next step would have been to go into wp-content with backup copies of my themes and plugins, but I would have done this VERY, VERY CAREFULLY.

Usual reminder from other sites – make sure you have a copy of wp-config.php somewhere, else you're in for a very long evening if you do something unwanted.

Step 3 – Inspect The Database

I started here, as it seemed the most likely culprit based on lots of searching for similar issues. Consensus among several discussions was that searching for the keywords:

eval, gzinflate, shell_exec, base64_decode

in your database would produce the maximum bang-for-buck. As it happens, only "eval" existed in the CNYO database and, sadly, "eval" is a common combination of four letters on a science-based website (so 100 hits, many of "evaluation").

I was fortunate to do this first-pass, find little that looked problematic, and move on to Step 1 above instead.

Step 4 – Transfers Worked? Now Find The Problem (Locally)

For the academically curious… the wp-admin and wp-includes replacement solved my problem. Doing the next logical step of renaming the new wp-admin to wp-admin-new and renaming the old wp-admin-old to wp-admin (alphabetically, of course), I found the site remained in its original, untouched state – placing the problem file(s) squarely in wp-includes.

To find the official location, one needs a tool that will compare the contents of files and directories. In OSX, this is FileMerge in Xcode (search for the app or Command-Space Bar and type filemerge.app (see this link on stackexchange for a how-to). If you don't have Xcode, similar comparison tools exist on all OSs.

To start this, I moved wp-includes-old to my local machine so as to perform this comparison in filemerge. I renamed it to wp-includes in the pic below.

Once open, select the wp-includes in your clean, unzipped WordPress folder as the Left folder, then select the wp-includes(-old) as the Right folder. And run Compare.

Clicking on "Identical" on filemerge's righthand side to exclude all identical files, the list of changed files from old-to-new is small, with the offending .php file identified as temdfpg.php, which calls a .quota file that looks something like below:

php $IBmtKwVMuXQGpgbUH='ur'.'ld'.'ec'.'od'.'e'; … lots of and lots of scribble ... %22%2F%3E%3C%2F%73%62%65%7A%3E'));exit;

Problem identified, problem solved. All in all, I suspect I got lucky in doing a few very simple things to narrow down the location of the problem. I will hope for similar luck next time.