“You can’t compromise an application using XSS”

Before I open up this can of worms, I can tell you that both vendor and client have told me this.  I then try to explain to them how things are generally interwoven and connected to each other and how you CAN own an application through XSS if done in a correct manner.

With XSS, you usually end up owning the USER of the application and thus can build up on your attack.

“You cannot alter any data using XSS”

With a reflected XSS attack, yes, you cannot change any stored data on an application.  You can, however, change the User Interface significantly.  You can swap out an entire page using a reflected XSS attack to make a user think he is on another screen of the application.  Like the login page for example or injecting an iframe.  The only catch is that you have crafted this login page using HTML and JavaScript and have presented it to him as if it were part of the legitimate site.  The login form sends his password to a server you control, but nothing is altered on the application database to begin with.

In the above examples and all cases of XSS, one thing is common.  The scope of this vulnerability is confined to that of the application user.  You do not use XSS to attack the application directly.  You use it to attack the user and indirectly attack the application.  So an XSS is more comparable to a pseudo social-engineering attack where you are tricking the user into revealing his credentials (enter his password on a crafted password screen or stealing his cookie).

The easiest way I find to present an XSS vulnerability, even before I put it in a report, is to call all the project stakeholders into a room and demo it to them.  I tell them that I have some findings to share with them and would like a few minutes to show them a live demo.  I then load up the application page that they are all familiar with.  Open up my email client to a received message[1], click on the XSS laden link[2] and show them a perfectly legitimate login screen of their application.  I log in using credentials I was given and then continue to access one of the application’s functions as normal.

After a few seconds, I stop and tell them that I was just a victim of an XSS attack.  Then I move into the technical details.  I find this approach to be quite effective[3].  It raises awareness in a way that the client can relate to.  What they perceive to be a legitimate session turns out to be an attacker controlled phishing attack of sorts.

[1] I create this message and send it to myself to simulate a company employee receiving an email from another person.

[2] I sometimes obfuscate the link, but usually I use HTML mail to show them an underlined “Click Here” phrase when the actual link is a stager.  I send an include (hex encoded <script src> tag) to a remote JavaScript file that contains the code to render the fake login page.

[3] My setup includes a remote site under my control where I host the malicious, custom written JavaScript files.  I have a backend script to pick up the posted information and send me a neat little email containing the cookie (if any), username and password and some other relevant data.  If one of the executives has a connected laptop, I will invite him to try it himself.  In the early days, I would send the link out to all the application users first by spoofing an internal email.  Then, I’d compile a list of the users affected and share the information with the executives in the meeting.

I’ve had more positive responses using this approach than trying to put it in the report only to have several opinions thrown back from the client and the vendor that show a lack of knowledge on the subject.

XSS attacks are very common and can be used to great effect.  I am not alone when I say that XSS is very badly misunderstood and the threat that it poses is often ignored.  I think a hands-on approach of this nature, even though it takes more time and effort, is worthwhile in spreading the word.  Sometimes, you just have to spend the effort to demo your vulnerabilities to put things into context.  Your clients will appreciate it and remember it more than just reading a report.

I’m a big fan of Burp Suite. Burp Suite is a set of tools that I believe every web application pen-tester should find indispensable. Developed by Dafydd Stuttard a.k.a. Port Swigger, it is available in both Free and Professional (read paid) versions. Its a great set of tools and I use it’s extensibility to achieve the automated login process. Dafydd has also co-authored the book The Web Application Hacker’s Handbook. No, I don’t personally know Dafydd, and no, he’s not paying me to say these things (although I would never dare to send back a free copy of the Pro version he would send me ), but I use the tools and I think they’re quite awesome.

I recently pen-tested a banking application that was being launched by a large bank and dusted off my re-login plugin. Given that the bank used the F5 Big IP appliance with the application security module and the fact that it employed a ticketing system, I had to make extensive changes to my once humble re-login plugin. So I did. In the spirit of giving back, I thought someone else might find the plugin useful or can even build off my one (if you do, please do share the improved version) so I’ll post my research and final plugin here.

Because of the pain in the ass Big IP, I had to craft my re-login plugin as follows:

1. Record the error page of the Big IP and find a unique string to identify the page
2. Record the POST request for the login page
3. Write the plugin to detect if this string is in the response
4. If it is, then make an HTTP GET request to the start page.
5. Grab the cookies from the GET request
6. Replace the cookies from the POST request with the ones from the GET request
7. Make the HTTP POST request
8. Grab the response and send it back to the browser.

Now when I send that incredibly long string in the “Amount” field or send a whole load of XSS in the “Description” field, I am no longer greeted by the Big IP error page. Instead, my plugin takes over, seamlessly logs me back in and brings me to the landing page.

Here is the source code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105

import java.util.regex.Matcher;
import java.util.regex.Pattern;
import burp.IBurpExtender;
import burp.IBurpExtenderCallbacks;
 
public class BurpExtender implements IBurpExtender {
 
	public burp.IBurpExtenderCallbacks callBacks;
 
	public void applicationClosing() {
	}
 
	public void registerExtenderCallbacks(IBurpExtenderCallbacks callbacks) {
		callBacks = callbacks;
	}
 
	public void setCommandLineArgs(String[] cla) {
	}
 
	public byte[] processProxyMessage(
			int messageReference,
			boolean messageIsRequest,
			String remoteHost,
			int remotePort,
			boolean serviceIsHttps,
			String httpMethod,
			String url,
			String resourceType,
			String statusCode,
			String responseContentType,
			byte[] message,
			int[] action)
	{
 
		byte[] firstRequest;
		byte[] nextRequest;
		String initialCookies = "";
 
		if(!messageIsRequest){
			try{
				if(isBigIPError(message)){
					callBacks.issueAlert("Attempting to re-login...");
					firstRequest = new String("[Enter First Request separated by \r\n]").getBytes();
					nextRequest = new String("[Enter Second Request separated by \r\n]").getBytes();
					byte[] firstResp = callBacks.makeHttpRequest(remoteHost, remotePort, serviceIsHttps, firstRequest);
					initialCookies = grabCookies(firstResp);
					byte[] interimReq = buildRequest(initialCookies,nextRequest);
					message = callBacks.makeHttpRequest(remoteHost, remotePort, serviceIsHttps, interimReq);
				}
			} catch (Exception e) {
				e.printStackTrace();
			}
		}
		return message;
	}
 
	private String grabCookies(byte[] getRequest){
		String getReq = new String(getRequest);
		String regEx = "Set-Cookie:\\s(.*?);";
		Pattern pattern = Pattern.compile(regEx, Pattern.DOTALL | Pattern.MULTILINE);
		Matcher matcher = pattern.matcher(getReq);
		StringBuilder cookies = new StringBuilder();
		cookies.append("Cookie: ");
		while(matcher.find()){
			cookies.append(matcher.group(1)+"; ");
		}
		cookies.append("\r\n");
		return cookies.toString();
	}
 
	private byte[] buildRequest(String cookies, byte[] postRequest){
		String[] carvedPost = {};
		String postReq = new String(postRequest);
		carvedPost = postReq.split("\r\n\r\n");
		postReq = carvedPost[0]+"\r\nContent-Length: "+carvedPost[1].length()+"\r\n\r\n"+carvedPost[1];
		StringBuffer finalReq = new StringBuffer();
		String regEx = "Cookie:\\s(.*?)\r\n";
		Pattern pattern = Pattern.compile(regEx, Pattern.DOTALL | Pattern.MULTILINE);
		Matcher matcher = pattern.matcher(postReq);
		while(matcher.find()){
			matcher.group();
			matcher.appendReplacement(finalReq,cookies.toString());
		}
		matcher.appendTail(finalReq);
		return finalReq.toString().getBytes();
	}
 
	private boolean isBigIPError(byte[] msg){
		String message = new String(msg);
		boolean result =false;
		try{
			String regEx = "[Enter the regex of an identifying term appearing in the error page]";
			Pattern pattern = Pattern.compile(regEx,Pattern.DOTALL|Pattern.MULTILINE);
			Matcher matcher = pattern.matcher(message);
			if(matcher.matches()){
				callBacks.issueAlert("Received error from F5 Big-IP!");
				result = true;
			}
 
		} catch (Exception e) {
			e.printStackTrace();
		}
		return result;
	}
}

To get this to work in Burp, I will provide you with instructions directly from PortSwigger:

Before you proceed, make sure to change the GET, POST and RegEx to match your own scenario. Just place them into the areas surrounded by square brackets. Remove the square brackets after that.

———————————SNIP——————————————-

If you want to play with this example yourself, you can download the source here: BurpExtender.java. The steps to compile and run the plugin are as follows:

1. If you don’t already have it, download and install the Java Development Kit (JDK) from Sun.
2. Create a directory to work in, and cd into it from the command line.
3. Copy the plugin source file (BurpExtender.java) into your working directory.
4. Create a subdirectory called “burp”, and copy theIBurpExtenderCallbacks.java file into this directory. You will need this file in the correct relative path, because the plugin code makes use of the IBurpExtenderCallbacks interface.
5. In your working directory, compile the BurpExtender.java source file into a .class file using javac, the Java compiler. The exact command will depend on the location of your JDK – for example, on Windows, you might type: “\Program Files\Java\jdk1.6.0_04\bin\javac.exe” BurpExtender.java
6. Confirm that the file BurpExtender.class has appeared in your working directory.
7. Build a Java archive (JAR) file containing your .class file. Depending again on your JDK location, you might type:”\Program Files\Java\jdk1.6.0_04\bin\jar.exe” -cf burpextender.jar BurpExtender.class
8. Confirm that the file burpextender.jar has appeared in your working directory.
9. Copy your normal Burp JAR file into your working directory.
10. Using the actual name of your Burp JAR file, start Burp using the command: java -Xmx512m -classpath burpextender.jar;burp.jar burp.StartBurp

If everything works, Burp should launch with a number of entries in the alerts tab, confirming which IBurpExtender methods were successfully loaded from your plugin (in this case, processProxyMessage and registerExtenderCallbacks):
———————————SNIP——————————————-

If you need any clarifications on this or some help, just post some comments and I’ll do my best to answer them.

That should be it for now. Go forth and Haxx0r!

–
Chopstick