Message-ID: <CAD6s_XsTQa+2tgKgPkNUHOEpd0QkubRUDU8N3d-+_09jQT4Ncg@mail.gmail.com>
Date: Sat, 21 Apr 2012 00:32:08 +0200
From: Christian Sciberras <uuf6429@...il.com>
To: MustLive <mustlive@...security.com.ua>
Cc: full-disclosure@...ts.grok.org.uk, submissions@...ketstormsecurity.org
Subject: Re: DoS vulnerability in WordPress

Honestly, you'll be doing a favour to everyone in the universe and yourself
if you learned (to write) some proper English.








On Fri, Apr 20, 2012 at 10:50 PM, MustLive <mustlive@...security.com.ua>wrote:

> 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@...hat.com>
> To: "MustLive" <mustlive@...security.com.ua>
> Cc: <submissions@...ketstormsecurity.org>;
> <full-disclosure@...ts.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/
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists