[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Full-disclosure] Brute Force vulnerability in WordPress

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. 
  To: InterN0T Advisories 
  Cc: MustLive ; full-disclosure@xxxxxxxxxxxxxxxxx ; 
submissions@xxxxxxxxxxxxxxxxxxxxxxx 
  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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> 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/