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
[snip]
Content-Type: multipart/form-data; boundary=---------------------------9040894219264
Content-Length: YYYY

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

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

value2
-----------------------------9040894219264
Content-Disposition: form-data; name="filenameId"; filename="test.png"
Content-Type: image/png
[snip]

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

Constraint

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.