Full Disclosure mailing list archives
Re: DoS vulnerability in WordPress
From: "MustLive" <mustlive () websecurity com ua>
Date: Fri, 20 Apr 2012 23:50:35 +0300
Hello Kurt! First off all, WordPress developers lay that they made automatic database repair against the vulnerability, which allowed two attacks - DoS and full site takeover (at presence of the installer). Since WP 2.9 (in December 2009) it's still not automatic, so still all versions of WordPress are vulnerable to Tables Corruption Attacks, which I've described in May 2009 (turning 'WP_ALLOW_REPAIR' will not make it automatic). Second, such functionality as in repair.php, which overloads the DBMS (and so every site on the server which uses this DBMS), must be under authorization (and not to every logged in user, but admin only). WP developers haven't did it, but they decided to make such silly method of protection against attacks on this functionality. By default it's off, so admins and their sites protected from attacks on it (and have no advantage from this security functionality). When admins will decide to turn it on, like when the problem with DB occurs or just for testing of this functionality or because they believe in developers words that it's "automatic database optimization" (including repairing of the tables), so for reliability they turned it on, they will receive new vulnerability at their sites. Admins could left this option on for different reasons: forgot to turn off, was busy and decided to turn it off later, have tables crash all the time, so it's easier to turn it on one time and other reasons. For example, besides WordPress I've wrote about analogical vulnerabilities in IBP 1, 2, 3 (which could lead to DoS). And since IPB 2 there is a functionality - not "protection against tables crashes", nor "automatic database optimization", but just functionality in admin panel for repairing DB - which can be used to quickly recover forum after tables crashes. It's accessible only to authorized admins - how it should be made. Best wishes & regards, MustLive Administrator of Websecurity web site http://websecurity.com.ua ----- Original Message ----- From: "Kurt Seifried" <kseifried () redhat com> To: "MustLive" <mustlive () websecurity com ua> Cc: <submissions () packetstormsecurity org>; <full-disclosure () lists grok org uk> Sent: Monday, April 16, 2012 10:11 PM Subject: Re: [Full-disclosure] DoS vulnerability in WordPress
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/15/2012 02:55 PM, MustLive wrote:DoS (WASC-10): By constantly sending requests to script http://site/wp-admin/maint/repair.php (functions "Repair Database" and "Repair and Optimize Database") it's possible to create overload at the site (and the whole server). And the more data in site's DB, the more load from every request. http://site/wp-admin/maint/repair.php?repair=1&_wpnonce=a4ca36d5ff http://site/wp-admin/maint/repair.php?repair=2&_wpnonce=a4ca36d5ff The attack will work at turned on WP_ALLOW_REPAIR in wp-config.php. Protection against CSRF (tokens) is bypassing, because for using of this functionality the authorization isn't required. So it's possible to get _wpnonce remotely and to conduct DoS attack.This appears to be intended functionality, by default I get: "To allow use of this page to automatically repair database problems, please add the following line to your wp-config.php file. Once this line is added to your config, reload this page. define('WP_ALLOW_REPAIR', true);" So either an admin has to specifically configure this to allow it anonymously, or exploitation requires administrative access. I don't see any trust boundary being violated here. - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPjG77AAoJEBYNRVNeJnmTKWUQAIE5a0yRHp3AZMKhc1aCWYKb BgCvGp6qD+54kNvjYcGqfGh6LalZJeYm/1zYMtWyrXFptlCElCobDfWvVS5EUx3X gSwyIgrh630Iy1IEpwdmAZzBGQ/wiHx3E+00zvNrbyeGzrHdiem6+zT1A/EbElum d5wga4iyctFFkdCCIfbE9YfLzGyZG0CGjNNyR9EuURQ2RPJV9ldfrCjtjD4jIqI3 PBIcMzfysDMIqLRXB8Tf+462Ux4iHW/FieXOaoG0N+1+Gq+P3/spBJlMOG6AWGzl h7/yQbsCbFzYTL5mFWaZu18BGXx6MjzW0IliZ/Q70T6AHsuaEiEqKmEVbbbd/Com JyayQu7NyA8fuBhq1KRCrA3WjrAEfsV/yLQXVMsSdtbWodHpZ5RjFqhX95aBE9Ld CWtheuTm1xSuVVYq92VaJlT2aHlE/LK/nfSMPMqx1xBOHl1VbhuOvFVON6UIIYXg mPuYjmWXLIaEGYn6k8ZRcXCbZIvnPYPF3T1Jkp03m7RCCbMiQ1C7FQ65vmFwKtEi MqdoCcNWQIn4dM6Tb4/AwFDCj6Du+mJSusZvOCfMQt38GDES+iqndZAtXJ0YRUJG tES9pMq9NzeqtqyExROQFaoecLNHeJeWGQWLCrusUT5mdEHpjnl+WOkq+skUC1EJ khftjrd8KsbyNfGWN7/H =yegM -----END PGP SIGNATURE-----
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- DoS vulnerability in WordPress MustLive (Apr 15)
- Re: DoS vulnerability in WordPress Kurt Seifried (Apr 17)
- Re: DoS vulnerability in WordPress Javier Reoyo (Apr 17)
- Re: DoS vulnerability in WordPress MustLive (Apr 20)
- Re: DoS vulnerability in WordPress Christian Sciberras (Apr 20)
- Re: DoS vulnerability in WordPress Kurt Seifried (Apr 17)