It seems after the brief period of quiet and uncertainty the main cause of the vulnerability attacking WordPress blogs was revealed. The security magazine over at darkreading.com noted that is was the storing of critical information as plain text in the database is what left users exposed.

Earlier i had noted that there was a problem with sites going down, and on a variety of different hosts as a result of some malware, that used SQL injections.

“The attacker basically created a scanner to locate all configuration files containing incorrect permissions” – darkreading.com

From there the bot would then mine through to the database and inject the malicious iframes into the post content, and as a result all the visitors to the site would be infected  by malware.

It seems however, that the problem actually is the result in a flaw in the design of WordPress itself. This is because the loose permissions that the configuration files that were read are the default WordPress installation permissions.

Another important thing to note is that this is not actually a problem with the core code but a permisions problem. This is why over at WordPress the word was that there were a number of unanswered questions to around the circumstances surrounding the setup of these blogs.

As a result  Barry Abrahamson, a systems engineer at WordPress noted,

“WordPress can be installed a number of ways, and many hosts have built custom installers. I am not sure how WordPress was installed in these cases.”

From his prospective Abrahamson, also focused more attention on the hosting providers as the ones who should be on top of file permissions as he noted that,

“file level responsibility of the hosting environment, not the application.”

To some extent i think that this is true however, when the default permissions set by the application leave it at risk for exposure to injection attacks, they should make the changes within the application to protect their users.

This explains why  hundreds of blogs were able to breached at the same time. Essentially the fix for this one to make sure that your settings files like the wp-config.php and any other internal files have the correct permissions.

Also check with your host what the permissions are on your server and if they are secure enough to prevent your site getting attacked like this.

Again a clear example of why site permissions matter.