Re: Brute Force vulnerability in WordPress

["MustLive" <mustlive () websecurity com ua>]

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 () intern0t net>
To: "MustLive" <mustlive () websecurity com ua>
Cc: <submissions () packetstormsecurity org>;
<full-disclosure () lists 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 () 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/