'Design Flaw' Led To Wave Of Attacks On Hundreds Of WordPress Blogs
Database storing user credentials in plain text gets hacked
Hundreds of WordPress blogs were hacked during the past few days by attackers who pilfered blogger credentials stored in plain text in the database.
The researchers who discovered the attacks say a design flaw in the WordPress blogging platform was the underlying problem because by default it allows users to set up permissions that let anyone read their blog's wp-config.php file configuration files, and because WordPress stores the bloggers' credentials in plain text.
More Security Insights
- Forrester Study: The Total Economic Impact of VMware View
- Securing Executives and Highly Sensitive Documents of Corporations Globally
- Top Big Data Security Tips and Ultimate Protection for Enterprise Data
- Client Windows Migration: Expert Tips for Application Readiness
The attackers injected malicious iFrames into the blogs so that any visitors would automatically be infected with malware, including code that spreads fake antivirus software.
"A few people got hacked last week and asked us to help," says David Dede, founder of Sucuri Security, which also uses WordPress for its own blog. "We fixed them and in one site, just after we fixed it, it got hacked again. Looking at the logs, we didn't see any access in there at all, so the attack didn't come from the Web."
Dede says after further analysis and more complaints of hacked blogs, he and his team found that the blogs were getting hit with a malicious iFrame, and that the blogs were all hosted on Network Solutions' servers. Most were running the newest version of WordPress, 2.9.2, he says
The attacker basically created a scanner to locate all configuration files containing incorrect permissions, Dede says. "It read the database credentials from there and started hacking everyone," he says.
Network Solutions has now cleaned up the infected blogs and stopped the attacks by changing database passwords for WordPress. The hosting provider recommends that WordPress users log into their accounts and change their administrative passwords, as well as delete any administrative access accounts they don't recognize.
WordPress, meanwhile, says it hasn't seen any evidence that the attacks were related to a security problem with its software. Barry Abrahamson, systems wrangler for WordPress, says the attacks appear to have targeted weak file permissions. "File-level permissions and Web server security are the responsibility of the hosting environment, not the application," Abrahamson says. "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."
If a blogger wants to check if his site was hacked, then he should look for extra HTML in the header and view the source for any iFrames pointing to http://mainnetsoll.com/grep or http://networkads.net/grep, he says. "They can [also] try installing the WordPress Exploit Scanner plug-in," Abrahamson says. "The database scan portion of this plug-in should catch if a malicious iFrame code has been inserted into the options table in their database."
Contact your hosting provider if you find either of these issues, he adds, and ensure you're running WordPress 2.9.2.
The good news is the attacks were not as malicious as they could have been, Sucuri Security's Dede notes. The attackers modified only the site URL, he says. "So they were actually nice," he says.
Dede and other experts say the attacks suffered by WordPress could happen to most any popular blogging platform: "It's a hard problem to fix. They need the credentials stored somewhere, and the Web server needs to be able to read it," Dede says. Joomla, Mediawiki, and other blogging platforms that are set up the same way are also vulnerable to this type of attack when the permissions in the configuration files are set up incorrectly, he says.
Encrypting the credentials isn't an option because the keys have to be stored where the Web server can read them in order to decrypt the data, he says.
There's no way to decrypt the credentials for the database without accessing the database, WordPress' Abrahamson notes. "We would have to store the decryption key in another file somewhere on the file system. 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?"
The users erred by setting up permissions for anyone to read the configuration files, Dede notes, although that was the default on WordPress. WordPress now is no longer recommending this, however, he notes.
Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.