Possible security issue: Warning: fsockopen() [function.fsockopen]: unable to…

I’ve searched the web and I see that nobody else has written anything about this possible security issue with WordPress so if I’m mistaken I apologize, but in the spirit of “If you see something, say something,” here it goes.

The other day I started getting the following error at the top of every page:

Warning: fsockopen() [function.fsockopen]: unable to connect to 176.123.2.3:80 (No route to host) in /home/xxxxxxxx/xxxxxxxx.com/wp-content/themes/default/consumer.php on line 40

I hadn’t changed anything in more than a week, so I didn’t understand why this message was appearing. And the IP mentioned had nothing to do with my website.

I copied the site to my local hard drive and I started searching for the offending IP and where it was being called.

Here’s what I found:

• The IP was written in a file called config.db
• This config.db file was timestamped a few days earlier and therefore had a date completely different from all other files. It was created by someone or something that wasn’t me.
• The config.db file was located in an “images” directory, which usually was created at the same time as the file and was empty except for that file.
• The rogue “images” directory and its “config.db” file were added into my themes and plugin directories (not all).
• A file called “consumer.php” had been added to my theme directory. This is the file that contains the function that imports the IP from config.db and attempts to contact that IP. Since the IP doesn’t seem to be working now, the error message is generated.
• Finally, the “header.php” file was modified. A call to the functions in consumer.php file is made immediately after the body tag. The call is hidden by adding many spaces to the right of the body tag so that the rogue function call is off screen in most editing programs.

I have contacted my host and they told me they are looking into it. Since the rogue images/config.db have appeared all over my hosting account and the timestamps cover a few hours, I have the feeling that some kind of virus action is going on at a server level, not just on my account. But this is my deduction not based on any report from the host.

If you search the warning I quoted above you will find a number of websites in google that have this same problem, with the same IP. But, as I said, I found nobody talking about the problem and how to fix it.

Some of the sites that Google returns with this warning text also have an advisory from Google itself stating that these sites contain possibly dangerous content. Probably due to what is going on with the code that I have highlighted.

Of course if the IP in the warning were working correctly, there would be no warning message in WordPress and therefore I would have never noticed that something bad was happening. Pretty scary.

So, how to fix it? I’ve done the following:

1. Check your original theme ZIP. It’s likely that consumer.php was not included. If it wasn’t, delete it from your theme directory.
2. Re-upload the original header.php file. If that’s not possible, simply remove the offending require_once(dirname(__FILE__) . '/consumer.php'); call that is on the same line as the body tag.
3. Go through your directory tree using FTP and delete config.db files, especially if you see that they have a different date from all the other files in the directory.
4. In many cases, the config.db will be the only file in the “images” directory. If this is the case, delete the images directory as it is not required.

I have implemented these steps and so I no longer have the warning at the top of every page. However, I still don’t have any information as to HOW this happened. Any news from anybody else with more info would be greatly appreciated so we can try to plug any holes so it doesn’t happen again.

Note to WordPress – I think this is a pretty critical problem that you need to look into, especially since I found lots of sites in Google that seem to have the same error. Fortunately the rogue IP wasn’t working so I caught the problem. If instead the IP had been working, who knows what would be happening with my site and its users….