Date: Wed, 4 Apr 2012 07:30:39 -0600
From: Sanguinarious Rose <SanguineRose@...ultusTerra.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Brute Force vulnerability in WordPress

So:

1. Any login page is a "Brute Force Vulnerability" or accepting user
input for that matter is probably a "Brute Force Vulnerability"
2. There is no way to protect against it that can not be overcome (but
apparently there is some magickal way when implemented corrected?) so
its still a "Brute Force Vulnerability"
3. Magick

I would, in fact, challenge you to describe a practical method to
prevent a "Brute Force Vulnerability".

On Wed, Apr 4, 2012 at 6:40 AM, MustLive <mustlive@...security.com.ua> wrote:
> Dear MaXe!
>
> First, you need to take into account that I'm busy man and no need to
> overload me with letters on non important subjects, especially if you want
> to quickly receive an answer (or receive it at all). And especially no need
> to overload me with letters, when you already wrote me a letter (I'm talking
> about January's letter), for which you need to receive an answer first (and
> be sure I'll answer you on that letter when will find time). It's very
> important - do not send me new letters before you'll receive answers on
> previous ones :-). So always wait until you receive answers on previous
> letters, before sending new ones.
>
>> No offense intended of course.
>
> Second, no need to write offense. You've already for second time (in last
> two letters) write me an offensive text (it's present in your letters) and
> at that same time saying "No offense intended". So ask yourself, why you're
> offending me and at that claiming opposite. For you it'll be better to save
> your and my time and not write offense, so there will be no need to justify
> yourself and write "No offense intended" phrases. So you will can use more
> time for other important things, like getting visa to Australia ;-).
>
>> Same type of vulnerabilities exist in 99,999...% of all web applications
>
> >From where you got such statistic, that 99,999% of webapps had Brute Force
> vulnerabilities? Or 99,999% of web sites? It's completely incorrect
> statement and is far away from real statistic. Not 99,999%, nor even 99% -
> not webapps, nor web sites. There are a lot of web applications that have no
> authentication (a lot of such one were made in 90s and beginning of 2000s,
> and even are making nowadays) and the same with websites - there are sites
> with no authentication. All such webapps and web sites have no Brute Force,
> and of course there is some percentage among those webapps and web sites
> with authentication that have no BF because they have protection against it.
>
> And in this advisory I was talking about Brute Force vulnerability via
> XML-RPC functionality (and in the next one I was talking about Brute
> Force vulnerability via APP functionality). How many webapps do you know
> with BF holes in XML-RPC and APP functionalities and which percentage it
> will be for them among all webapps? Far away from your 99,999%.
>
> So even hypothetical statistic much be close to real numbers. And there are
> a lot of classes of vulnerabilities, which are more widespread then Brute
> Force. Like among vulnerabilities from WASC TC v.2. Including there are such
> more widespread vulnerabilities then BF in WordPress. I'll not starting the
> discussion about them, because don't see need in it, nor have time for it.
>
>> including your website.
>
> In this letter I've wrote about BF via XML-RPC functionality. Where did you
> see XML-RPC or BF in it at my site? There is no XML-RPC at all for a long
> time. So it's a lie. in the next letter I've wrote about BF via APP
> functionality. Where did you see APP or BF in it at my site? There never was
> APP at my site at all. So it's a lie again.
>
> And concerning other BFs, which I've wrote about in 2008 and 2010 (against
> which I had reliable protection from begging of 2008). Did you see BF in
> password protected page/post - no, then why lying. Did you see and exactly
> confirm existence of BF in login form - no, then why lying. So no need to
> claim without confirming of existence of holes, because it'll be a lie.
>
> I'm protecting my web sites against BF since beginning of 2001, when made my
> first back-end for my site, and for vulnerable WordPress, after seeing that
> developers are ignoring to fix BF at all, I've also fixed such holes in
> begging of 2008. And all lamers who everyday trying to bruteforce my
> honeypot login form are going away with nothing.
>
>> Even if you can't bruteforce all the time, you can adjust it with timing
>
> Yes, there are methods of bypassing BF protections. But there are also more
> advanced methods of protection. But even they can by bypassed if not
> implement correctly - as I've wrote last year in my articles (translation of
> which you could read in WASC mailing list).
>
>> Did you also mention this 5-10 years ago on your web site about website
>> security named websitesecurity.com.ua?
>
> I've mentioned as about BF, as about other important things at my site, and
> was doing it for six years. And you are writing with such not serious tone
> about my site already from last year. If earlier I've ignored your tone,
> then since this year I'll not be ignoring it. And in my answer on your
> previous letter (you just need to wait for it) I've already made remark for
> you and would do it again. No need to write me with such tone.
>
>> 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?
>
> I'm writing only about what matters - only about that which is important for
> me. And no need to lie about "locking actual users out" (in login forms) -
> I'm not writing about this type of attacks when disclosing vulnerabilities
> in webapps. If you see no risk in one class of vulnerabilities, where I see
> it, then it's your position and you can write about what matters for you.
>
> I see enough risk in BF, so I write about it. If you don't understand enough
> this class of holes in webapps, then it's your problem. Because I know it's
> real risk - as I took over a lot of admin and user accounts via BF during
> pentests and regular security researches (including at sites of banks and
> other financial and e-commerce sites), as I saw many cases like many
> hundreds of cases per year of sites defacements in UAnet due to picking up
> passwords (via BF holes in popular CMS). So I exactly think that BF matters.
>
>> Will the next thing you disclose be about bruteforcing SSH because it by
>> default doesn't lock users out?
>
> No need to write such "funny" assumptions about me. There were trolls in the
> list who wrote such ones (and other trolls who wrote lies and other not
> serious things) and it's not need for you to fall to their level.
>
> There is FTP, which also doesn't lock users out by default. And unlike SSH,
> which is not turned on at every web server, then FTP is turned on at mostly
> all web servers (to provide web sites owners FTP access to their site), so
> it's much more widespread issue. Which belongs to "known ones" - and those
> who want, those will fix it.
>
> But first off all, I'm talking not about protocols, but applications (mostly
> webapps), and I'll not be writing such disclosures (as you like to
> imagine for yourself and should left your imaginations with yourself).
> Second, there are such "unprotected" SSH and FTP servers, but there are
> applications with protection against BF - I have dealt with such one for FTP
> (so those who want, those will fix it). And if such "unprotected" SSH and
> FTP servers long time ago became standard situation which all ignores (and
> it's up to hosters to minimize BF risks), then it had no influence on
> webapps and web sites and their BF holes. Ignorance in SSH/FTP/etc. doesn't
> mean that should be ignorance in webapps/websites.
>
>> It's been like this for +10 or +20 years.
>
> Time of hole existence in webapp or a class of webapps (and the same for
> other apps) doesn't matter. XSS is known from 1998, for 14 years almost
> nothing changes, the same for SQL Injection, Buffer Overflow and other
> classes of vulnerabilities (known for 10/20/more years), but the time of
> ignorance to fix these holes, to prevent these holes, to do anything by
> themselves about it - all this doesn't matter. The only objective reason
> when there will be no need to write about some specific class of
> vulnerabilities - it's when these holes will gone (at least on 99%).
>
>> 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.
>
> Where you ever seen that I've wrote about any webapp, which is vulnerable to
> blocking in login forms. There were no such cases, so it's a lie again. One
> lamer in the list have wrote some years ago such nonsense into my
> direction and it's not need for you to fall to his level.
>
> So, MaXe, in addition to above-mentioned two important things - not writing
> me until received answers on all previous letters and not offending me -
> there is the third thing. No need to lie about me. Having good behavior and
> using these rules - it's what you need (as all others who write me letters).
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua
>
> ----- Original Message -----
> From: "InterN0T Advisories" <advisories@...ern0t.net>
> To: "MustLive" <mustlive@...security.com.ua>
> Cc: <submissions@...ketstormsecurity.org>;
> <full-disclosure@...ts.grok.org.uk>
> Sent: Monday, March 26, 2012 1:09 AM
> Subject: Re: [Full-disclosure] Brute Force vulnerability in WordPress
>
>
> 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/

_______________________________________________
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