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

Comments

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

Alcatel Lucent Omnivista or: How I learned GIOP and gained Unauthenticated Remote Code Execution (CVE-2016-9796)

It is time for another advisory or better a blog post about Alcatel Lucent Omnivista  and its vulnerabilities. Omnivista is a central management network tool and it is typically used in medium/large organisation with a complex VoIP/SIP infrastructure. Interestingly enough, this software belongs to the niche of "undownloadable" software and it requires a license to work as well. My "luck" came during an engagement where it was already installed and this post documents one of the many 0days discovered during such audit. The reasons why I wanted to dedicate a single blog post on this vulnerability are several. First, remote code execution (RCE) is always a sweet bug to show. Second, I strongly believe that documenting vulnerabilities in applications using old protocols and standards, respectively GIOP and CORBA, can be beneficial for the infosec community, since no many examples of vulnerabilities in such applications are available or published on the Interne

Trend Micro Threat Discovery Appliance - Session Generation Authentication Bypass (CVE-2016-8584)

In the last few months, I have been testing several Trend Micro products with Steven Seeley ( @steventseeley ). Together, we have found more than 200+ RCE (Remote Code Execution) vulnerabilities and for the first time we presented the outcome of our research at Hack In The Box 2017 Amsterdam  in April. The presentation is available as a PDF or as a Slideshare . Since it was not possible to cover all discovered vulnerabilities with a single presentation, this blog post will cover and analyze a further vulnerability that did not make it to the slides, and which affects the Trend Micro Threat Discovery Appliance (TDA) product. CVE-2016-8584 - TDA Session Generation Authentication Bypass This was an interesting vulnerability, discovered after observing that two consecutive login attempts against the web interface returned the same session_id token. Following this observation, our inference was that time factor played a role. After further analysis and reversing of the TDA libra