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

TrendMicro ScanMail for Microsoft Exchange (SMEX) predictable session token - CVE-2015-3326

It's time for another advisory ( CVE-2015-3326 ), a simple one, for a vulnerability which can be found quickly and trivially. For those of you who just want to give a glance at the post, I suggest to directly watch the picture which says it all! The following vulnerability was discovered on TrendMicro SMEX (ScanMail for Microsoft Exchange) 10 SP2 but it affects other versions as well. While surfing the SMEX web administrative interface using a web proxy, I have noticed something in the HTTP request - the session token itself and its format, a number. After observing a significant number of logins, the session token was always represented with an number composed of minimum 4 digits and maximum 5 digits, as shown in the screen shot below:   Although the observed session tokens were never generated sequentially, the lack of a cryptographically strong PRNG for the session identifier, allows a malicious user to trivially guess the token. This attack can be easily automated.

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

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