lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 20 Feb 2011 14:34:16 +0200
From: "MustLive" <mustlive@...security.com.ua>
To: "Zach C." <fxchip@...il.com>
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: Re: 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: bugtraq@...urityfocus.com ; full-disclosure@...ts.grok.org.uk ;
submissions@...ketstormsecurity.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" <mustlive@...security.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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ