Web AppSec ninja, semicolon character enthusiast!

Tag Archives: ASP.NET

I have recently published a blog post via NCC Group’s website about the deserialization issue by abusing the ASP.NET resource files (.resx and .resources extensions). A number of products were exploited and some file uploaders can also be vulnerable to this type of attack.

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/

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).

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.

.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:

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:

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:

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:

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:

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:

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.