Network Solutions mops up after mass WordPress breach
Plenty of blame to go around
Agentless Backup is Not a Myth
Administrators at web host Network Solutions say they've closed a hole that allowed attackers to commandeer a large number of sites so they tried to infect visitors with malware.
The mass hack caused Network Solutions customers running WordPress to silently redirect visitors to networkads.net/grep, a site that attempted to perform malicious drive-by downloads. Network Solutions has now closed the hole by resetting database passwords for the blogging software, the company said Sunday. Users should also review their settings for any administrative access accounts that aren't recognized and if found delete them.
The compromise was the result of database credentials that WordPress stores in plain-text, according to David Dede, a researcher with Securi Security. While the database is supposed to be accessed only with the Apache webserver, "lots of users" configured the file so it was readable by any Network Solutions customer.
A malicious user then employed a script that automatically scoured the Network Solutions system for poorly secured accounts and, when found, modified the databases so the corresponding websites redirected users to the malicious website.
"So, at the end anyone can be blamed," Dede wrote. "At WordPress for requiring that the database credentials be stored in clear-text. At WordPress again for not installing itself securely by default. At the users for not securing their blogs. At Network Solutions for allowing this to happen."
To clean up the mess, Network Solutions had to change the database passwords for WordPress, which will likely cause problems for customers who use scripts that automatically access the file. The Network Solutions blog post doesn't say whether changes have been made to customers' wp-config.php file, so users should check to make sure it's set to private by running the command "chmod 750 wp-config.php." ®
Update
A representative for some WordPress developers wrote in to take issue with Dede's claim that at least some blame rested with developers of the blogging software.
"WordPress, like all other web applications, must store database connection info in cleartext," wrote Paul Kim VP User Growth at Automattic Inc., which employs some of the core developers for WordPress. "Encrypting 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. If a malicious user has access to 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 to the door in the lock, does it help to lock the door?"
COMMENTS
Re: chmod 750? Really?
Yes. 750. I said home directory. Why are you advocating setting rw-r--r-- permissions on a directory? For a start, you're missing x permissions, and secondly you're allowing global read access?
rwx-r-x--- or if possible rwx-r-----
Where the directory is owned by the website owner and Apache has group access.
If you set those permissions on the home directory, then it doesn't matter if the website owner accidently sets rw-rw-rw permissions on a file inside there, no other user on the server will be able to read or write it.
The only users that need access to a users home directory are the apache user, and the website owners user.
Network Solutions shared hosting fail
Network Solutions should configure their shared hosting so only the user and apache has read access to the users homedir. Then even if the user does something stupid and leaves an important file globally readable, nobody else on the system will be able to read it.
chown username:apache ~username
chmod 710 ~username
I'm assuming that they're using suexec/mod_php or similar so users can't run cgi/php as the apache user.
These are *basic* things required to lock down shared hosting.
IT infrastructure monitoring strategies
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Data control in the cloud
Cloud based data management
Agentless Backup is Not a Myth
