Message-ID: <CAD6s_Xs+T_s2KxozqvWVjmrGs4XGswusprrANnCG7huKfLwSnA@mail.gmail.com>
Date: Wed, 28 Mar 2012 23:55:19 +0200
From: Christian Sciberras <uuf6429@...il.com>
To: MustLive <mustlive@...security.com.ua>
Cc: full-disclosure@...ts.grok.org.uk, "Zach C." <fxchip@...il.com>
Subject: Re: Brute Force vulnerability in WordPress

How do you propose fixing this "vulnerability"?

"Error: Just pick another username....we don't like the one you chose."

Brute force wouldn't work (would be infeasible) if wrong logins would take
slightly longer to process (say, 2 to 5 seconds) as well as throttling
login attempts.
But again, this is a login issue, definitely NOT "abuse of functionality by
bruteforcing logins".

Hell, I could "bruteforce" logins with a single google dork... there's no
point protecting against the inevitable, especially when the "protection"
is causing a huge disservice for absolutely no reason.


Chris.




On Wed, Mar 28, 2012 at 11:43 PM, MustLive <mustlive@...security.com.ua>wrote:

> **
> *Hi Zach!*
>
> Yes, it's also a vulnerability. It's Abuse of Functionality, which allows
> to enumerate logins. And during 2008-2011 I've wrote about all existent
> Login enumerations and Login leakages in WordPress (including this
> one). And also in many other web applications. Such vulnerabilities are
> also widespread like BF, but less then BF. I've found many web sites and
> web applications, where there was BF, but no Login enumerations or Login
> leakages. So they are less widespread, but also ignored by developers, even
> more then BF holes.
>
> Knowing logins is vital for Brute Force attacks and if logins are hidden
> it's not just 50% more secure (as some developers like to say about 50%
> less secure with leaked logins), but it's make BF almost impossible.
> Because with unknowing logins it'll be needed to pick up passwords blindly
> (with using of common logins), which will be unsuccessful in 99% cases. But
> there are web applications where logins are not needed - it's webapps with
> only one password field (there were many such webapps in 90-s and first
> part of 2000-s) and with fixed login (which is the same as only one
> password field), like Adobe ColdFusion, about this and other holes I've
> wrote last year.
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua
>
> ----- Original Message -----
> *From:* Zach C. <fxchip@...il.com>
> *To:* InterN0T Advisories <advisories@...ern0t.net>
> *Cc:* MustLive <mustlive@...security.com.ua> ;
> full-disclosure@...ts.grok.org.uk ; submissions@...ketstormsecurity.org
> *Sent:* Monday, March 26, 2012 3:05 AM
> *Subject:* Re: [Full-disclosure] Brute Force vulnerability in WordPress
>
> He also considers it a vulnerability to tell a new user that the username
> they've picked out has been taken by another user.
>
> On Sun, Mar 25, 2012 at 3:09 PM, InterN0T Advisories <
> advisories@...ern0t.net> wrote:
>
>> Same type of vulnerabilities exist in 99,999...% of all web applications
>> including your website. Even if you can't bruteforce all the time, you can
>> adjust it with timing, and e.g., proxies, different user-agents, etc., and
>> then you have "Timed Bruteforce Attacks" which works on pretty much all
>> websites. Did you also mention this 5-10 years ago on your web site about
>> website security named websitesecurity.com.ua?
>>
>> Also, when will you stop posting about: bruteforce/full path
>> disclosure/locking actual users out/and other low priority
>> "vulnerabilities" that exist in most web apps, and completely move on to
>> vulnerabilities that matters? Seriously, anyone can find these
>> "vulnerabilities" and the reason why anyone hasn't reported / disclosed /
>> complained about them is because they exist in most apps and doesn't
>> compromise the security of the end-user nor the website.
>>
>> Will the next thing you disclose be about bruteforcing SSH because it by
>> default doesn't lock users out? It's been like this for +10 or +20 years.
>>
>>
>> What I find funny is that either you:
>> A) Say a web app has a vulnerability because it doesn't lock the
>> "offending" user out because of too many password tries, OR
>> B) Say a web app has a vulnerability because it does lock out the
>> offending user because of too many password tries.
>>
>> It's almost a contradiction and an endless evil circle. You can't have
>> both, ever.
>>
>>
>> No offense intended of course.
>>
>>
>>
>> Best regards,
>> MaXe
>>
>> On Sun, 25 Mar 2012 23:45:33 +0300, "MustLive"
>> <mustlive@...security.com.ua> wrote:
>> > Hello list!
>> >
>> > There are many vulnerabilities in WordPress which exist from version
>> 2.0,
>> > or even from 1.x versions, and still not fixed. So I want to warn you
>> about
>> > one of such holes. It's Brute Force vulnerability via XML-RPC
>> functionality
>> > in WordPress.
>> >
>> > -------------------------
>> > Affected products:
>> > -------------------------
>> >
>> > Vulnerable are WordPress 3.3.1 and previous versions.
>> >
>> > ----------
>> > Details:
>> > ----------
>> >
>> > Brute Force (WASC-11):
>> >
>> > http://site/xmlrpc.php
>> >
>> > In this functionality there is no protection against Brute Force attack.
>> At
>> > sending of corresponding POST-requests it's possible to pick up
>> password.
>> >
>> > Note, that since WordPress 2.6 the XML-RPC functionality is turned off
>> by
>> > default. WP developers did it due to vulnerabilities (such as SQL
>> Injection
>> > and others), which were found in this functionality, i.e. not motivating
>> it
>> > as counteraction to Brute Force, but it worked also as protection
>> against
>> > Brute Force attack.
>> >
>> > So this issue doesn't concern those who uses WordPress since version 2.6
>> > with default settings. But those who needs to use XML-RPC, those will
>> have
>> > Brute Force vulnerability, because the developers didn't make reliable
>> > protection against it.
>> >
>> > Earlier in 2008 and 2010 years I've already wrote about Brute Force
>> > vulnerabilities in WordPress (http://websecurity.com.ua/2007/ and
>> > http://websecurity.com.ua/4016/ SecurityVulns ID: 10677) and it's
>> another
>> > such vulnerability. Besides them there is also known BF attack not via
>> > login
>> > form, but with using of authorization cookie (when by setting different
>> > cookies it's possible to pick up password).
>> >
>> > ------------
>> > Timeline:
>> > ------------
>> >
>> > 2012.03.20 - disclosed at my site.
>> >
>> > I mentioned about this vulnerability at my site
>> > (http://websecurity.com.ua/5723/).
>> >
>> > Best wishes & regards,
>> > MustLive
>> > Administrator of Websecurity web site
>> > http://websecurity.com.ua
>>
>
> _______________________________________________
> 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