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: