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:
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.
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.
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.
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.
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.