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.
