OWASP Challenge 7 Christmas capture flag

I missed this one during Christmas holiday. Anyway, here is the challenge
http://www.owasp.org/index.php/OWASP_AppSec_Research_2010_-_Stockholm,_Sweden#tab=Challenges


The target is http://66.249.7.26. (OWASP should do better next time, at least grabbed a domain name to look more professional)


Step 1: Visit http://66.249.7.26 and the site looks like:

A look at source code reveals these messages within html comment:

Step 2: My first thought is that the bell image might hide something. Several tests showed that assumption is not true. Then, I thought about finding more pages. Wikto did not find anything interesting. DirBuster found some standard documentation pages.

Step 3: Return back to the hidden comment. "Dont forget to leave milk and cookies for santa and his helpers." Cookies! Yes, cookie. I should try cookies. By using Burp, I added a test cookie x=y into the request. The response did have something new:

Noooo noooo noooo - but close!

Now, it is a game of cookie. Burp's repeater is perfect for this.

Cookie: santa=y generates something new:

Hoooo hoooo hoooo!!!

Warning: mysql_fetch_assoc(): supplied argument is not a valid MySQL result resource in /var/www/xmas/frontend/index.php on line 95

However "helpers" and "hishelpers" do not have any luck. Maybe, I should use his reindeer's names: Dasher, Dancer, Prancer, Vixen, Comet, Cupid, Donner, Blitzen, Rudolf. None seems to work.

Step 4: So far, we have found one cookie: santa. If we set santa=1, the error message is gone and we have something new:

YToxOntzOjIwOiJCRU5DSE1BUksoMTEsTUQ1KDEpKSI7czoxOiIwIjt9

santa=123 returns:

YToxOntzOjIyOiJCRU5DSE1BUksoMTEyMyxNRDUoMSkpIjtzOjE6IjAiO30=

They look like base64 encoding. Yes. the decoded messages are:

a:1:{s:20:"BENCHMARK(11,MD5(1))";s:1:"0";}

a:1:{s:22:"BENCHMARK(1123,MD5(1))";s:1:"0";}

From the error message in step 3, we already knew that the server is running MySQL and PHP.

According to http://dev.mysql.com/doc/refman/5.0/en/information-functions.html#function_benchmark, BENCHMARK executes the expression for specified time. For example, BENCHMARK(11,MD5(1)) means that the server will run MD5(1) for 11 times. Since our input seems to be used in SQL statement, let's try some SQL injections:

santa=123' generates old error message

santa=234,SHA(1))# does not generate any error message and we get

YToxOntzOjIyOiJCRU5DSE1BUksoMTIzNCxTSEEoMSkpIjtzOjE6IjAiO30=

and it is decoded as a:1:{s:22:"BENCHMARK(1234,SHA(1))";s:1:"0";}

Wow, it seems that we are very likely to be able to conduct SQL injection for the application. That's all for today.

Microsoft Anti-XSS library

If you are using ASP.NET, then Microsoft Anti-Xss library is valuable at tackling with cross site scripting issues. The latest version can be found at:

http://antixss.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=20333

There is some documentations at

http://msdn.microsoft.com/en-us/security/aa973814.aspx

It also comes with new sanitization function to include "safe" html within your output.

http://blogs.msdn.com/securitytools/archive/2009/09/01/html-sanitization-in-anti-xss-library.aspx

Lots of people asked the same question "why do not we just use HttpUtility.htmlEnocde?". The Differences between AntiXss.htmlEncode and HttpUtility.HtmlEncode are:

• AntiXss.htmlEncode uses white list approach while HttpUtility.HtmlEncode uses black list
• AntiXss.htmlEncode supports more languages
• AntiXss.htmlEncode is designed for defeat XSS while HttpUtility.HtmlEncode is designed to generate safe html.
• Performance difference.

The details can be found at http://blogs.msdn.com/securitytools/archive/2009/07/09/differences-between-antixss-htmlencode-and-httputility-htmlencode-methods.aspx