I haven’t had the time to write about much WordPress news lately but after reading the post published on the WordPress developer blog regarding Network Solutions, it might have been for the best.

There have been a number of WordPress based sites hosted on Network Solutions that have had their databases compromised but overall, the issue was not directly targeted at the company. There has also been an ongoing discussion in the WordPress Tavern forums regarding all of the information surrounding the attacks. I’ve been keeping an eye on my feedreader to view the thoughts and opinions of many different websites all following and reporting on the story and if you didn’t know any better, you’d think there was a major exploit in WordPress 2.9.2. As Matt points to in the dev blog post, many websites reported this as a WordPress security issue.

However, Matt’s response is a direct conflict with what Network Solutions has stated. First, Matt’s response.

WordPress, like all other web applications, must store database connection info in clear text. Encrypting credentials doesn’t matter because the keys have to be stored where the web server can read them in order to decrypt the data. If a malicious user has access to the file system — like they appeared to have in this case — it is trivial to obtain the keys and decrypt the information. When you leave the keys to the door in the lock, does it help to lock the door?

What Network Solutions has stated:

Although this issue is not with our hosting servers, we can help you clean this issue up and restore your site to a previous backup. However, this may not guarantee that the issue will not occur again. We are working with the WordPress community and affected Network Solutions customers to help determine which WordPress theme or plugin that may be causing this issue and we will update this post as we learn more.

We continue to look out for our customers and our security team is reviewing logs to determine which WordPress instance or plugin may need to be fixed. We have also been working with experts in the WordPress community on this issue.

It will be interesting to see if anyone from Network Solutions will come out and vouch for it being a permissions issue that caused all of the problems. Until then, we won’t know for sure if that was the case. Andrew Nacin who is also one of the core developers of WordPress has requested that a proper explanation be given that sets the record straight.

There are two posts in the Tavern forum thread that I wanted to bring to light here that might help others when it comes to directory and file permissions.

ChipBennett – So, I’m not experienced with administrating shared server environments. Wouldn’t setting wp-config to 0640 prevent this attack, even if all else were held equal? (Apparently, only WordPress installs for which wp-config.php was 755 were getting compromised.)

Otto – 640 or 750 indeed prevents this.

The reason WP doesn’t check for that is two-fold:

1. On a standard server with a basic and straightforward configuration, The site will fail with 640/750 on wp-config, because Apache won’t have rights to read the file. For 640/750 servers, you must be running suPHP for it to work. suPHP lets Apache run with the user credentials. Many, many hosts don’t run with suPHP.

2. On a single-site box (dedicated), you don’t need to worry about other users reading your files, since hopefully you have no other users. So requiring esoteric configurations makes that setup harder.

Basically, shared hosts *NEED* to run suPHP in order to be secure. suPHP prevents webapp attacks from moving outside their personal sandbox, and it allows users to set xx0 file permissions to eliminate other users on the box from reading their files.

But, suPHP is not the default configuration, so unless the host knows their stuff, they don’t do that sort of thing.

I’m also going to link to the following articles as they contain some great information regarding WordPress sites being hacked and how to harden the software.

http://codex.wordpress.org/Hardening_WordPress
http://codex.wordpress.org/FAQ_My_site_was_hacked
http://ocaoimh.ie/did-your-wordpress-site-get-hacked/
http://www.devlounge.net/code/protect-your-wordpress-wp-config-so-you-dont-get-hacked
Top 5 WordPress Security Tips You Most Likely Don’t Follow

There is an aside to this entire series of events. While Network Solutions was doing an admirable thing keeping their customers updated via a public blog, other agencies picked up on the news and considering it’s a blog for a known webhosting company, took their facts for face value. This was like a bad wildfire that kept spreading until the official WordPress development blog post was published today, putting a damper on those flames. I was very close to writing about the security issues being reported and if I did, I would have linked to the relevant articles and I probably would have added fuel to the fire. I wonder if Network Solutions should have kept their customers updated in a different method than one that was so public. Also, none of the articles that I read concerning these security events quoted Mark Jaquith or Matt Mullenweg confirming that there was a specific issue related to the WordPress software. Mark did give a rule of thumb to Network Solutions regarding permissions.

“the most restrictive permissions that still work.” File permissions vary from server setup to server setup, Generally, “644″ is recommended for wp-config.php. For public_html, it is usually 755.

Let’s keep an eye on the Network Solutions blog to see what they say.