Common Security Issues in Financially-Oriented Web Applications

A guideline for penetration testers to assess eCommerce and financial services applications.

This document summarises NCC Group’s experience of assessing eCommerce and financial services applications, providing a checklist of common security issues seen in financial services web applications.

This paper has been published via the NCC Group website:
https://www.nccgroup.trust/uk/our-research/common-security-issues-in-financially-orientated-web-applications/

The PDF version of this paper is also available here: https://www.nccgroup.trust/globalassets/our-research/uk/whitepapers/2015/06/common-security-issues-in-financially-orientated-web-applications-_v1.0_final.pdf

Interesting XML Processing in Copy/Paste in Word and Outlook

This issue was not considered to be a security issue based on “Definition of a Security Vulnerability” in https://msdn.microsoft.com/en-us/library/cc751383.aspx as I have been told by Microsoft MSRC team. I thought it can be interesting to some people, so I am sharing the details here.
It seems Microsoft Word and Outlook applications (tested on Office 2010) analyse the DTD section of an XML message upon pasting it in a document or a new email.
This can lead to a denial of service attack by creating an XML message with a large number of nested entities.
The victim should paste the crafted XML message into a Word or Outlook document in order for this issue to be exploited. This can potentially be done by using websites that put arbitrary data in the clipboard upon clicking a button or pressing the CTRL+C combination.

As an example, the following XML message (reference: https://msdn.microsoft.com/en-us/magazine/ee335713.aspx) can be copied and pasted into a Word or Outlook document in order to cause denial of service (paste this into a notepad file first to remove the WordPress style, then copy/paste it again into a new Outlook email or a Word document):

<!DOCTYPE lolz [
<!ENTITY lol "lol">
<!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
<!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
<!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
<!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
<!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
<!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]><foo>&lol9;</foo>

Files within the PATH environment variable could also be targeted by using the DTD section as it is shown below:

<!DOCTYPE test [
<!ENTITY xxe SYSTEM "win.ini">
]><foo>&xxe;</foo>

The following image shows that MS Word has sent some requests to the file-system to find this file.

It was not possible to use this vulnerability to send requests externally or use arbitrary files on the file system which are outside of the PATH (in environment variables). Therefore, I could not exploit it to hijack files as I could not use the “/”, “\”, or “:” characters.

Non-Root-Relative Path Overwrite (RPO) in IIS and .Net applications

tl;dr

In this blog post, I will show you a better way to exploit non-root-relative path overwrite issues in ASP.NET Web Form applications. This is a low risk vulnerability that can be used to inject a resource such as a stylesheet or even a dynamic JavaScript into an affected web page.

Introduction

Many of us already know for a long time about path-info and the ability of several web application technologies such as .Net, php, or java that can accept parameters after the file extension by using a slash (“/”) or a semi-colon (“;”) character. This is a useful feature to create customised restful applications. In case of Java, it can normally accept a session token after a semi-colon character in the URL (when jsessionid is not in the cookies – bad practice).

Web pages which include their URLs in their output without encoding it properly (assuming it is safe) or with improper encoding can become vulnerable to cross-site scripting issues (e.g. http://www.exploit-db.com/exploits/31865/). However, this is not the topic of this blog post as it has nothing to do with the relative paths!

Many of us know about the functional issues that relative paths could cause a web application especially when URL-rewrite rules or restful URLs are in use. For instance, we could see broken pages with messed-up images and stylesheets from time to time by adding or changing parameters in the URL.  However, I did not have any idea how to exploit this issue in any ways until Gareth Heyes shed light on it and published the following useful blog post:
http://www.thespanner.co.uk/2014/03/21/rpo/

After that I mistakenly thought this attack would only be useful in the old versions of IE until James Kettle published the following useful post in the PortSwigger’s blog:
http://blog.portswigger.net/2015/02/prssi.html

It is highly recommended to read this blog post if you have not read it yet. Especially the “Exploiting Quirks” section caught my eye! Who knows? It may catch yours too ;-)

RPO and ASP.NET Applications

The usage of non-root-relative paths is common among the ASP.NET Web Form applications and I am going to focus on this type of application in this blog post.

In order to add a stylesheet and a JavaScript file with non-root-relative paths, the following code can be added to an ASP.NET page (.aspx or its Master page):

<head runat="server">
	<link href="~/style.css" rel="stylesheet" type="text/css" />
	<script type="text/javascript" src="<%=Page.ResolveClientUrl("~/js.js")%>"></script>
</head>

You can use the following vulnerable “.aspx” page (VB.NET) in your test environment:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<!-- Author: Soroush Dalili (@irsdl) - https://Soroush.SecProject.com/blog/ -->
<head runat="server">
	<link href="~/style.css" rel="stylesheet" type="text/css" />
	<script type="text/javascript" src="<%=Page.ResolveClientUrl("~/js.js")%>"></script>
</head>
<%
Dim input: input = Request("input")
if input <> "" then session("input") = input
%>
<body>
	<form runat="server">
		<div class="page" id="page">Just an example. Your input goes here: "<%=Server.HtmlEncode(session("input"))%>"</div>
        <div class="DotNetVersion">.Net Framework version: "<%=Environment.Version%>"</div>
	</form>
	<script>
		var pageColor = '';
		var pageObj = document.getElementById('page');
		var textColor;

		if (pageObj.currentStyle){
		  textColor = pageObj.currentStyle.color;
		}else if (window.getComputedStyle){
		  textColor = document.defaultView.getComputedStyle(pageObj, null).getPropertyValue("color");
		}

		if(textColor=="red" || textColor=="rgb(255, 0, 0)"){
		  pageColor = 'red';
		}
	</script>
</body>
</html>

This page uses an old doctype which can simply be exploited in an RPO attack. As explained in the PortSwigger’s blog post, a list of doctypes that can open a website in Quirks mode can be found in the following website: https://hsivonen.fi/doctype/#handling and sometimes it is even possible to force a web page to be opened in Quirks mode by using IE (see PortSwigger’s blog post for the requirements).

This ASPX page has been saved in the following URL (.Net Framework 2): http://sdl.me/demo/RPO/test.aspx?input=test

As this page HTML-encode the “input” parameter, it is not possible to exploit a cross-site scripting issue. Sometimes in real ASP.NET applications, the protection can be because of the Request Validation module.

The above ASP.NET page shows the following HTML code in the browser:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<!-- Author: Soroush Dalili (@irsdl) - https://Soroush.SecProject.com/blog/ -->
<head><link href="../../style.css" rel="stylesheet" type="text/css" />
	<script type="text/javascript" src="../../js.js"></script>
<title>

</title></head>

<body>
	<form name="ctl01" method="post" action="test.aspx?input=test" id="ctl01">
<div>
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUKLTQ3MDQ5NDcxMmRkL+8De/6ibnWrmbVRn1YZfKdyQoI=" />
</div>

<div>

	<input type="hidden" name="__VIEWSTATEGENERATOR" id="__VIEWSTATEGENERATOR" value="EBB86DB2" />
</div>
		<div class="page" id="page">Just an example. Your input goes here: "test"</div>
        <div class="DotNetVersion">.Net Framework version: "2.0.50727.4253"</div>
	</form>
	<script>
		var pageColor = '';
		var pageObj = document.getElementById('page');
		var textColor;

		if (pageObj.currentStyle){
		  textColor = pageObj.currentStyle.color;
		}else if (window.getComputedStyle){
		  textColor = document.defaultView.getComputedStyle(pageObj, null).getPropertyValue("color");
		}

		if(textColor=="red" || textColor=="rgb(255, 0, 0)"){
		  pageColor = 'red';
		}
	</script>
</body>
</html>

.NET resolves the “~” operator to the root of the current application (in IIS). Therefore, you may see a “../” pattern when the page is located in a subdirectory.

Note: If a web page is in a directory but does not contain a “../” pattern in a non-root-relative path (does not start with a protocol or a “/” character), the directory name shows the application name that is installed on IIS (this is in fact root of that web application).

.Net Framework 4 resolves the “~” operator a little bit different from .Net Framework 2 and here is when the confusion arises!

In our example page, .Net Framework 4 adds more “../” to the “style.css” path when we have additional folders after the “.aspx” extension. In other words, by opening the “/test.aspx/1111/2222/3333” page in .Net Framework 4 the “style.css” path has 3 additional “../” as it shown below:


<link href="../../../../../style.css" rel="stylesheet" type="text/css" />

Unfortunately I do not have a web server with .Net Framework 4 but we can use our local IIS server to reproduce the issue.

This behaviour of .Net Framework 4 neutralises normal RPO attacks as the page cannot load itself as a stylesheet anymore. However, vulnerable pages in .Net Framework 2 can be exploited with the same exploitation method that was described in Gareth Heyes’ or PortSwigger’s blog posts:


http://sdl.me/demo/RPO/test.aspx/1111/2222/?input=%0C}}}}]]]]]*/ {} *{color:red;}

Link

Note: “%0A”, “%0C”, or “%0D” should be used to escape the double or single quotation characters. In addition, the attack will not work if there is any open “{“ or “[“ characters as well as “/*”. Therefore, the “%0C}}}}]]]]]*/” string was used before the CSS injection vector to ensure that the rest of string can be loaded as a valid style to make the page red. The “import” method could also be used as another vector of CSS injection.

Note: This PoC code will not work if .Net Framework 4 is used as it was explained above.

A Generic Solution for ASP.NET Pages:

.Net Framework 4 does not add additional “../” to the path when the directory names after the “.aspx” extension are empty! As a result, the following easy solution could be used in .Net Framework 2 and 4 at the same time:


http://sdl.me/demo/RPO/test.aspx////////////?input=%0C}}}}]]]]]*/ {} *{color:red;}

Link

Overwrite by Using Another File:

RPO in a web server such as IIS which understands an encoded directory traversal pattern in the path “%2F.. %2F” can also be exploited to point to the other files (that supports path-info) on the same website.

The following shows an example in which “anotherpage.css.aspx” is used to replace the stylesheet:

</pre>
http://sdl.me/demo/RPO/anotherpage.css.aspx/%2f..%2f..%2f..%2fdemo/RPO/test.aspx
<pre>

Link

This can also cause a cross-site scripting issue if an attacker can use another dynamic file (such as a JSON handler file) to rewrite the path of a non-root relative JavaScript file as it is shown below:

</pre>
http://sdl.me/demo/RPO/anotherpage.js.aspx/%2f..%2f..%2f..%2fdemo/RPO/test.aspx
<pre>

Link

In IIS, “%2F” (URL-encoded version of “/”) can also be replaced with a “%5C” (URL-encoded version of “\”).

Note: This method is similar to the one I had used before to exploit location.pathname in JavaScript (https://soroush.secproject.com/blog/2013/09/simple-security-tip-window-location-window-location-pathname-can-cause-open-redirect-issue/).

Note: In case of having an application on IIS in the path, this method can only be exploited within this application path (not from root of the website). The following shows an example:

</pre>
http://example.com/ApplicationName/page2.aspx/%2f..%2fpage1.aspx
<pre>

Note: Using another dynamic page may help an attacker to inject other resources such as even JavaScript files in special cases.

.NET Framework 4 Form’s Action:

This feature of .NET Framework 4 was known to me for a long time but I could never exploit it in any useful way. However, some people may find this inspirational to find some security issues and please don’t forget to update me on that as I am really interested!

Anything after the last forward-slash or backslash (“/” or “\”) characters before the QueryString part of the URL is used as the form’s action without URL-encoding (double and single quotation characters have HTML-encoding). For instance, opening the “example.aspx/1.aspx/2.aspx?test=test” will create the following HTML form in the page:


<form method="post" action="2.aspx" id="ctl01">

I could not use this to exploit RPO as the control characters (such as “%0A”, “%0C”, or “%0D”) will be blocked by default IIS settings and characters like “< > * % & : \ ?” and double escaping are blocked by the default ASP.NET settings (requestPathInvalidCharacters). Exploiting CSS injection by using “import” is more feasible in this case but there is limitation on the usage of forward slash or backslash characters (you will see it when you start exploiting it yourself).

Most of the ASP.NET pages also do not use the “action” attribute of .Net forms, otherwise we could probably exploit this by chaining it to an open redirect or a reflected cross-site scripting issue (to bypass browsers’ anti-XSS protections).

 

In the end, I should not forget to thank Dean McCarten (@2bitwannabe) who provided me with an example from Visual Studio 2013 which used relative paths in a stylesheet. This .Net sample code and a recent penetration testing project encouraged me to write this blog post.

Analysis of setting cookies for third party websites in different browsers

I had done a research into the ability of third party websites setting cookies for first party websites across different web browsers. This was published in the NCC Group blog which is available via the following link:

https://www.nccgroup.com/en/blog/2015/01/analysis-of-setting-cookies-for-third-party-websites-in-different-browsers/

The PDF version of this blog post is also available here: https://soroush.secproject.com/downloadable/Analysis_of_setting_cookies_NCCGroup_blog.pdf