Code Nuances (or Bypassing XSS Filters) : Centralops.net Case Study

It is always fun to play around with deployed security mechanisms that are used for subverting application layer attacks. It is much more interesting to target applications enabled with protections (or that throw code nuances)  rather attacking protection-free applications. A simple case study of centralops.net is presented below.

Acknowledgement: I would like to thank Gavin from Hexillion Group (http://hexillion.com/) for patching this issue within few hours.

Case Study: Recently working on a domain dossier (http:///www.centralops.net) website for my ongoing research, I came across with interesting scenario where I have to bypass some glitches in the code (or filter) to execute the XSS code. I wanted to perform link injection with payload :

"/>&<a href="http://0x.lv/xss.swf"> Injecting SWF Payload </a>

Error due to Injection !

The error I encountered was: "has multiple items separated by spaces, but only one input is allowed at a time. Domain Dossier will continue with"

The error clearly indicates that the input has to be provided as one value. It means the injection payload has to be pushed as one value. I tried a number of payloads with different meta characters which resulted in same responses until I found the XSS payload that bypassed everything in this scenario.  I played around with the white spaces and tried to remove them with certain characters that allowed me to execute the JavaScript (one can find more payloads but depending on the time, I was satisfied with that because the bypass was done already). Overall it was a game play for 10 minutes.

Original : "/><a href="http://0x.lv/xss.swf"> Injecting SWF Payload </a>
Bypass: "/><a//href="http://0x.lv/xss.swf">Injecting_SWF_Payload</a>
Bypass: "/><a/href="http://0x.lv/xss.swf">Injecting_SWF_Payload</a>

Note: I used "/", "//" and "_" characters to treat the payload as one value and pushed it. As a result injection occurs as follows:

Successful Rendering of XSS Payload !

 The supplied payload resulted in successful XSS injection in the target application.

Successful Execution of Payload !

What do we learn from this?
During past years, I feel its more important to understand how exactly the attack is executed (analyzing the underlying components) . As per my experience, one attack vector might not work in all target environments, so we have to build a new one every time. In a number of earlier scenarios, I have seen that if we tamper the whitespaces between HTML attributes and tags, the code fails to render properly in the application. But, in this case study, we are required to embed additional characters in the payload for passing the payload as one value to the application.

Inference: 

(1) Understand the error and develop appropriate combinations to overcome nuances (or bypass XSS filters).
(2) Design XSS payload as per target environment.

Enjoy !

Web Application Design Does Matter - Google Chrome XSS Auditor Bypass : Version <= 32.0.1700.41 m Aura !

Update (6th March 2014) : The post is also discussed on Stack Overflow here: https://stackoverflow.com/questions/22202323/bypass-the-chrome-xss-auditor-by-changing-attributes-in-forms, for additional discussion by the users.

Update: The bug has been reported to Google Chrome team already. The details can be found here: https://code.google.com/p/chromium/issues/detail?id=330972. The team was not able to recreate the issue in the test environment. I validated this issue on the Command and Control (C&C) panel of a botnet :) and I was not in a state to reveal the details of that panel. Anyways the bug is in Wont Fix state and Google Chrome is still vulnerable to these types of XSS bypasses.

Recently, I encountered an XSS auditor bypass in Google Chrome ( &lt;= 32.0.1700.41 m Aura) while working on my research.

Google Chrome Latest Version Tested !

Although, the XSS auditor in Google Chrome is a client-side XSS filter that eradicates the reflective XSS attacks right away. One point that should be taken into consideration that, sometimes the design of the web application also impacts the working of XSS auditor leading to creating such scenarios which are not expected. Anyways, let's analyze a bypass in latest (and earlier) versions of Google Chrome browser. The web page URL looks like as follows:

http://www.example.com/index.php?m=login which generates the form as follows:

For Injection, we crafted the URL as follows:

http://www.example.com/index.php/" onmouseover="JavaScript:alert(document.location)" name="?m=login . 

In this injection, we have not injected in "m" parameter rather we have played with the URI structure. The idea is to tweak the form layout rather the value accepted by the "m" parameter. If you place your injection in "m" parameter, it gets nullified by the XSS Auditor. Let's see how the injection occurs:

As a result, Google Chrome XSS auditor is bypassed.

Inference: Few ideas that should be taken into consideration:

1. The design of web applications impact the XSS auditor.

2. Instead of always targeting the HTTP parameters, play around with the URI structure also.

Note: Internet Explorer blocked this vector.

Additional Readings: Check out the inside details of Google Chrome XSS Auditor:

• XSS Auditor Source Code :  https://code.google.com/p/webkit-mirror/source/browse/Source/WebCore/html/parser/XSSAuditor.cpp
• More about XSS Auditor Read here: http://www.collinjackson.com/research/xssauditor.pdf

Enjoy !