Over the weekend the discussion surrounding the mass compromise of sites running WordPress continued. After some research on various blogs, the common link discovered in the attacks wasn’t plug-in related or a ZeroDay vulnerability, it was a permissions issue.
The sites were compromised by altering the siteurl value in the wp_options table of targeted sites. Once this value was altered by the attacker, an Iframe was injected into the rendered page, which would then redirect visitors to a malicious domain where Malware, Rogue anti-Virus, and various client side exploits were delivered.
The interesting observation when looking at the malicious destinations used by the Iframe was that it served up Malware in the BUZUS family. This is interesting as BUZUS is traditionally spread using instant messaging programs according to researchers from TrendMicro.
BUZUS is a Trojan that has been used in the past to launch Denial-of-Service attacks. In addition to instant messaging, BUZUS has also been known to spread over P2P networks by mimicking the names of popular games and movies.
The injected Iframe also prevented administrative access to the WordPress related sites, and had the drawback of making infected sites visible to the public. In addition, the attack was also noticeable to the site administrator due to the fact that anything dependent on the siteurl would cease to function properly.
The attacks were traced to permissions on the wp-config.php file. Most sites will be fine if the file is set to 0644. However, they are often set to less restrictive permissions such as 0755.
The difference is that 0644 controls access and allows the server to read the file and use it, while 755 means everyone can read and execute the file, and depending on methods, write to it as well. For the most part, the best practice is to use 0755 sparingly when it comes to file permissions and development requirements. If you can avoid using it, you should.
Because the wp-config.php file was set with improper permissions, the attacker was able to access it with ease. As most shared hosting uses a predictable and single method for database access, an attacker sharing the same host as the victim already has access to the host’s databases.
The wp-config.php file stores the database username and password in clear text. With this information, combined with the data related to database structure, which is usually uniform, the attacker is able to navigate the WordPress installation’s backend altering things at will.
Network Solutions, GoDaddy, and MediaTemple are just three shared hosting companies that had customers impacted by the mass compromise. There is no way to know how many other shared hosting services were affected.
Researchers David Dede (Sucuri Security) and Denis Sinegubko (Unmask Parasites) both reached the same conclusions, that file permissions were to blame for the incident, but selected different sources for the problem overall.
Dede, wrote that WordPress could be blamed for allowing clear text access to the database details, and for failure to install itself securly. On the other hand, Dede said that users could be blamed for not securing their blogs. Sinegubko said that the issue is a design flaw with WordPress. Again, the standard practice is to use 0644 as the permissions setting for wp-config.php, but since the attack, it has been suggested by Network Solutions and others to use 0640.
“Unfortunately, this trick will only work on servers with suPHP. On other servers where web server executes PHP scripts with its own rights, this trick will [completely] break WordPress blogs. Every page will produce the ‘Failed opening required wp-config.php’ error,” Sinegubko wrote.
“This means that WordPress blogs on most shared servers are vulnerable to this sort of attack...Any other database driven web scripts that store database credentials in plain text are also vulnerable.”
There is no word if WordPress plans to address how file permissions are used, and presently they recommend the use of 0750 for users on shared hosting in their hardening manual. In the WordPress forums, the advice is to use the most restrictive permissions that are available.
For some this means setting public_html to 0750, WordPress related folders to 0755, and WordPress related files to 0644. For others it means using 0640, but that will only work depending on how your host manages their server.
For those on dedicated servers and hosting, you can better control how PHP and Apache work, and for the most part those with dedicated sites were not included in the recent problems.
For now, restrict as much as possible, and monitor how your site appears in search engines. If you discover problems, hosts like Network Solutions and MediaTemple are available to help with resolution.