Comments on: WordPress Install Files Security Risk http://blogsecurity.net/wordpress/wordpress-install-files-security-risk Always something worth reading... Fri, 12 Mar 2010 11:09:45 +0000 http://wordpress.org/?v= hourly 1 By: Vladimir http://blogsecurity.net/wordpress/wordpress-install-files-security-risk/comment-page-1#comment-16543 Vladimir Tue, 09 Jun 2009 04:32:39 +0000 http://blogsecurity.net/?p=512#comment-16543 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. 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.

]]> By: Vladimir http://blogsecurity.net/wordpress/wordpress-install-files-security-risk/comment-page-1#comment-16542 Vladimir Tue, 09 Jun 2009 04:30:26 +0000 http://blogsecurity.net/?p=512#comment-16542 MustLive, I am afraid you #2 won't work as WordPress handles inability to establish database connection differently than corrupted tables. MustLive, I am afraid you #2 won’t work as WordPress handles inability to establish database connection differently than corrupted tables.

]]> By: MustLive http://blogsecurity.net/wordpress/wordpress-install-files-security-risk/comment-page-1#comment-16496 MustLive Wed, 20 May 2009 21:53:08 +0000 http://blogsecurity.net/?p=512#comment-16496 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 <a href="http://websecurity.com.ua/3152/" rel="nofollow">Attack on Abuse of Functionality in WordPress</a>, 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. 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.

]]> By: Diablo http://blogsecurity.net/wordpress/wordpress-install-files-security-risk/comment-page-1#comment-16495 Diablo Wed, 20 May 2009 18:28:34 +0000 http://blogsecurity.net/?p=512#comment-16495 000 + rename should be enough ... anyway it should be safer to delete it. 000 + rename should be enough … anyway it should be safer to delete it.

]]> By: DK http://blogsecurity.net/wordpress/wordpress-install-files-security-risk/comment-page-1#comment-16452 DK Sun, 10 May 2009 18:26:38 +0000 http://blogsecurity.net/?p=512#comment-16452 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. 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.

]]> By: Milan http://blogsecurity.net/wordpress/wordpress-install-files-security-risk/comment-page-1#comment-16450 Milan Sun, 10 May 2009 00:06:25 +0000 http://blogsecurity.net/?p=512#comment-16450 Are there any potential problems that cause arise from deleting this file? Are there any potential problems that cause arise from deleting this file?

]]> By: Luis http://blogsecurity.net/wordpress/wordpress-install-files-security-risk/comment-page-1#comment-16444 Luis Fri, 08 May 2009 14:03:53 +0000 http://blogsecurity.net/?p=512#comment-16444 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 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

]]>