Re: [Full-disclosure] Vulnerability in reCAPTCHA for Drupal
Hello Zach! fucking *two days*? Is that even enough time for the vendor to acknowledge? You've read inattentively - between informing of developers and disclosing of vulnerabilities the two months and two days have passed (as you can see in Timeline section). So be more attentive next time. About how much time developers need to fix the holes. 1. The developers need enough time and I'm always giving them enough time. In different cases I gave different time: sometimes it was month or few months, sometimes it was year or even more. But always sufficient amount of time (and if developer just ignore the hole, then regardless of given time, such developer never fix it). In average I'm giving two months for fixing. 2. Different developers need different amount of time. It also depends on number of vulnerabilities. For example, developer of PHPXref fixed holes on the next day after I informed him (http://phpxref.sourceforge.net/Changelog). And developers of MyBB, which I informed about multiple vulnerabilities last week, they are still investigating them (for more then week), as they stated. Mozilla requires just ten days, as they stated (http://ha.ckers.org/blog/20070803/mozilla-says-ten-fucking-days/). And I had such cases, when admins of web sites fixed holes in a few minutes after receiving of my letter (as they stated, when quickly answered me after the fixes). So there are developers which fix holes quickly enough. Best wishes regards, MustLive Administrator of Websecurity web site http://websecurity.com.ua - Original Message - From: Zach C. To: MustLive Cc: bugt...@securityfocus.com ; full-disclosure@lists.grok.org.uk ; submissi...@packetstormsecurity.org Sent: Thursday, February 17, 2011 7:54 PM Subject: Re: [Full-disclosure] Vulnerability in reCAPTCHA for Drupal fucking *two days*? Is that even enough time for the vendor to acknowledge? On Feb 17, 2011 9:20 AM, MustLive mustl...@websecurity.com.ua wrote: Hello list! I want to warn you about Insufficient Anti-automation vulnerability in reCAPTCHA for Drupal. In project MoBiC in 2007 I already wrote about bypassing of reCaptcha for Drupal (http://websecurity.com.ua/1505/). This is new method of bypassing reCaptcha for Drupal. - Affected products: - Vulnerable are all versions of reCAPTCHA plugin for Captcha module versions before 6.x-2.3 and 7.x-1.0. -- Details: -- Insufficient Anti-automation (WASC-21): In different forms in Drupal the vulnerable captcha-plugin reCAPTCHA is using. Drupal's Captcha module is vulnerable itself, so besides reCAPTCHA other captcha-plugins also can be vulnerable (at that this exploit is a little different from exploit for default Captcha module for Drupal). For bypassing of captcha it's needed to use correct value of captcha_sid, at that it's possible to not answer at captcha (captcha_response) or set any answer. This method of captcha bypass is described in my project Month of Bugs in Captchas (http://websecurity.com.ua/1498/). Attack is possible while this captcha_sid value is active. Vulnerabilities exist on pages with forms: http://site/contact, http://site/user/1/contact, http://site/user/password and http://site/user/register. Other forms where reCAPTCHA is using also will be vulnerable. Exploit: http://websecurity.com.ua/uploads/2011/Drupal%20reCAPTCHA%20bypass.html Timeline: 2010.12.11 - announced at my site. 2010.12.14 - informed reCAPTCHA developers. 2010.12.14 - informed Google (reCAPTCHA owner). 2011.02.16 - disclosed at my site. I mentioned about this vulnerability at my site (http://websecurity.com.ua/4752/). 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/
Re: [Full-disclosure] Vulnerability in reCAPTCHA for Drupal
On Fri, Feb 18, 2011 at 3:40 PM, Charles Morris cmor...@cs.odu.edu wrote: I am very aware I must compromise this belief when working in the market, like most of my other beliefs and morals, and I do so daily. Then I go home and cry myself to sleep. Charles One of the most insightful, even if somewhat depressing, commentaries I've read on this mailing list. Ulisses -- “If debugging is the process of removing software bugs, then programming must be the process of putting them in.” - Edsger Dijkstra ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Vulnerability in reCAPTCHA for Drupal
Michele, Granted I don't know or really care about drupal, and I'm not just trying to defend MustLive, who just seems to be a guy trying to get ahead in the world, even if he's a little misguided; but what really gets to me is when people dismiss issues like that. Not to mention you are assuming that the defaults are never changed. full path disclosure IS an information disclosure, unless the code is designed to disclose it's filesystem path. Any information gathered by unorthodox methods from an application that wasn't designed to do so, is an information disclosure. Information disclosure IS a vulnerability. Even if an attack vector isn't known, things like filesystem knowledge, internal varialbe names, error messages, username = id mapping, etc can still be used from a social engineering perspective. It is my personal belief that all vulnerabilities should be patched regardless of existence of a known attack vector or exploit. If an application does not behave exactly as it's intended in all circumstances: patch || gutmann() And, to MustLive; I hope that debugging option or whatever is turned on by default- otherwise the quoted issue is more of a misconfiguration and yes two days is a completely irrational acknowledgment duration cap ... :( ... I've had vendors take weeks to acknowledge an issue.. we have to gently hold the hand of vendors and teach them how computer work.. I personally suggest putting a proper disclosure policy on your website and then stick to it. On 2/17/11, Michele Orru antisnatc...@gmail.com wrote: If you thing that some statements from MustLive like the following: Full path disclosure (WASC-13): At POST request to the page with form with using of Cyrillic char in parameter op, the error message is showing, which consists the full path on the system. Vulnerabilities exist at pages:http://site/user/,http://site/user/1/edit, http://site/user/password,http://site/user/register,http://site/contact, http://site/user/1/contact. Other pages which have forms also can be vulnerable. Exploit: http://websecurity.com.ua/uploads/2011/Drupal%20Full%20path%20disclosure.html As noted Drupal developers, these vulnerabilities appear due to turned on debugging option in administrator panel. So for preventing of these and other FPD at the site it's needed to turn off this option. are not hilarious, then you're a really noob. I mean, every Drupal user knows that the default path to register a new user is user/register, or that the default admin account is reachable at user/1, or that the contact form is at the contact URI. These are not vulnerabilities, and this is one of the many reasons why almost no-one in FD read his advisories and flag his address as spam :) antisnatchor ... MustLive mailto:mustl...@websecurity.com.ua February 17, 2011 6:18 PM Hello list! I want to warn you about Insufficient Anti-automation vulnerability in reCAPTCHA for Drupal. In project MoBiC in 2007 I already wrote about bypassing of reCaptcha for Drupal (http://websecurity.com.ua/1505/). This is new method of bypassing reCaptcha for Drupal. - Affected products: - Vulnerable are all versions of reCAPTCHA plugin for Captcha module versions before 6.x-2.3 and 7.x-1.0. -- Details: -- Insufficient Anti-automation (WASC-21): In different forms in Drupal the vulnerable captcha-plugin reCAPTCHA is using. Drupal's Captcha module is vulnerable itself, so besides reCAPTCHA other captcha-plugins also can be vulnerable (at that this exploit is a little different from exploit for default Captcha module for Drupal). For bypassing of captcha it's needed to use correct value of captcha_sid, at that it's possible to not answer at captcha (captcha_response) or set any answer. This method of captcha bypass is described in my project Month of Bugs in Captchas (http://websecurity.com.ua/1498/). Attack is possible while this captcha_sid value is active. Vulnerabilities exist on pages with forms: http://site/contact, http://site/user/1/contact, http://site/user/password and http://site/user/register. Other forms where reCAPTCHA is using also will be vulnerable. Exploit: http://websecurity.com.ua/uploads/2011/Drupal%20reCAPTCHA%20bypass.html Timeline: 2010.12.11 - announced at my site. 2010.12.14 - informed reCAPTCHA developers. 2010.12.14 - informed Google (reCAPTCHA owner). 2011.02.16 - disclosed at my site. I mentioned about this vulnerability at my site (http://websecurity.com.ua/4752/). 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 -
Re: [Full-disclosure] Vulnerability in reCAPTCHA for Drupal
I'm definitely not trying to defend MustntLive, but his timeline shows 2010.12.14 to 2011.02.16. Which makes it 2 months and 2 days, not 2 days, right? On Feb 18, 2011 7:08 AM, Charles Morris cmor...@cs.odu.edu wrote: ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Vulnerability in reCAPTCHA for Drupal
Why yes it does. Shame on me for not reading so well. On Feb 18, 2011 7:51 AM, Conor conor.l...@gmail.com wrote: I'm definitely not trying to defend MustntLive, but his timeline shows 2010.12.14 to 2011.02.16. Which makes it 2 months and 2 days, not 2 days, right? On Feb 18, 2011 7:08 AM, Charles Morris cmor...@cs.odu.edu wrote: ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Vulnerability in reCAPTCHA for Drupal
On Fri, 18 Feb 2011 10:07:26 EST, Charles Morris said: It is my personal belief that all vulnerabilities should be patched regardless of existence of a known attack vector or exploit. Let me fix that for you: All vulnerabilities should be evaluated as to whether patching them makes sense. If it's a one-liner fix for a stupid logic error, yes it probably should be patched whether or not there's a known exploit. The problem starts when you hit something that's a deeply seated design issue in a published API - then you need to balance the costs of possible exploits against the equally real costs of fixing the problem (which may end up requiring a possibly large number of third parties to fix their usage of the API). The Windows shatter attack is a good example: https://secure.wikimedia.org/wikipedia/en/wiki/Shatter_attack Why was that such a pain to fix over multiple years? Because you couldn't fix it without breaking legitimate users of the interface. And here it is almost a decade later, and I'm not 100% convinced it's totally fixed yet. That one was pretty obviously an issue where a paper was out showing how to exploit it, in a very highly visible and widely distributed piece of software. But there's plenty of packages that have only thousands or even mere hundreds of users (especially off on the long-tail end of open-source). If one of those projects is discovered to have a major hole, but it's a package that's usually used on a laptop and you need to run code on the target machine, how important is it *really* to be patched? If the attacker is already running code on your laptop as another user, the additional privilege escalation to your userid may not matter that much anymore... So yes, evaluation is needed. But patching it may not make any realistic sense, depending on the nature of the issue and who is potentially affected. pgpe5l7Ql4Fht.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Vulnerability in reCAPTCHA for Drupal
It is my personal belief that all vulnerabilities should be patched regardless of existence of a known attack vector or exploit. Let me fix that for you: All vulnerabilities should be evaluated as to whether patching them makes sense. If it's a one-liner fix for a stupid logic error, yes it probably should be patched whether or not there's a known exploit. ... So yes, evaluation is needed. But patching it may not make any realistic sense, depending on the nature of the issue and who is potentially affected. I agree Valdis, and I personally used shatter when it was popularized.. resulting in tons of fun here at the university with my colleagues. However, I'm simply stating a belief in a more abstract sense, I agree beliefs are not always realistic, but personally I /do/ make that guarantee whenever I write a piece of code. I am very aware I must compromise this belief when working in the market, like most of my other beliefs and morals, and I do so daily. Then I go home and cry myself to sleep. Charles ___ 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] Vulnerability in reCAPTCHA for Drupal
Hello list! I want to warn you about Insufficient Anti-automation vulnerability in reCAPTCHA for Drupal. In project MoBiC in 2007 I already wrote about bypassing of reCaptcha for Drupal (http://websecurity.com.ua/1505/). This is new method of bypassing reCaptcha for Drupal. - Affected products: - Vulnerable are all versions of reCAPTCHA plugin for Captcha module versions before 6.x-2.3 and 7.x-1.0. -- Details: -- Insufficient Anti-automation (WASC-21): In different forms in Drupal the vulnerable captcha-plugin reCAPTCHA is using. Drupal's Captcha module is vulnerable itself, so besides reCAPTCHA other captcha-plugins also can be vulnerable (at that this exploit is a little different from exploit for default Captcha module for Drupal). For bypassing of captcha it's needed to use correct value of captcha_sid, at that it's possible to not answer at captcha (captcha_response) or set any answer. This method of captcha bypass is described in my project Month of Bugs in Captchas (http://websecurity.com.ua/1498/). Attack is possible while this captcha_sid value is active. Vulnerabilities exist on pages with forms: http://site/contact, http://site/user/1/contact, http://site/user/password and http://site/user/register. Other forms where reCAPTCHA is using also will be vulnerable. Exploit: http://websecurity.com.ua/uploads/2011/Drupal%20reCAPTCHA%20bypass.html Timeline: 2010.12.11 - announced at my site. 2010.12.14 - informed reCAPTCHA developers. 2010.12.14 - informed Google (reCAPTCHA owner). 2011.02.16 - disclosed at my site. I mentioned about this vulnerability at my site (http://websecurity.com.ua/4752/). 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/
Re: [Full-disclosure] Vulnerability in reCAPTCHA for Drupal
It's either he floods f-d with his vulnerabilities or he has to go out in the real world to farm dirt for export to the West. On 02/17/2011 12:54 PM, Zach C. wrote: fucking *two days*? Is that even enough time for the vendor to acknowledge? ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Vulnerability in reCAPTCHA for Drupal
fucking *two days*? Is that even enough time for the vendor to acknowledge? On Feb 17, 2011 9:20 AM, MustLive mustl...@websecurity.com.ua wrote: Hello list! I want to warn you about Insufficient Anti-automation vulnerability in reCAPTCHA for Drupal. In project MoBiC in 2007 I already wrote about bypassing of reCaptcha for Drupal (http://websecurity.com.ua/1505/). This is new method of bypassing reCaptcha for Drupal. - Affected products: - Vulnerable are all versions of reCAPTCHA plugin for Captcha module versions before 6.x-2.3 and 7.x-1.0. -- Details: -- Insufficient Anti-automation (WASC-21): In different forms in Drupal the vulnerable captcha-plugin reCAPTCHA is using. Drupal's Captcha module is vulnerable itself, so besides reCAPTCHA other captcha-plugins also can be vulnerable (at that this exploit is a little different from exploit for default Captcha module for Drupal). For bypassing of captcha it's needed to use correct value of captcha_sid, at that it's possible to not answer at captcha (captcha_response) or set any answer. This method of captcha bypass is described in my project Month of Bugs in Captchas (http://websecurity.com.ua/1498/). Attack is possible while this captcha_sid value is active. Vulnerabilities exist on pages with forms: http://site/contact, http://site/user/1/contact, http://site/user/password and http://site/user/register. Other forms where reCAPTCHA is using also will be vulnerable. Exploit: http://websecurity.com.ua/uploads/2011/Drupal%20reCAPTCHA%20bypass.html Timeline: 2010.12.11 - announced at my site. 2010.12.14 - informed reCAPTCHA developers. 2010.12.14 - informed Google (reCAPTCHA owner). 2011.02.16 - disclosed at my site. I mentioned about this vulnerability at my site (http://websecurity.com.ua/4752/). 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/
Re: [Full-disclosure] Vulnerability in reCAPTCHA for Drupal
Well, just playing devil's advocate here, mind you, I think much of the irritation from MustLive's postings comes from the following three reasons: 1.) MustLive is primarily a web-application specialist (for the sake of argument) 2.) The vulnerabilities he finds are of a class of vulnerabilities that are most common in his field. (Consider: someone searching for vulnerabilities in internet services directly and doing the binary analysis will primarily be finding buffer or stack overflows, right? In web security, XSS and SQL injection (as well as others I'm undoubtedly forgetting -- I am *NOT* counting not using a CAPTCHA here, see next item) are the most common vulnerabilities, given the lack of binary code to overwrite) 3.) Every so often he posts a vulnerability of questionable risk in the form of anti-automation which is essentially a fancy way of saying ha ha they don't use CAPTCHA. I don't consider that a vulnerability so much as an opening for annoyance; I suppose your mileage may vary. My guess is that there's a thought that web apps are far easier to crack at than binaries, so vulnerabilities are easier to find, therefore don't waste time finding something that's useless. That may be, in some cases, but sometimes a vulnerability in the web app destroys the entire chain, so to speak. Thoughts? -Zach (P.S. Still just playing devil's advocate; sometimes they get to annoy the crap out of me too.) On Thu, Feb 17, 2011 at 9:57 AM, Eyeballing Weev eyeballing.w...@gmail.comwrote: It's either he floods f-d with his vulnerabilities or he has to go out in the real world to farm dirt for export to the West. On 02/17/2011 12:54 PM, Zach C. wrote: fucking *two days*? Is that even enough time for the vendor to acknowledge? ___ 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/
Re: [Full-disclosure] Vulnerability in reCAPTCHA for Drupal
If you thing that some statements from MustLive like the following: " Full path disclosure (WASC-13): At POST request to the page with form with using of Cyrillic char in parameter op, the error message is showing, which consists the full path on the system. Vulnerabilities exist at pages: http://site/user/, http://site/user/1/edit, http://site/user/password, http://site/user/register, http://site/contact, http://site/user/1/contact. Other pages which have forms also can be vulnerable. Exploit: http://websecurity.com.ua/uploads/2011/Drupal%20Full%20path%20disclosure.html As noted Drupal developers, these vulnerabilities appear due to turned on debugging option in administrator panel. So for preventing of these and other FPD at the site it's needed to turn off this option. " are not hilarious, then you're a really noob. I mean, every Drupal user knows that the default path to register a new user is user/register, or that the default admin account is reachable at user/1, or that the contact form is at the contact URI. These are not vulnerabilities, and this is one of the many reasons why almost no-one in FD read his "advisories" and flag his address as spam :) antisnatchor Zach C. February 17, 2011 7:29 PM Well, just playing devil's advocate here, mind you, I think much of the irritation from MustLive's postings comes from the following three reasons: 1.) MustLive is primarily a web-application specialist (for the sake of argument) 2.) The vulnerabilities he finds are of a class of vulnerabilities that are most common in his field. (Consider: someone searching for vulnerabilities in internet services directly and doing the binary analysis will primarily be finding buffer or stack overflows, right? In web security, XSS and SQL injection (as well as others I'm undoubtedly forgetting -- I am *NOT* counting "not using a CAPTCHA" here, see next item) are the most common vulnerabilities, given the lack of binary code to overwrite) 3.) Every so often he posts a vulnerability of questionable risk in the form of "anti-automation" which is essentially a fancy way of saying "ha ha they don't use CAPTCHA." I don't consider that a vulnerability so much as an opening for annoyance; I suppose your mileage may vary. My guess is that there's a thought that web apps are far easier to crack at than binaries, so vulnerabilities are easier to find, therefore don't waste time finding something that's "useless." That may be, in some cases, but sometimes a vulnerability in the web app destroys the entire chain, so to speak. Thoughts? -Zach (P.S. Still just playing devil's advocate; sometimes they get to annoy the crap out of me too.) ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ Eyeballing Weev February 17, 2011 6:57 PM It's either he floods f-d with his "vulnerabilities" or he has to go out in the real world to farm dirt for export to the West. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ Zach C. February 17, 2011 6:54 PM fucking *two days*? Is that even enough time for the vendor to acknowledge? ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ MustLive February 17, 2011 6:18 PM Hello list! I want to warn you about Insufficient Anti-automation vulnerability in reCAPTCHA for Drupal. In project MoBiC in 2007 I already wrote about bypassing of reCaptcha for Drupal (http://websecurity.com.ua/1505/). This is new method of bypassing
Re: [Full-disclosure] Vulnerability in reCAPTCHA for Drupal
On Thu, 17 Feb 2011 21:39:49 +0100, Michele Orru said: I mean, every Drupal user knows that the default path to register a new user is user/register, or that the default admin account is reachable at user/1, or that the contact form is at the contact URI. Yes, but that's the *URL PATH*. What's the full path *on the filesystem*? Is it /opt/drupal/user/register? Or did they stick it in /usr/local/drupal? Or somewhere else? This actually matters if you're trying to do a tree traversal exploit like ../../../path/to/drupal/install/ - or if you *thought* you had configured your system so it wouldn't leak full pathnames so skiddies couldn't abuse tree traversal exploits. pgpagQyFZkMJ6.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
