WordPress .htaccess Hacked and Fix – We Hope

UPDATES AT BOTTOM (CLICK TO SKIP TO THE LATEST)

This won’t be a funny post. It’s more of a PSA to help anyone else affected by whatever it is we were all affected by.

Confused?

So am I.

As a blog designer, although I certainly do more, I’m often the first point of contact if someone has a problem with their website. Especially if I’m the one who built it. Just as I should be!

Today, I was bombarded with emails, contact forms, and Facebook messages from people who noticed that their sites had been hacked and rerouted to various websites in India and (I believe) Russia. While TellingDad.com wasn’t hacked (yet), my other website was a victim as well. As was my staging platform where I build sites before publishing them for launch.

What’s odd about the latter is that the site is hidden from the search engines so there shouldn’t have been any reason for it to be seen by a bot. This led me to believe that it had to have been a server-related vulnerability. Or, perhaps the hack was able to access other areas of the server once it infiltrated the code somehow. This is WAY out of my knowledge zone but my suspicions may have been confirmed when Trisha, from MomDot, noticed that sites she never even published were infected. Even folders that were just sitting there awaiting files were infected.

While I don’t know the vulnerability that caused it, I wanted to see if it could be resolved. It took about an hour to determine what was manipulated, and ultimately, my fix seemed to work. It looks as though the injection took place at about the same time, almost like dominoes, sites were dropping and redirecting to these bizarre websites.

What follows is a step-by-step look at what I did to resolve it. As of the time of this writing, I’ve fixed 23 sites with the following method. Of the 23, I had done work on 12 of them. The other 11 were people who either reached out knowing I had fixed others or reached out because they thought I was some techie-geek. The geek part, yes. Techie part? Barely.

So, and it’s absurd that I have to even say this, but any suspicion that I’m somehow at fault or the cause or the man behind the hack is ludicrous, unfair, and just plain stupid. I gave up well more than half of my workday to fix other peoples’ issue without any request for payment. Two offered and sent PayPal after their sites were restored, which I greatly appreciated since I did nothing but work on hack fixes all afternoon, lol, but I never asked for a penny.

This, plus the fact that I was hacked, should be plenty of evidence that my presence on Facebook to answer questions and my willingness to fix the issue for people is because I like to help…not because I enjoy doling out hacks and then hogging up precious hours to fix them for free. I know how fun rumor mills are so I want to get any threat of that put to rest right off the bat. I’ll repeat it, I never asked for a dime. I only offered to help. Hopefully those I assisted will go to bat for me. Nada, zilch, nothing. And I couldn’t care less.

With that, here are the steps I took to clean the sites. If your site was hacked and you have no clue what the following steps mean or how to do them, reach out to me, and I’ll clean your site so long as I’m awake and have time. But, if at all possible, do it yourself as it’s always good to have a handle on how to manage your site.

1. Login to your host server via FTP and get to your blog’s root installation folder. You’ll see folders like /wp-content, /wp-includes, /wp-admin, etc. if you’re in the right place.

2. Either download the .htaccess file to open it in Notepad or edit it server-side and you’ll most likely see that your .htaccess file has been changed. I have no clue WHERE it’s being redirected because the destination URL appears to be random. But, if you don’t see the following in the .htaccess file, then you need to delete the text and replace it with this:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Note that this is the raw WordPress htaccess file that is initially installed. If you made modifications to it before the hack, those changes are most likely gone and will need to be replaced.

3. Save your newly corrected .htaccess file and then stay in that root directory. You should see a file called default.php. If you edit that file, you’ll see a bunch of garbled code that is obviously encrypted. Rather than delete the default.php file, I simply renamed it “defaultDEAD.php” so that it couldn’t be called. The reason for this is because I want to have something to compare it to if the hack regenerates itself (which it very well may). I’ve since been told that it’s okay to delete these default.php files so that scanners don’t throw a false positive for infection.

4. With your root directory now fixed (htaccess file and changing the name of the default.php file) access your blog’s /wp-includes folder. You will most likely see an .htaccess file and the same default.php file here as well. It just depends on how deep the hack went into your site. Some sites had it trickle into every folder, and some didn’t. Delete the .htaccess file and change the name of the default.php file. Don’t just overwrite the htaccess, it’s okay to delete it here. Only leave the htaccess file in that root directory.

5. Within this /wp-includes folder, also do the same in the /pomo, /SimplePie, /Text, and /theme-compat directories. Not everyone had the .htaccess and default.php files added into these folders, but some did, so just check to make sure. If they are there, delete the htaccess file and change the name of the default.php file. As mentioned above, I used defaultDEAD.php.

6. Now go back to the root folder. This time, choose the /wp-content folder. You should see it there, too. Do the same step…delete htaccess and change the name of default.php. Now access the /plugins and /themes folders to see if the hack trickled there as well. This was about 50/50 for me. Not every site had the hack represented there. Check anyhow!

7. Go back to the root folder. While there is still a /wp-admin folder that we haven’t checked, I have yet to see the hack represented there. Check anyhow and check the sub-folders. Just in case, although I saw 0 with it there.

If you got them all, then your site should come back to life. These are the exact steps I followed after finally figuring this out so I hope it helps others.

Bear in mind that I’m not 100% sure that this completely eliminates the threat. While it does get rid of the hack’s imprint and brings the site back up, I don’t know if it’ll just regenerate itself at some point. Hacks and vulnerabilities are WAY, WAY, WAY out of my wheelhouse so I’m just hoping this keeps it at bay until someone smarter comes along and shuts down whatever the vulnerability may be.

I don’t know if it’s a plugin, I don’t know if it’s WordPress, I don’t know if it’s Apache…I have no idea. I know it’s not one specific host at fault because those reaching out to me are hosted with a wide range of companies. For now, consider this a duct tape fix, and not a total solution. While I HOPE it turns out to be a total solution, I doubt it, because whatever vulnerability existed to allow it, it certainly hasn’t been closed yet.

I’m keeping watch, hoping the fix holds, but it might regenerate itself. If it does, follow the above steps. It sucks, I know, but it’s better than a dead site while waiting for it to make its rounds to security personnel who actually understand this stuff.

Again, if you’re totally lost, feel free to reach out through my contact form. If I can, I’ll help you. NO CHARGE — to those who think this is some get-rich-quick ruse — shame on you. I had simply fixed the hack on my site, offered to share what I had found, and then some took it upon themselves to drum up ludicrous conspiracy stories. Can’t it just be one guy doing others a solid without anything requested in return?

Anyhow. I digress. If and when I’m privy to a permanent fix, I’ll post it here.

Good luck!

__________________________________________________

UPDATE: 6:30pm EST

In case there are computer wiz’s out there, my TellingDad.com site wasn’t entirely hacked to where it was brought down but I DO see the same offending files there. However, the .htaccess file is different. It’s as though it’s there waiting for instructions.
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^[a-z0-9]{1,4}[.](htm|pdf|jar) default.php [L]

# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

The default.php file is there (and it shouldn’t be) but my site is still working. However, it looks as though the .htaccess code is ready to blow up based on the encrypted code within default.php whenever it’s triggered. See, if the site isn’t working, that htaccess code pasted above would have an actual URL in the RewriteRule line, NOT a command for it to generate the random URL to use.

This in mind, EVERYONE needs to check their sites via FTP to see if this exists and remedy it before it blows up.

________________________________________________

UPDATE: 11:30pm EST

Shutting down after 11+ straight hours of hack fixes and virus hunts. Tomorrow will prove to be a BIG sign as to whether or not the hack is set to regenerate daily. I hope not. I determined that those I had helped had out-of-date WordPress installations and plugins. I’m hoping that the combination of file cleansing + updating will eliminate the threat. Too early to tell. That said, it is imperative that you keep your WordPress up to date because they aren’t just features…they’re also security updates. The longer your site sits around without updating, the greater the odds that you open yourself up to vulnerabilities.

I’m still a bit bent out of shape that a few chose to spread ridiculous rumors because of how quickly I offered to help, but I can’t say the source shocked me. While I know who it was, I’m not saying, because it’s simply not worth it and I refuse to stoop to the same level. I’m just glad that many of those I helped opted to vocalize their thanks.

I spent ELEVEN hours doing these fixes and investigating for people…I put more than an entire working day aside. Not for me. For them. I asked for $0 in return and I can’t fathom how anyone could be so petty to think I had some ulterior motive. I deserved better than what the drama-mongers took it upon themselves to do. I had nothing to do with this hack…one that’s been around for years in various strains…and I can go to sleep happy, knowing 32 sites that would otherwise be offline, are up and running as of tonight. Knock on the proverbial wood!

So, with that, here’s to a hopefully peaceful “morning after!”

________________________________________________

UPDATE: 10:44am EST (the next day)

I’m not going to say “so far, so good” because it’ll jinx it, but if I WERE inclined to say it, then I would have this morning. 33 sites fixed thus far and I haven’t seen a recurrence. That doesn’t mean there won’t be if there is a backdoor exploit, so it’ll be a very nervous few days as we wait to see if it makes a comeback.

To those who have yet to see a problem but are on an older version of WordPress, you need to stay updated. As per a security report I found in my travels last night:

“Malware entry: MW:REDIRECTION:121

Description: A malicious redirection modifies the .htaccess to redirect users to a TDS, which then pushes the user to fake AV or spam sites. We are seeing it often on outdated Joomla and WordPress sites.

Affecting: Any web site (most common on WordPress).

Clean up: Malware is hidden at the .htaccess file.

Last update: Jan/2013″

If you’re afraid to update, you’re only delaying the inevitable. I’m hoping these sites stay clean because I dread receiving a deluge of 33 “It’s back” emails. Come on WordPress, keep it together!

________________________________________________

UPDATE: 1/29/13 11:00pm EST (the night after)

Well, the fix didn’t hold. With two sites affected, I tried two different patches to see how they behaved if the problem repeated itself. I have spent nearly the entire day trying to research this and even downloaded a known affected site to go file-by-file and compare it to a raw wordpress installation. Nothing! I used multiple scanners, file searches, and more but there were zero threats. Not only that, but I searched files manually to try and find the 64base code that causes these things…nothing.

This leads me to believe that it’s server related but I really have no idea. I mean, it COULD be a WordPress issue but I’m reading a ton of stuff that states if a site on a shared server environment is infected then it can crawl through and hit nearly everyone on it.

I have scanned three different sites thoroughly and zero threats have been found. Yet, the .htaccess file is still being overwritten and new .htaccess files are still being added to the /wp-includes and /wp-content directories.

So, even after cleaning, the main .htaccess file in the root was edited and an .htaccess file was added in each of those two mentioned directories…even after being deleted prior.

Following Trisha’s lead on changing her .htaccess file to read-only, I have tried two things tonight:

On Site A, I made the root’s .htaccess file read-only and just deleted the .htaccess files from /wp-includes and /wp-content

On Site B, I made the root’s .htaccess file read-only. I then created EMPTY .htaccess files for /wp-includes and /wp-content and set those to read-only.

What I want to see is if it’s able to still overwrite these .htaccess files. If all .htaccess files are overwritten tomorrow on both Site A and Site B, then I’m back to square one.

But, if Site A’s root .htaccess file is untouched and the .htaccess files regenerate in /wp-includes and /wp-content, then I’ll check Site B. What I’m hoping is that the read-only setting prevents the script from adding/editing those empty files. If it works, then it should keep the virus at bay until I can hire a specialist to find the original cause.

So, we’ll see what happens and I can’t wait until this nightmare is over. It’s cost me two solid days and hundreds of dollars in lost productivity, but I just know I’m in a better position to help than leaving people to fend for themselves. I’m just happy that my existing clients understand and are staying patient knowing I’m not out goofing around. I just wish I didn’t have to be tethered to my computer for 12-hour stretches working on this.

In short…hackers suck.

More tomorrow!

________________________________________________

UPDATE: 2:15am 1/30/13 (I should really be in bed)

I’m starting to read about other occurrences of the exact same problem and it doesn’t appear to be limited to WordPress. I’m not 100% certain it’s a server exploit but the evidence is surely starting to point in that direction. It’s as though it creates a rolling infection that blitzes through other folders/sites on the same server. Time will tell, but I’m spent tonight and my brain is mush.

Anyhow, for additional review: http://www.webmasterworld.com/apache/4535610.htm

________________________________________________

UPDATE: 5:15pm 1/30/13 (2 or 3 days after, who knows, I’m frazzled)

Well, the fix mentioned above with regards to changing the .htaccess files to read-only access (0444) seems to be holding up. While I’m knocking on wood as I write this, it’s a promising sign that it hasn’t returned when (after updating to the latest WordPress version):

1. The .htaccess file that’s supposed to be in the root directory is set to read-only (chmod 444).
2. Blank .htaccess files in the /wp-content and /wp-includes directories are set to read-only (chmod 444).
3. Any of the offending default.php files are deleted (if you see encrypted base64 code, it’s an offender).
4. All relative passwords are changed (FTP and WordPress Admin specifically).
5. You sacrifice a goat.

Step 5 is optional. Just making sure you’re paying attention. While this MIGHT, MAYBE, PERHAPS WILL stop the script from infecting your site, it still doesn’t solve the problem…it doesn’t close the exploit. Or maybe it does. I dunno. I just know that with these safeguards in place, we have yet to have a regeneration. That’s a very positive sign but we’re not out of the woods yet.

I have hired a WordPress security expert to look into this and I’m hoping that together we can figure out the vulnerability. Between server logs, file scrubbing, and analysis, I’m hopeful.

I’ll continue to keep you posted but I really need to get back to my design work before clients arrive with pitchforks and torches in hand. Although they’re all apprised of the situation and are being fantastic as I deal with this. Lord knows they’ll want the same dedication should it happen to them…lord I hope not.

________________________________________________

UPDATE: 12:15am 2/2/13

The fix mentioned above now has a 64-0 success record versus a recurrence. That’s huge. I don’t know how many people actually did #5 but we should collectively thank them in case it helped.

I took the day to visit each and every client’s site to verify against the hack and only found two infections. Both of which are on blogs where I no longer have access and one of the two hasn’t been updated in nearly 11 months. I reached out via email so we’ll see.

Anyhow, the point of this update is to report that I’m done with updates. At least until something breaks to where it’s relevant to update again. If you’re looking for WordPress protection, I would recommend Wordfence. It’s a free plugin (although the $17.95/year paid version looks well worth it) and it’ll provide excellent protection against vulnerabilities and attacks. I can’t say it’s impervious, but that’s mainly because all this is out of my wheelhouse. But, based on significant research as I battled this thing for three days, it’s regarded as being top-notch.

I hope this continues to help people who face the same issue. I should say that three people incurred actual malware being injected into dozens of .js files but I’m not 100% sure it was related to this hack or if it was a different one. With only 3 instances, the latter is highly likely. To clean those, I simply followed the steps above and then re-uploaded the /wp-admin and /wp-includes folders from the latest WordPress download. I renamed the offending folders /wp-adminOLD and /wp-includesOLD just in case they needed to be reviewed. This eliminated the malware.

If you need help, comment below or just reach out. I know many of you emailed saying you wanted to keep your site private and that’s okay. No need to tell the world, just use my contact form.

Best of luck to those who have the issue and I hope the above steps help you!

________________________________________________