WordPress Install Files Security Risk
Jeff Starr over at Perishable Press has discovered a way to hack a WordPress blog in rare cases where the installation files have been left behind and the database is in accessible:
The other day, my server crashed and Perishable Press was unable to connect to the MySQL database. Normally, when WordPress encounters a database error…
The problem that I painfully discovered when my server crashed is that WordPress does not always display the default page for all database-related issues. Apparently, if the database is missing entirely, WordPress assumes that it has not yet been installed and loads the Installation Page..
I’ve thought about writing about this for a while but thought it might be a far fetched scenario. Also, WordPress has recommended removing the installation files for some time now (simply delete “wp-admin/install.php”), however, with so many updates, perhaps many of us are vulnerable to this.
More info and fix ideas here.
Thanks to Webrocker for reporting this.
If you enjoyed this post, please leave a comment or subscribe to the feed and get future articles delivered to your feed reader.
Comments
Milan, no this shouldn’t be a problem, see thread:
http://wordpress.org/support/topic/198900
Luis, yes this would work but not ideal as a change of permissions could be affected at a later stage and still leave you vulnerable.
It’s interesting vulnerability in WordPress. Which shows that even installers with protection from overinstall is dangerous, because this protection can be bypassed in some cases, so it’s always better to delete installations files after the install.
As I wrote in my article Attack on Abuse of Functionality in WordPress, I have created some variants of the attack on this vulnerability in WP.
It’s possible to attack site even if there is database of engine and there is connection to MySQL, but at that there is crash in one of WP’s tables (which is checking by installer). Particularly, the attack is possible when table wp_options (in WordPress 2.6.2) is damaged, or wp_users (in WordPress 2.0.3 and 2.0.11). I.e. in different versions of WP different tables is checked by installer – it can be table wp_options or wp_users (hardly possible that some other table will be checked by installer in other versions of WP).
Variants of the attack at the site on WordPress (which has installer at the site):
1. In case, if such crash in MySQL was happened on the site and such dialog of installer is showed, then it’s possible to attack the site. Taking into account that it’s very unlikely, and it’s also needed to detect the time of the crash, so better to use other variant of the attack.
2. Make DoS attack on MySQL for the attack on WordPress. Due to DoS attack there will be crash with connection to MySQL and installer potentially can show installation dialog. Though in most cases the connection to DBMS will be lost completely and installer will show corresponding message.
3. Due to automated attack on MySQL (via Insufficient Anti-automation vulnerability in WP) it’s possible to lead to crash in one of checked tables (which also is DoS attack). And in this case installer will work.
Particularly for WordPress 2.0.x and other versions of engine, where installer checked wp_users, this can be done via automated users registration. If to resister user actively at the site, then there can be crash in table wp_users and so engine will can’t read it and show dialog of installer.
MustLive, I am afraid you #2 won’t work as WordPress handles inability to establish database connection differently than corrupted tables.
PS – as for #3: to crash *properly* configured MySQL server is not an easy task. Moreover, if you use InnoDB instead of MyISAM it will be nearly impossible to crash the table.
I went through my installation and disable all install.php by chmod to “000″, would this be enough or do I really have to delete the file to prevent an attack?
Thanks for info,
Luis