Full Disclosure mailing list archives
Re: Brute Force vulnerability in WordPress
From: InterN0T Advisories <advisories () intern0t net>
Date: Wed, 04 Apr 2012 15:31:15 -0400
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 version2.0,or even from 1.x versions, and still not fixed. So I want to warn youaboutone of such holes. It's Brute Force vulnerability via XML-RPCfunctionalityin 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.
Atsending of corresponding POST-requests it's possible to pick uppassword.Note, that since WordPress 2.6 the XML-RPC functionality is turned offbydefault. WP developers did it due to vulnerabilities (such as SQLInjectionand others), which were found in this functionality, i.e. not
motivating
itas counteraction to Brute Force, but it worked also as protectionagainstBrute 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 willhaveBrute 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'sanothersuch 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/
Current thread:
- Re: Brute Force vulnerability in WordPress MustLive (Apr 04)
- Re: Brute Force vulnerability in WordPress Sanguinarious Rose (Apr 04)
- Re: Brute Force vulnerability in WordPress InterN0T Advisories (Apr 04)