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 <[email protected]> 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" <[email protected]> > To: "MustLive" <[email protected]> > Cc: <[email protected]>; > <[email protected]> > 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" > <[email protected]> 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/
