Friday, August 08, 2014
C-SCAD Tool Presentation and Tool Available
The project page of C-SCAD tool has been updated. Please check the details here: http://cscad.secniche.org
Sunday, February 16, 2014
Intel XSS and Google Chrome XSS Auditor Bypass : Application Design Matters! Its True !
What's the learning lesson here? Occurrences of XSS vulnerabilities are not new but the interesting part is how the vulnerable application impacts the browser defined security components such as XSS filters. In this case study, Google Chrome XSS auditor (enabled by default) again fails to perform the desired work for what is designed for.
The idea here is not to show that there is an XSS bug in Intel website rather to show execution of XSS payloads depends on the application design and there is always an unexpected behavior. Even sophisticated client-side XSS filters can be bypassed easily. I do not have time to investigate what caused the XSS payload to bypass Chrome's XSS auditor. I will notify the Google Chrome team so that they can take a look into it.
Proof-of-Concept: I used the very simple payload : JavaScript:alert(document.cookie) in "URL" parameter for the vulnerable redirect.asp webpage.
 |
| Injected XSS Payload ! |
The payload gets embedded as a hyperlink in the webpage. Amazingly, the XSS auditor accepted to render that payload. So, the XSS injection worked successfully and resulted in cookie extraction.
 |
| Successful XSS Injection ! |
Keep on trying !
Tuesday, January 07, 2014
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 :
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.
The supplied payload resulted in successful XSS injection in the target application.
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 !
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>Note: I used "/", "//" and "_" characters to treat the payload as one value and pushed it. As a result injection occurs as follows:
Bypass: "/><a//href="http://0x.lv/xss.swf">Injecting_SWF_Payload</a>
Bypass: "/><a/href="http://0x.lv/xss.swf">Injecting_SWF_Payload</a>
 |
| Successful Rendering of XSS Payload ! |
 |
| 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 !
Wednesday, January 01, 2014
Reported Jenkins Vulnerability Patched by BlackBerry !
Nowadays, I do not perform aggressive vulnerability hunting (due to my ongoing job) but, when I have time, I dissect components of widely used software and try to find flaws in them. I am more interested in the cases where companies understand the problem and ready to patch it. I am not at all inclined towards finding generic issues in websites which nobody cares about. I always believe that it is important to understand the cons associated with that existing vulnerability when it is reported. It is also crucial to determine how the attacker can chain together a set of bugs to have greater impact. If we don't understand the nitty-gritty details of the vulnerability, there is high chances that the vulnerability will resurface again.
In this case of BlackBerry, unnecessary exposure of Jenkins component in production environment could resulted in problematic scenarios. Exposed components of Jenkins were vulnerable to flaws such as Injections, XSS, etc. So, the belief is: "Expose Less and Be Secure !"
Note: I am going to reveal Frame Injection vulnerability to Jenkins team so that the issue can be patched. No details for now.
Enjoy !
