More Details About a WordPress Attack Making the Rounds

Since the same type of attack has hit my websites on a second web host, I want to provide some more details about the attack I recently experienced prior to writing about why you need to update WordPress and your plugins.

Yesterday, I logged in via FTP to a separate hosting account on a completely different web host, and found some of the same signs that accompanied the original attack on my 1and1 account.

The first sign is a suspicious file in the root of the website. The filename is “.. ” — as in ‘dot dot space’

This is particularly insidious, because the filename is designed to make the file hard to find. This is because “..” by itself is a unix/linux standard for “parent directory.” (It’s the same way on Windows & DOS systems as well.)

Thus, if you aren’t paying attention and looking specifically for it, it’s hard to notice. Also, since most systems don’t give you any sign of the “space” in the filename, it’s hard to open the file. (Here’s where I have to give credit to a sysadmin at 1and1 for helping me discover the space in the filename. I kept telling him it was called “..” and he said, “that’s impossible.” He was right.)

Either way, I have found that you can simply rename the file and then download it via FTP to open it up and see what’s inside. Here’s the code inside the “.. ” file:

This is obfuscated somehow… perhaps encoded with base64 or some other method.

I’m not certain what it does, but my guess is that it only works when in combination with the code that was inserted into PHP files. Here are the filenames targeted by the attack:

  • wp-config.php
  • index.php
  • header.php

While index.php & header.php are common filenames in a wide variety of php websites, wp-config.php is unique to WordPress. Thus, I’m fairly certain that the creators of this attack were particularly interested in attacking WordPress sites.

The wp-config.php file only shows up in the “root” folder of any given WordPress installation. On the other hand, index.php appears in a number of folders in a typical WordPress installation. Here are a few examples:

  • the “root” folder of the site
  • the wp-admin folder
  • wp-content folder
  • wp-content/themes
  • wp-content/plugins
  • wp-content/uploads
  • the main folder of any given theme
  • the main folder of some plugins

The header.php file, on the other hand, is most likely to show up in one or more of your theme folders.

My guess is that whatever script gets uploaded to your server gets busy locating files that match those filenames and injecting the malicious code.

The code is intended to be hard to spot. First of all, the PHP files are edited without modifying their timestamps. Thus, they don’t look like they’ve been edited recently.

Also, the code contains an opening <?php tag, and then is immediately followed by 1183 spaces. This means that even if you open an infected file in a typical code or text editor, the malicious code will be so far off your screen that you won’t notice it. You can scroll down and see all of the untouched PHP code that you’re expecting to see in the file.

From being attacked in the past, I was already aware of both of those techniques, so I opened the files and scrolled all the way to the right, finding the code.

Here’s an exact copy of what’s being inserted into these files.

What Does This Code Do?

Well… the only reference to this particular attack that I’ve been able to find online is found in this thread (in German). That confirmed a suspicion I had held which led me to believe that there was something inserting some ad code into the WordPress admin pages (the “Dashboard” specifically) of my sites. Thus, it is only visible when logged in as an admin user, and is intentionally targeting WordPress site operators.

1and1 insisted that my sites were injecting malware into visitors’ browsers. Perhaps this is the malware. Perhaps the code was doing more than just displaying the ads I saw.

In any case, I had originally attributed these ads to a recently-added Chrome extension which I immediately disabled.

Now that I’ve seen the German thread, I’m more convinced that the sites which were displaying that ad were, in fact, the ones infected with this malicious attack.

So… I have no proof as to what this code actually does. It’s all obfuscated and it’s beyond my pay grade to figure it out anyway. My only hope is that by writing this up, someone (or perhaps more than one someone) will be able to use what I’ve discovered to help make sense out of it and put this sort of crap to an end.

If you have thoughts about this, don’t hesitate to comment below or hit me up on Twitter. Thanks.

Reason #478 to Update WordPress and Plugins

Dumb. Really Dumb.
Photo via BigStockPhoto.

We all know we shouldn’t let an old WordPress site sit around without updating it. It’s dangerous, they say.

And… for the most part, I’m really good about staying on top of this—at least when it comes to mission-critical sites. But… I’ll admit, there are a few sites that I built and forgot about.

One in particular came to my attention this week. It was a site I built around a hobby of mine. It needed a WordPress upgrade.

Okay… it had missed a lot of WordPress upgrades.

But worst of all: it had a plugin that was very old and had stopped being updated by its original developer. It was a stats plugin that I really loved back in the days before Jetpack gave us access to WordPress.com stats.

That particular plugin had a vulnerability which was exploited by some nasty malicious hacker.

How I Found Out I’d Been Hacked

This particular site was in one of my longest-standing hosting accounts… one I’ve had since 2006 with 1and1.com. I keep telling myself I’m going to clean that account out and move all the sites, but I just haven’t done it. That’s part of the reason I’ve let some of the sites go unpatched—because why patch ’em if you’re gonna move ’em, right?

<sigh>

Well… somewhere along the line, 1and1 started the practice of sending an email when they encountered something suspicious going on. In the past, they’ve notified my when SPAM emails started going out because of the TimThumb WordPress vulnerability and when their antivirus scanner found malware in a PHP file.

I’ve always been quick to respond when I see one of those, and it happened just a few weeks back. In that case, it just turned out to be an old inaccessible file that I’d renamed after fixing a previous problem.

On Monday of this week, I got another one of these emails:

Anti-virus scan reports: Your 1&1 webspace is currently under attack [Ticket XXXXXX]

Even though I was busy, I jumped right in to see what was happening. They identified a file that had been uploaded to my webspace, and when I saw where it was located, I knew exactly what was going on. That old plugin was still running on the site I mentioned earlier.

So… I logged in via FTP, downloaded a copy of the “malicious file” just so I could see it, and then deleted it and the entire plugin that it got in through.

No big deal.

Or so I thought.

Sites Down

Yesterday, I discovered that all of the sites in that hosting account were down. For most of them, I was getting a simple “Access Denied” error from 1and1 when I tried to load them up in my browser.

A minor panic set in as I went in and tried to discover what was going on.

What I found was very perplexing. The file permissions on the index.php file, the wp-config.php file, and a handful of other files in these sites were changed to 200.

If you aren’t familiar with Linux file permissions, 200 basically means that the file can’t be read by anyone. So… if that file happens to be critical to the running of your site, then… your site doesn’t work.

So… I changed the permissions on a couple of these files in one of the most important sites just to try to get it working. Oddly… within a few minutes of me setting the permissions to 644, they were automatically changing back to 200.

“Hmmmmm…. maybe there’s some malware still running in my account,” I thought to myself.

That’s when I noticed a whole bunch of database “dump” files in the root of my webspace. They looked like this:

dbxxxxxxxx.dump.lzo

Uh oh.

So… I replied to the email I’d gotten a few days earlier, and explained what was going on. This updated the “ticket” in 1and1’s Abuse Department so they could have a chance to respond.

After working on things for a few more minutes, I couldn’t stand it any longer. I dialed the 1and1 Support Department (something I truly hate to do) and waited. Within a short time, I was on the line with someone from India who had undergone a significant amount of accent reduction, and explained what was going on. When he was unable to find my ticked ID, I explained that I’d gotten an e-mail. He put 2 and 2 together and connected me with the Abuse Department.

Then… for the first time in the 8 years that I’ve had this account, I spoke to an American. I mean… fluent English. Clearly no foreign accent. And also for the first time, he knew something about what he was talking about!

He reviewed the ticket and was able to explain a little better what had occurred. Hackers had gotten in through unpatched software (which I knew) and had managed to execute shell commands with my account’s user privileges.

Within what must’ve been a very short period of time, they inserted malicious code into approximately 1,500 files in my webspace. This means that they infected even the WordPress sites that were all patched and running the latest versions.

All told, somewhere near 40 sites were infected.

1and1’s systems were automatically changing the file permissions for any infected files to 200 in order to keep anyone from accidentally downloading malware when visiting my sites.

So… then began the painstaking process of removing all the malicious code that had been inserted and bringing the sites back on line one by one.

Could This Happen To You?

Yes. And it’s just a matter of time.

I’m planning to write In this post, I provided more details about it and an update explaining exactly what to do if you fall victim to an attack like this. It’s not particularly difficult to fix, but if you have 1500 files across 40 sites affected, it’s gonna take some time.