Introduction:

This post is going to introduce a new technique that has not been covered previously in other topics that are related to file upload attacks such as Unrestricted file upload and File in the hole.

Update 3 (01/11/2016)

 Title was changed from “Cross Domain Data Hijacking” to “Cross-Site Content Hijacking” to reflect the issue better. This issue can also be called “Cross-Site Data Hijacking“. The recommendations section was updated as well.

The following posts were created based on this topic:

https://www.acunetix.com/vulnerabilities/web/cross-domain-data-hijacking

https://dunnesec.com/2014/05/26/cross-domain-hijack-flash-file-upload-vulnerability/

The following tool was created to exploit this issue as a proof of concept – this project covers multiple methods such as by using Flash, PDF, or Silverlight:

https://github.com/nccgroup/CrossSiteContentHijacking

Update 2 (21/05/2014)

Ok! People in twitter were very resourceful and reminded me that this was not in fact a new technique and some other bug bounty hunters are already using it in their advisories! I wish they had documented this properly before. The following links are related to this topic:

http://50.56.33.56/blog/?p=242 (Content-Type Blues)

https://bounty.github.com/researchers/adob.html (Flash content-type sniffing)

Update 1 (21/05/2014):

It seems @fransrosen and @avlidienbrunn were quicker than me in publishing this technique! Yesterday they have published a very good blog post about this issue: http://blog.detectify.com/post/86298380233/the-pitfalls-of-allowing-file-uploads-on-your-website

I highly recommend the readers to read the other blog post as well especially for its nice JSONP trick.

I wanted to wait until end of this week to publish mine but now that this technique is already published, I release my post too. The draft version of this post and PoCs were ready before but I was not sure when I am going to publish this as it would affect a lot of websites; this was a note for bug bounty hunters!

The only point of this blog post now is the way that I had looked at the issue initially.

How safe is the file uploader?

Imagine that there is a file uploader that properly validates the uploaded file’s extension by using a white-list method. This file uploader only allows a few non-dangerous extensions such as .jpg, .png, and .txt. Moreover, it checks the filename to not contain any non-alphanumeric characters!

This seems to be a simple and a safe method to protect the server and its users if risks of file processors’ bugs and file inclusion attacks have already been accepted.

What can possibly go wrong?

This file uploader does not have any validation for the file’s content and therefore it is possible to upload a malicious file with a safe name and extension on the server. However, when the server is properly configured, this file cannot be run on the server. Moreover, the file will be sent to the client with an appropriate content-type such a text/plain or image/jpeg; as a result, an attacker cannot exploit a cross-site scripting issue by opening the uploaded file directly in the browser.

Enforcing the content-type by using an OBJECT tag!

If we could change the file’s content-type for the browsers, we would be able to exploit this issue! But nowadays this is not simply possible directly as this counts as a security issue for the browser…

I knew straight away that the “OBJECT” tag has a “TYPE” attribute but I was not sure which content-types will force the browser to actually load the object instead of showing the contents (“OBJECT” tag can act as an IFrame). I have created a test file (located at http://0me.me/demo/SOP/ObjectMimeType.html) that loads the object tags with the different mime-types and the result is as follows (Java and Silverlight were not installed):

“application/futuresplash”: load the file as a Flash object

“application/x-shockwave-flash”: load the file as a Flash object

“text/x-component”: only works in IE to load .htc files(?)

“application/pdf” and a few others: load the file as a PDF object

The result can be different with having different plugins installed.

So I can load any uploaded file as a flash file. Now I can upload a malicious flash file into the victim’s server as a .JPG file, and then load it as flash file in my own website. Please note that there is no point for me to upload a flash file that is vulnerable to XSS as it would run under my website’s domain instead of the target.

Exploitation

I found out that the embedded flash can still communicate with its source domain without checking the cross-domain policy. This makes sense as the flash file belongs to the victim’s website actually.

As a result, the flash file that has been uploaded as a .JPG file in the victim’s website can load important files of the victim’s website by using current user’s cookies; then, it can send this information to a JavaScript that is in the attacker’s website which has embedded this JPG file as a Flash file.

The exploitation is like a CSRF attack, you need to send a malicious link to a user who is already logged-in in the victim’s website (it still counts as CSRF even if you are not logged-in but this is out the scope of this post). The malicious Flash should have already been uploaded in the victim’s website. If the uploader is vulnerable to a CSRF attack itself, an attacker can first upload a malicious Flash file and then use it to hijack the sensitive data of the user or perform further CSRF attacks.

As a result, an attacker can collect valuable information that are in the response of different pages of the victim’s website such as users’ data, CSRF tokens, etc.

The following demonstrates this issue:

A) 0me.me = attacker’s website

B) sdl.me = victim’s website

C) A JPG file that is actually a Flash file has already been uploaded in the victim’s website: http://sdl.me/PoCs/CrossDomainDataHijack.jpg

(Source code of this Flash file is accessible via the following link:

http://0me.me/demo/SOP/CrossDomainDataHijack.as.txt )

D) There is a secret file in the victim’s website (sdl.me) that we are going to read by using the attacker’s website (0me.me): http://sdl.me/PoCs/secret.asp?mysecret=original

E) Note that the victim’s website does not have any crossdomain.xml file: http://sdl.me/crossdomain.xml

F) Now an attacker sends the following malicious link to a user of sdl.me (the victim’s website):

http://0me.me/demo/SOP/CrossDomainDataHijackHelper.html

By pressing the “RUN” button, 0me.me (attacker’s website) website can read contents of the secret.asp file which was in sdl.me (victim’ website). This is just a demo file that could be completely automated in a real scenario.

Note: If another website such as Soroush.me has added sdl.me as trusted in its crossdomain.xml file, the attacker’s website can also now read the contents of Soroush.me by using this vulnerability.

Limitations

An attacker cannot read the cookies of the victim.com website.

An attacker cannot run a JavaScript code directly by using this issue.

Future works

Other client-side technologies such as PDF, Java applets, and Silverlight might be used instead of the Flash technology.

Bypassing the Flash security sandbox when a website uses “Content-Disposition: attachment;” can also be a research topic. If somebody bypasses this, many mail servers and file repositories will become vulnerable.

Recommendations

Please find the recommendations in the following project: https://github.com/nccgroup/CrossSiteContentHijacking