Full Disclosure mailing list archives
Re: Brute Force vulnerability in WordPress
From: Sanguinarious Rose <SanguineRose () OccultusTerra com>
Date: Wed, 4 Apr 2012 07:30:39 -0600
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 () 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 applicationsFrom where you got such statistic, that 99,999% of webapps had Brute Forcevulnerabilities? 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 timingYes, 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 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 motivatingitas 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/
_______________________________________________ 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)