Last week TrustWave’s SpiderLabs claimed that there were multiple vulnerabilities in WordPress 3.3.1 and below. Their report was also discussed in a post on threatpost. Unlike the Websense and M86 Security Labs reports of a vulnerability in WordPress 3.2.1 that were based on false information, these claims are based on factual information but the issues are presented in a way that we consider to be misleading.
What should have been made very clear by TrustWave and threatpost is that the possible security issues only exist if you have placed the WordPress files on your website but have not run the install script. If you are currently running WordPress this is not an issue in your installation.
If for some reason you have an extra copy of WordPress on the website that has never been used and someone could determine where that it is then this could be an issue. You should remove that copy, as you should with any software on your website that is not being used
Here are the findings made in TrustWave’s SpiderLabs’ report and some possible mitigations for the issues raised:
Finding 1
The WordPress ‘setup-config.php’ installation page allows users to install WordPress in local or remote MySQL databases. This typically requires a user to have valid MySQL credentials to complete. However, a malicious user can host their own MySQL database server and can successfully complete the WordPress installation without having valid credentials on the target system.
After the successful installation of WordPress, a malicious user can inject malicious PHP code via the WordPress Themes editor. In addition, with control of the database store, malicious Javascript can be injected into the content of WordPress yielding persistent Cross Site Scripting.
What this is saying is that if the WordPress files are on a website and the install script has not been run someone else could run it. They could have WordPress connect to a database sever they control during the install and then they would we be able to place PHP code or JavaScript code on the website. As far as we can tell what they are describing would also be equally true of Joomla, Drupal, and other web software because they have similar web based installers.
It is not uncommon for WordPress to be setup with a remote database server, so removing or restricting the ability to do that would not seem to be advisable.
One possible mitigation for this vulnerability be to require the person using the install script to add or modify a file on the website to confirm that they have control of the website before proceeding through it. A similar mitigation would be to require the database credentials be entered into a file on the website instead of through the web installer. Either of those would make the installation process more complicated for users without providing any security benefit for anyone that promptly runs the install script after putting the WordPress files on a website.
Finding 3
The WordPress ‘setup-config.php’ installation page allows users to install WordPress in local or remote MySQL databases. When using this installation page the user is asked to supply the database name, the server the database resides on, and a valid MySQL username and password.
Malicious users can omit the “dbname” parameter during this process, allowing them to continually bruteforce MySQL instance usernames and passwords. This includes any local or remote MySQL instances which are accessible to the target web server. This can also be used as a method to proxy MySQL bruteforce attacks against other MySQL instances outside of the target organization.
What this is saying is that if the WordPress files are on a website and the install script has not been run someone could use install script to make login attempts on a local or remote database server.
In addition to the mitigations mentioned for Finding 1, it would be possible to place limits on the number of attempts to log in into database servers with the installer. That would add complication to the installation process without providing any security benefit for anyone that promptly runs the install script after putting the WordPress files on the website.
Finding 2
The WordPress ‘setup-config.php’ installation page allows users to install WordPress in local or remote MySQL databases. When using this installation page the user is asked to supply the database name, the server that the database resides on, and a valid MySQL username and password.
During this process, malicious users can supply javascript within the “dbname”, “dbhost” or “uname” parameters. Upon clicking the submission button, the javascript is rendered in the client’s browser.
What this is saying is that if the WordPress files are on a website and the install script is not run someone could create POST requests to the install script page which cause arbitrary JavaScript to included on the page in response to that request.
It seems like it should be possible to sanitize these parameters to prevent the described issue, but it doesn’t seem like this would be likely to be exploited as it would make more sense to exploit the issue mentioned in Finding 1. Exploiting the issue in Finding 1 would allow arbitrary JavaScript to be placed on pages without requiring a POST request, which would be easier and evade cross-site scripting (XSS) filters built-into some web browsers, as well as allowing other things to be done which are more of a concern then being able to place arbitrary JavaScript on a page.
WordPress’ Response
WordPress responded to the report by stating that “We give priority to a better user experience at the install process. It is unlikely a user would go to the trouble of installing a copy of WordPress and then not finishing the setup process more-or-less immediately. The window of opportunity for exploiting such a vulnerability is very small.”
We largely agree with WordPress’ view. We would further say that trying to make this a WordPress issue seems inappropriate as the most serious claim is related to having a user friendly web based install script, which is common among web software, rather than something specific to WordPress. If TrustWave’s SpiderLabs believes this is a serious issue they should have raised it instead of trying to make this into an issue with WordPress.