There are 5 web application security questions that have been set as a challenge. You will receive points based on your solutions (please see the Pointing System). The deadline for this challenge is end of May 2012.
You can use your twitter ID to be followed by other people who follow this challenge. You can also send me a link to your blog/website/twitter to be linked in the table.
Please send your solutions with the subject: “SecProject Web AppSec Chal1 – Your Name” to sdalilimail-challenge1 [at] yahoo [d0t] com. Please do not send the solutions to any other email address.
Hall of Fame:
There is a direct link to Hall of Fame accessible via Project menu:
Click here to see Hall of Fame
(http://soroush.secproject.com/blog/projects/hall-of-fame-challenge-series-1/)
| Deadline: 1st of June – 24:00 GMT |
The rules are as follows:
General Rules:
1- Identical answers will be counted only for the first reporter.
2- Please do not use automated tools on the targets as they can lead to a denial of service for other contestants.
3- Please do not publish your answers till the deadline. Thanks in advance.
XSS Rule(s):
You need to “alert” your name on the screen. You are not allowed to create a new HTML tag.
Note: it is ASP!…
SQL Injection Rule(s):
You need to exploit the provided sample website to: 1- read the admin password and 2- achieve the secret text which means you have reached the forbidden area successfully.
I think you need to take a look at the source code for this one! The database is a MS Access database which makes it more challenging.
Vuln Bank Application Rule(s):
You need to increase your total money to more than 100.
You have the source code (ASP VBScript) to be able to try this vulnerable bank application offline. (“resetall.asp” is just for debugging purposes)
Questions are as follows:
Download links are as follows:
- http://Soroush.secproject.com/downloadable/secproject.com-challenge1.zip
- http://sdl.me/challenge1/secproject.com-challenge1.zip
XSS1:
Test Target = http://sdl.me/challenge1/xss1/JsChallenge1.asp
XSS2:
Test Target = http://sdl.me/challenge1/xss2/JsChallenge2.asp
XSS3:
Test Target = http://sdl.me/challenge1/xss3/JsChallenge3.asp
SQL Injection:
Test Target = http://sdl.me/challenge1/sqli/
Vuln Bank Application:
Test Target = http://webapsecchall01.brinkster.net/vulnbankapp4543334/ [currently does not work due to the hosting problem - please run it locally for your testing]
Note: A fresh target will be provided for you if you can explain the vulnerability correctly and you want to exploit it.
Goals and Pointing System:
XSS Points (Max 60 Points – Per Each):
Mozilla Firefox 12.0 without NoScript: +5 Points
IE9 Anti-XSS Bypass: +15 Points
Latest Chrome Anti-XSS Bypass: +10 Points
IE9 & Chrome at the same time with 1 link: +5 Points
NoScript Bypass: +25 Points
Note: In order to get the points, you need to send me the link(s) that will lead to an “alert” message by opening it. If you are using any specific encoding/packing that make your inputs unreadable, you need to explain your method briefly. If each link is related to a specific browser, please mention that as well next to it.
Amendment (new): XSS3 now has double points (120 points in total) due to a problem in its implementation which made it extremely hard.
SQL Injection Point (Max 60 Points):
Reading the admin password: 20 Points
Running the code in the critical area of the code and achieving the secret code: 40 Points
Note: In order to get the points, you need to send me the link(s) that can perform the attack along with its explanation.
Virtual Bank Application Point (Max 60 Points):
Correct Explanation: 20 Points
Exploitation on a Custom Website: 40 Points
Note: In order to get the points, please send your explanation in English. If you think it is easier for you to send me a video link for this exploit, you can also add that to your explanation. Please tell me if you want to exploit the vulnerability on a sample link, then I can send you the relevant link if your explanation was correct.
History of These Questions:
This challenge is based on real and interesting issues that I have seen during my web application testing. I thought it can be good to share some of them with you to challenge your skills. The XSS issues came from an issue in Yahoo.com website two years ago which has been fixed now. The SQL Injection issue was inside a popular web application which I cannot announce its name and you may already know it; and the last issue is a general vulnerability of many web applications.
I have added some spice to the questions to make them even more interesting. All of these issues are exploitable (XSS3 has not been tested previously), but you need to be initiative to get more points.
Thanks to: Mario Heiderich, Ben Sheppard, and Gareth Heyes for their comments on this challenge. As they do not have the answers, they can still attend this challenge!
My name has recently been added to the “Facebook Whitehat (http://www.facebook.com/whitehat)” page among the other security researchers that have reported security issues to Facebook directly. I have also received a very good reward for this; it took them several months to investigate my request, but it was worth it.
I am writing about it here to say you do not always need to know how to code or have ninja skills to find the bugs like this; I want to encourage everyone to participate in security bug bounty programs to help the companies to be more secure and earn money at the same time!
After all, here are the details (this bug has already been patched by Facebook):
Title of reported issue: “How to find unsearchable people by their emails in Facebook”
In order to search someone -even if they made themselves unsearchable with hidden emails- by their email addresses, it was possible to do the following steps:
1- Login into your Facebook account (you need to have an activated account with a verified email).
2- Open the following page: https://www.facebook.com/ads/manage/settings.php
3- Now under the “Permissions” section, click on “Add a User”.
4- Enter the email address that you are looking for in the box and click on “Add” and wait to see the response (it is better to choose “Reports Only” instead of “General User”). If you have not received “Invalid User” error, it means you were successful.
5- Now after refreshing the page, you should be able to see the requested user under the “Permissions” area.
6- If you click on the user’s name, you should be able to see his/her public profile.
By using this method, you could be able to find First Name, Last Name, and Facebook User ID of the user just by having his/her email address.
Recommendation to the users:
- It is always better to use a private email address in social networking websites if you really want to be unsearchable.
Recommendation to the Developers in similar situation:
- If there is any policy in the application, it should apply to all different parts of it. I suggest using the shared secure libraries that meet the requirements is one of the best options.
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
Twitter
LinkedIn