Hello Nick aka Nant and Bugtraq! This Nant's letter I found some time ago (and now found time to write answer on it) and I found it accidentally, because I'm not subscribed to Bugtraq mailing list. So Nant and every reader of the list must take it into account (and send letters to my email, if they want to contact me). And this is that example of letter from developer, which I mentioned last week at the list. Which clearly shows, that web developers ignore advisory about holes in CaptchaSecurityImages.php itself, and only draw attention on advisories about their specific web applications. So in my answer I'll draw attention to this aspect of Nant's letter.
Some facts for those reading:
Nick, the more facts, the better - it'll show the whole picture. So I'll add other facts which you forgot to mention.
MustLive notified us on 13.4.2010 - that's 13 days after disclosure.
As I wrote in my advisory (in "Timeline") there were next important dates: 17.03.2010 - found vulnerability. 31.03.2010 - disclosed at my site. 01.04.2010 - informed developer of CB Captcha 1.x. And because I found other version of the plugin by another author, and after checking it later I informed author of CB Captcha 2.x. 13.04.2010 - additionally informed developers of Community Builder (both joomlapolis.com and communitybuilder.ru). Here are other dates: 27.03.2007 - developers of CaptchaSecurityImages.php fixed this hole at their own site and wrote the recommendations to fix this captcha bypass (http://www.white-hat-web-design.co.uk/articles/php-captcha.php). I.e. it was more than 3 years ago. And CB Captcha developers ignored that, and didn't do anything until I informed them and even after that they were fixing hole slowly, creating different justifications for themselves, including telling that it's not a hole. Did you (developers of CB Captcha) think about why original author fixed that hole in 2007 (and they had this hole almost one year after creating of the script, but when they understood the fact of the hole they fixed it). 17.03.2010 - I disclosed at my site the vulnerabilities in CaptchaSecurityImages (http://websecurity.com.ua/4043/) and at 22.03.2010 I reported about it to Bugtraq. It was 9 days before I disclosed at my site the hole in CB Captcha (which is similar to hole in CaptchaSecurityImages). This is important thing, which clearly shows, as I mentioned earlier, that web developers ignore advisory about holes in CaptchaSecurityImages.php itself, and only draw attention on advisories about their specific web applications. Developers of CB Captcha just didn't draw attention about my advisory in security mailing lists (from 22.03.2010) about holes in CaptchaSecurityImages, but they drew attention at my letter (and to my advisory posted in Bugtraq) about holes in CB Captcha. Which shows importance of making separate advisories of vulnerabilities in software which are using CaptchaSecurityImages.php (some uses its original code, and some other, like CB Captcha, uses rewritten code of original script, so it's not always completely the same code). It can be due to that fact, the developers and admins which are using different engines could forget or even don't know, that in their webapp there is such web application as CaptchaSecurityImages.php. But when they see advisory about specific webapp which they are using, they will draw attention at it. It's good that at least developers of CB Captcha 2.x and Community Builder answered me and decided to fix the hole. Because developers of Russian forks of CB Captcha 1.x and Community Builder didn't answered me and obviously they'd not fix the hole. Also Nick mentioned about that I contacted them after 13 days after disclosure (at my site). Man, from two above mentioned dates 27.03.2007 and 17.03.2010 you can see that it's not justification for developers of CB Captcha. And also note, that after I disclosed this hole at 31.03.2010, I found that there are two different versions of plugin (and I checked only 1.x and wrote ay my site only about affected 1.x). And after I contacted at 01.04.2010 developers of 1.x and after I found time to check 2.x version of plugin at 13.04.2010, I wrote about this version at my site and contacted developers of 2.x. I.e. I have contacted developers of CB Captcha 2.x just after few minutes after I wrote at my site about vulnerable version 2.x. So I hope for you and for readers of mailing list is everything clear with the dates and the facts :-). It's about dates, and now about vulnerabilities.
This should not be classified as any kind of vulnerability as there is no way that any harm can be done to a website using this script.
It's not serious statement. This is known for a long time class of vulnerability. If you didn't read WASC TC yet, then you'd better read it. First, this is Insufficient Anti-automation vulnerability. The class Insufficient Anti-automation is listed in WASC Threat Classification v1 (released in 2004) and in Threat Classification v2 (released in 2010). In TC v2 it's also referenced as WASC-21. Second, this attack is directed on the site. This hole doesn't belong to Client-side Attacks (TC v.1), but to Logical Attacks (TC v.1) and is using against site itself. And it can be used for different malicious actions. Best wishes & regards, MustLive Administrator of Websecurity web site http://websecurity.com.ua Re: Vulnerability in CB Captcha for Joomla and Mambo Apr 16 2010 02:04PM nant joomlapolis com
Hello viewers. This is Nick (aka nant) - one of the original (not the forked Russian version) CB Captcha plugin developers. We are responsible for version 2.2 that is referenced in the report. Some facts for those reading: MustLive notified us on 13.4.2010 - that's 13 days after disclosure. This should not be classified as any kind of vulnerability as there is no way that any harm can be done to a website using this script. The CB Captcha 2.2 plugin, as all similar Captcha scripts, are used to insure that human intervention is needed. The "bug" (at best) reported only allows a single user seeing the generated Captcha image, to use its code during the active session period. There is no harm that can be done to the system using this. Thus while this is a bit of odd behavior it does not represent a asecurity flaw. This will be fixed however as soon as possible. Thank you.
