Re: Brute Force vulnerability in WordPress

[Christian Sciberras <uuf6429 () gmail com>]

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 () websecurity 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 () gmail com>
> *To:* InterN0T Advisories <advisories () intern0t net>
> *Cc:* MustLive <mustlive () websecurity com ua> ;
> full-disclosure () lists grok org uk ; submissions () packetstormsecurity 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 () intern0t 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 () websecurity 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/
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/