Sometimes no Ninja skill is required to receive money from security bug bounty programs!

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.

Drag and Drop XSS in Firefox by HTML5 (Cross Domain in frames)

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);”

IIS5.1 Directory Authentication Bypass by using ":$I30:$Index_Allocation"

Download this advisory from: http://soroush.secproject.com/downloadable/IIS5.1_Authentication_Bypass.pdf
or: http://0me.me/demo/IIS/IIS5.1_Authentication_Bypass.pdf

Description:
Although IIS5 is very old, finding one is not impossible! Therefore, I want to introduce a technique to bypass the IIS authentication methods on a directory.
This vulnerability is because of using Alternate Data Stream to open a protected folder.
All of IIS authentication methods can be circumvented. In this technique, we can add a “:$i30:$INDEX_ALLOCATION” to a directory name to bypass the authentication.
In a protected folder such as “AuthNeeded” which includes “secretfile.asp”:
It is possible to run “secretfile.asp” by using:
“/AuthNeeded:$i30:$INDEX_ALLOCATION/secretfile.asp”
Instead of:
“/AuthNeeded/secretfile.asp”

More description:
Why IIS6 and 7 are not vulnerable:
- In these versions, IIS does not accept colon (“:”) character from the URL before the querystring.

Why we cannot use “::$Data” in IIS 5.1 anymore:
- IIS rejects the request if its URL contains “::$” (before querystring).

Why IIS5 is vulnerable to “Directory Authentication Bypass” by using “:$I30:$Index_Allocation”:
- IIS only verifies the directory name to check for authentication. Therefore, we can use “http://victim.com/SecretFolder:$I30:$Index_Allocation/” instead of “http://victim.com/SecretFolder” to bypass the authentication.

Is it possible to bypass something else by using “:$I30:$Index_Allocation” on a NTFS partition:
- If a checking is only based on the directory name, it can be bypassed by using this method.

Download this advisory from: http://soroush.secproject.com/downloadable/IIS5.1_Authentication_Bypass.pdf
or: http://0me.me/demo/IIS/IIS5.1_Authentication_Bypass.pdf

Crowzers or Carzy Browsers:

I need to translate this word first:
Carzy Browsers = Crowsers

Now, I want to share some odd behaviour of browsers with you. Let’s make them Crazy!

 1- First, we load a URL in an IFrame. Then, we load another website on the same frame. Now, by using “javascript:window.history.go(0)”, it will change the IFrame SRC to the first URL,  but it keeps the 2nd website on the IFrame!

 Try it here: http://0me.me/demo/crowzers/irsdl/addressbar_halt.html

 Which Browsers?

  - Mozilla Firefox 3.6.6

  - IE7

  - IE8

 2- We want to lock the address bar in different browsers by using “onblur” and “onload” events with “this.focus()”.

 Try it here: http://0me.me/demo/crowzers/irsdl/iframe_src_fool.html

 Which Browsers?

  - Mozilla Firefox 3.6.6

  - IE7

  - IE8

  - Opera 10.54

 3- We want to stop the browsers from working by using infinite loops and so on.

 Try it here: http://0me.me/demo/crowzers/irsdl/halt.html

 Which Browsers?

  - Mozilla Firefox 3.6.6: Halted with Mozilla Crash Reporter

  - IE7: Halted

  - IE8: Halted

  - Safari 5: Crashed on “javascriptcore.dll”

Good luck!

Opera Browser – Scroll Information Leakage

In Opera Browser, “scrollTop” and “scrollLeft” properties of a frame are accessible through the main page. This may lead to cross site information leakage.

Tested Platform: Opera <= 10.54 AND 10.60 RC (Build 3443)

Proof of Concept:

http://0me.me/demo/opera_scroll_leak/test_scroll.html

UPDATE:
Why is it really an issue?

I think it is one kind of bypassing same origin policy. All other famous browsers are secured against this method.

My point is: If you use “#” character, you can jump to a certain point of page in case having that Element’s ID.

It is shown in my proof of concept if you look at:

http://0me.me/demo/opera_scroll_leak/test_scroll.html

I used two URLs with different Element IDs to collect the user’s information from Facebook:

First, by using the following URL, I can check if the user is logged-in in facebook. It will jump to “#pass” point which is only available in case of having login form at the top of the page.

http://www.facebook.com/Opera?ref=ts&v=wall#pass

Then, as there is a SMS subscription on the Opera Browser Wall (http://www.facebook.com/Opera) when you are the fan, I can find it out by using “#sms_status_subscribe” in the following URL:

http://www.facebook.com/Opera?ref=ts&v=wall#sms_status_subscribe

 

And that’s why…!

Cross Site URL Hijacking by using Error Object in Mozilla Firefox

In this paper, I want to represent a method for performing Cross Site URL Hijacking (which we can call XSUH) by using the error object of Mozilla Firefox. XSUH attack is used to steal another website URL. This URL can show the client’s situation on that website, and it can contain confidential parameters such as session ID as well. There is another useful article with a similar purpose but with a different approach which is “XSHM” article of CHECKMARX , and reading this article is highly recommended to you as well.
As you might know, scripts error handling in Mozilla Firefox is quite useful for the developers as it can show the exact source of an error with some useful information. Now, this functionality can be misused to divulge the destination URL after the redirections (XSUH attack) which can lead to condition leakage or stealing some important parameters from the URL.

Download From Here: http://soroush.secproject.com/downloadable/XSUH_FF_1.pdf
Or Here: http://0me.me/demo/XSUH/XSUH_FF_1.pdf

Proof of Concept: http://0me.me/demo/XSUH/XSUH_demo_firefox_all_in_1.html

Note:  This technique has been tested on Mozilla Firefox 3.6.3, 3.5.9, 3.6.4build5 (26th May 2010).

IE7-8 drive list enumeration!

Iframe delay in loading the local drives in IE7 and IE8 can cause drive list enumeration!
Proof of Concept is available from this link:
http://plaincipher.com/demo/IE-Drive-Enum-Demo.html

Cheers,
Soroush Dalili

Microsoft IIS Semi-Colon Vulnerability

I found a vulnerability in Microsoft IIS when I was searching about a method to execute an ASP file when we can only upload a JPG file.

The result was too simple, but interesting! I need only a semicolon between the “.asp” and the “.jpg” to execute an ASP file. So, the answer was “myfilename.asp;,jpg”. I have written some information about this vulnerability in:

http://soroush.secproject.com/downloadable/iis-semicolon-report.pdf

I’ll try to update this PDF file if there was a need to add or change some information.

Description of this vulnerability from Secunia.com is:

Description:
Soroush Dalili has discovered a vulnerability in Microsoft Internet Information Services (IIS), which can be exploited by malicious people to potentially bypass certain security restrictions and compromise a vulnerable system.

The vulnerability is caused due to the web server incorrectly executing e.g. ASP code included in a file having multiple extensions separated by “;”, only one internal extension being equal to “.asp” (e.g. “file.asp;.jpg”). This can be exploited to potentially upload and execute arbitrary ASP code via a third-party application using file extensions to restrict uploaded file types.

The vulnerability is confirmed on a fully patched Windows Server 2003 R2 SP2 running Microsoft IIS version 6. Other versions may also be affected.

There are also several websites which wrote about this weakness:

1. Secunia Advisory: Microsoft IIS ASP Multiple Extensions Security Bypass

2. Securityfocus: Microsoft IIS Malformed Local Filename Security Bypass Vulnerability

3. The Register: Microsoft IIS vuln leaves users open to remote attack

4. VUPEN Security: Microsoft IIS File Extension Processing Security Bypass Vulnerability

5. Securitytracker: Microsoft Internet Information Services (IIS) Filename Extension Parsing Flaw May Let Users Bypass Security Controls

My Previous Advisories

I put my previous advisories at this page: My Previous Advisories

Thank you for visiting my homepage