Skip to main content

CSRF - File Upload PoC

A couple of weeks ago I have found myself working on a CSRF File Upload Proof-of-Concept (PoC) for a bug I have found in an Oracle product.

I remember that Krzysztof Kotowicz did some research on a similar PoC not long time ago. A quick Google search brought me to his article on invisible arbitrary file upload in Flickr. So instead of reinventing the wheel, I have tried to use his PoC code available here.

Unfortunately, the code was not working in my case and I was unsure whether that was depending on the browsers I was using (Firefox 8.0.1 and Chrome 15.0.874.121) and/or on the vulnerable application itself. Consequently, I have spent some time to come up with a PoC (or probably a good term would be a collage) which would work in my case. The technique used is the same illustrated in Kotowicz's research and more information can be found here.

In few words, the exploitation process is divided in two steps:

1) Use XHR to get a binary file and store it as a JavaScript object;
2) Then perform a cross-domain XHR POST request (using CORS) to send/upload the binary file to the vulnerable application.

Here is the PoC I have composed by taking pieces of code from different parts. For the curios reader, here is the diff output between my PoC and Kotowicz's one.

Following is a short summary of the collage:

Supporting multiple parameters

I just reused the same functions in Kotowicz's Flickr PoC to support multiple POST parameters.

Grabbing the binary file

I am using snippet code from here - the getBinary() function works fine in the latest Firefox (8.x) and Chrome (15.0.874.121).

Blob Type

I have integrated sendUpload() function into the fileUpload() one, with a modification around the Blob type, which is used to store the binary file. Below is the modified line:

var bb = new (window.BlobBuilder || window.WebKitBlobBuilder)();

This change was done because Chrome was complaining about the New BlobBuilder data type used in the original sendUpload() function.

Further Notes

The getBinary() function is used to get the file and considering CRSF occurs from a malicious site, then there are no issues with SOP, as the malicious file is served from the same domain.

A minor issue that I encountered during this work was related to single and double quotes in the filename value. In Kotowicz's original PoC, the Content-Disposition: header is set as an "attachment". The filename value is quoted with single quotes. However, in my case the single quotes PoC was not working. I have noticed that Firefox and Chrome automatically quote the filename with double quotes when the upload is performed with user interaction. The excerpt below is from an intercepted file upload request with Firefox:

POST /vulnerableappupload HTTP/1.1
Host: apphost
Content-Type: multipart/form-data; boundary=---------------------------9040894219264
Content-Length: YYYY

Content-Disposition: form-data; name="extraParam1"

Content-Disposition: form-data; name="extraParam2"

Content-Disposition: form-data; name="filenameId"; filename="test.png"
Content-Type: image/png

However, in some cases, it is possible to successfully upload a file by submitting the filename between single quotes or even without quotes. It depends on the way the file upload application functionality parses the Content-Disposition: header and related values from the browser.

Beside, I also did realise (lately) that there was a more recent PoC commit pushed by Kotowicz which was using the double quotes approach. My bad for missing it, as it would have saved quite some time.

Anyway, I got curios about the single quote/double quote issue and I had checked the RFC 2813. It doesn't specify whether the filename value has to be enclosed with single quotes or double quotes, so I am assuming that depends on the browser. Actually, in the examples included in the RFC 2813, the filename doesn't have quotes at all!

For those readers who are more interested, here is a page including a comprehensive testing conducted against the Content-Disposition header using different browsers.

Another minor note should be paid to the boundary value used in the file upload. The boundary in a multipart/byte request is a MIME boundary. This boundary value should not appear anywhere else in the data except between the multiple parts of the data. Also, the boundary value has to be the same to separate each part, so if you intend to reuse the PoC make sure you don't mess with that. I did that resulting in further wasted time :-).


The PoC would only work for a single step file upload process. If the application requires multiple steps to complete the file upload, then further logic needs to be added to the PoC.


Popular posts from this blog

Pwning a thin client in less than two minutes

Have you ever encountered a zero client or a thin client? It looks something like this... If yes, keep reading below, if not, then if you encounter one, you know what you can do if you read below... The model above is a T520, produced by HP - this model and other similar models are typically employed to support a medium/large VDI (Virtual Desktop Infrastructure) enterprise. These clients run a Linux-based HP ThinPro OS by default and I had a chance to play with image version T6X44017 in particular, which is fun to play with it, since you can get a root shell in a very short time without knowing any password... Normally, HP ThinPro OS interface is configured in a kiosk mode, as the concept of a thin/zero client is based on using a thick client to connect to another resource. For this purpose, a standard user does not need to authenticate to the thin client per se and would just need to perform a connection - e.g. VMware Horizon View. The user will eventually authenticat

Microsoft .NET MVC ReDoS (Denial of Service) Vulnerability - CVE-2015-2526 (MS15-101)

Microsoft released a security bulletin ( MS15-101 ) describing a .NET MVC Denial of Service vulnerability ( CVE-2015-2526 ) that I reported back in April. This blog post analyses the vulnerability in details, starting from the theory and then providing a PoC exploit against a MVC web application developed with Visual Studio 2013. For those of you who want to see the bug, you can directly skip to the last part of this post or watch the video directly... ;-) A bit of theory The .NET framework (4.5 tested version) uses backtracking regular expression matcher when performing a match against an expression. Backtracking is based on the NFA (non-deterministic finite automata) algorithm engine which is designed to validate all input states. By providing an “evil” regex expression – an expression for which the engine can be forced to calculate an exponential number of states - it is possible to force the engine to calculate an exponential number of states, leading to a condition defined su

UXSS in McAfee Endpoint Security, and some extra goodies...

During the HITB2017AMS talk given in Amsterdam with  @Steventseeley , I promised that I would have disclosed vulnerabilities affecting a security vendor product other than Trend Micro. For those who have come to my blog for the first time and are looking at "insecurities" of security vendors, you might be interested as well on how we found 200+ remote code execution vulnerabilities in Trend Micro software ... But this blog post is dedicated to two McAfee products instead: McAfee Endpoint Security and SiteAdvisor Enterprise (now part of McAfee Endpoint Security). For simplicity, I will just refer to McAfee Endpoint Security for the rest of this post. First let's demonstrate a particular type of XSS, a UXSS, considering that fact that it only affects the McAfee Endpoint Security plugin and does not depend on a particular web site or web application. There are two different injection points: - UXSS when user visits a red labelled web site - the payload is rendere