Re: Brute Force vulnerability in WordPress

[InterN0T Advisories <advisories () intern0t net>]

Dear MustLive,


No offense intended, but when you post irrelevant information to the
mailing lists I'm following I feel obligated at least once in a while to
respond and be critical, especially when it is almost always the same
pattern, and it is as if you've gone back in time and live in the 80's in a
Commodore 64. No offense intended of course :-)

I don't expect you to reply, and I certainly don't wait for you to respond
to my e-mails (as it often takes you a month to do such, while you post
5-100 new "vulnerabilities" meanwhile), and as I've actually found a
vulnerability I must inform this list about this seriousness that when I
write "No offense intended of course", I am performing a Time-Jump
Bruteforce Attack by using 25 characters in a clever way, and of course (no
offense intended) I wrote about this back in 2005 which you can read about
on securitycompanysecurity.com.co.uk

There is no way to protect against this vulnerability because when you
don't write it people will find your e-mails offensive too and you will
have to spend time apologizing or writing long funny e-mails that doesn't
make sense.


Now, let's get back to reality and be more serious.

I know that you're probably a busy man, even though I may (this time I
actually mean it: no offense intended) wonder what you're busy with, and if
you're spending your time right. Have you read the Web Application Hacker's
Handbook? I suggest you do, and stop posting about these bruteforce flaws,
etc., that can't be fixed or exists in like every web app there is.

It's like saying you found some air today. There's air everywhere on Earth
pretty much, and we all know it, but we don't need to be reminded weekly
about it exists.

About me sending more than one e-mail a month, what do you do with the
spammers? Do you send them e-mails too and ask them not to send you more
e-mails before they've responded? I get tons of e-mail each day, including
a lot of spam too, and in some cases I've received e-mails as if it was a
chat system, but I've never told anyone, please don't send me any further
e-mails before I've responded, because I respond whenever I have time.

Now we're at working on more important things, actually, I feel this is an
important matter too, and fyi I do already have a visa for Australia. So
that's not an excuse for not writing long e-mails to you :-)

I'll skip through most of what you've said as you could've said it in 10
words or less (e.g., MaXe I don't like what you say), but what intrigues me
is this: "> I'm writing only about what matters - only about that which is
important for me."

Information Security, is not about what is important for you, it is about
what is important for the world, and its users. Let's take an example: It's
easier than you think to break into a house, even with the best lock in the
world and 10-inch reinforced concrete door, you can just smash a window and
jump in, in some cases you can just take off the window. 

That's a very common physical security issue, but we don't need to hear
about it, especially not on mailing lists. We know that this vulnerability
exists, along with tons of others in the human nature, most people are
aware, of most of them, but we don't discuss them most of the time, unless
it's really necessary, as it's common sense. So is bruteforcing of any
kind. It's like trying to guess the key combination on a door or on a lock,
it has its flaws, and we know, but we accept it, and live with it.

Concerning lying, that's what you're accusing me for, so you're
postulating as you didn't back up your statement with facts. (Essentially
meaning, you're lying too.)

Keep in mind, that you may think you can offer 100% security, at least it
sounds like that, when you say you can protect against any type of
bruteforcing when "implemented correctly", the problem is, nothing is 100%
secure, at all. Everything in this world, universe, dimension, etc., will
never be 100% secure. Even credit cards that are locked or "eaten" by the
teller machine, has 3 tries, and an even higher chance to guess the pin if
there's a "pin code helper card" along with it. If you take a credit card
and only need the CVV number, you can in some cases bruteforce this
instead, and now you've just broken credit card security, but it was broken
from the start, just like computers are, as they are and will never be 100%
secure, because they were made by humans who will never be 100% secure, in
a world that will never be stable / secure, and in a universe that will
never be stable / secure, as everything is in constant motion all the time.
(Well, except "Dark Matter" perhaps.)

Back to lying: As I can see halfway through your e-mail you began to
become obsessive about me and others lying about you, however, as you don't
have the facts, you're postulating, aka lying which I've already said, but
lying is also relative, as you may think it's a lie from your perspective,
but from my perspective it's not, so in that sense, it's 50/50 and that
equally both, meaning either we both lie or both of us doesn't lie. 


I think it's wrong of you to fall down to this level where you waste time
on vulnerabilities that are worth absolute zero in most cases (thankfully
not always), and I think that you should as I said in my other e-mail,
focus on more "realistic" vulnerabilities that will protect the web apps
and its users from more serious attacks than password guessing and common
developer mistakes. 


Last but not least, I know that it is not the most friendly tone you're
receiving, but most of the time I'm actually quite friendly, it's only when
you keep annoying me (and others) for longer periods (in this case years!)
by sending these "bruteforce vulnerability" e-mails to the mailing lists
I'm following, so my brain starts to slowly degrade. 

I don't know if you've noticed, but who else on Full Disclosure writes
about the type of vulnerabilities you do? Maybe there's a reason they
don't, and this is what I've been trying to make you realize, to get you to
MustLive 7 instead of MustLive 3.11



Best regards,
Your no offense intended debater
MaXe


On Wed, 4 Apr 2012 15:40:08 +0300, "MustLive"
<mustlive () websecurity 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. After all, I'm
a monkey.
> 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/