Pages

Thursday, June 18, 2015

Same Origin Method Execution (SOME)




This blog post is a brief presentation of "Same Origin Method Execution" (SOME). SOME is a web application attack which abuses callback endpoints (mainly Flash applets and JSONP endpoints to which OAuth dialogs often redirect to -- redirect_uri) by forcing a victim into executing arbitrary scripting methods of any page on the endpoint’s domain. The impact of a SOME attack is similar to the impact of Cross-Site Scripting, though there are some important and distinguishing exploitation restrictions. In spite of limitations, it is vital and valid to say that the attack is not limited to a specific web functionality/page nor confined in terms of UI or HTTP response headers. In fact, using a payload of only alphanumeric characters and a dot will allow attackers to hijack dangerous web functionality and even exfiltrate sensitive user data such as private photos and/or videos. 
Popular domains like Google, Yahoo, Microsoft (plus.google.com, maps.yahoo.com, yammer.com and so on) along with the very popular platforms - Wordpress and VideoJS (which turned numerous domains vulnerable to SOME) were affected by SOME. Many were recently fixed (responsible disclosure details are mentioned below).


Paper, Demo and Slides from BlackHat

If you wish to invest your time in exploring the fascinating technical details in-depth, you are encourage to read my white-paper, or look at the updated Black-Hat presentation. The slides include a demonstration video of a SOME exploit - you can see how I used SOME to hijack Google cloud’s private photo and video albums. 

By the way, you can also find more details about the breach I am talking about in my previous blog post: Stealing private photo albums from Google

Attack Scenario:

To understand the SOME attack we first need to cover some general aspects, so bear with me:
  • Web browsers allow execution of a variety of methods without considering the given arguments, for example: form1.submit(“ignored”,”ignored”); will evaluate exactly as the following natural version: form1.submit(); will. Therefore, an external control over the prefix/padding before the parenthesis (as often given by many callback implementations) would be enough for hijacking dangerous web functionality regardless of the arguments.
  • In an environment with multiple windows and their respective  documents, redirecting any of the documents will re-enforce Same Origin Policy to restrict cross-site window documents’ DOM access. However, web browsers would not delete memory references to other window objects post-redirection. For instance, whenever a document opens a popup window, the browser will add a memory reference pointing to this document and save it as the window.opener property of the new window. Regardless of any redirections this reference would continue to work unless it is explicitly deleted or destroyed.
  • Most callbacks endpoints are designed to only allow a limited set of characters as a callback parameter value. This is commonly done by the following regex [a-zA-Z0-9_\.], or in other words, a char-set consisting of alphanumeric, a dot and an underscore. Let me add that crafting a SOME exploit requires only alphanumeric and a dot charset. 
  • Interaction between different browsing contexts is often applied via callback execution. For instance, Flash applets and/or other callback endpoints (e.g. OAuth dialogs) commonly execute a callback function to notify events to a different browsing context. As a result, in cases where this callback can be controlled via a HTTP parameter, an attacker would be able to control and replace the execution browsing context (e.g. by redirecting the opener window document). Analogically, the function/method that the interpreter executes could also be controlled by the attacker.

Same Origin Method Execution abuses the nature of user agents by forging a setup of windows/frames, in turn redirecting their documents. Using references created by this setup within a callback parameter will allow replacing the execution context with a targeted document and hijacking an existing web functionality within it.

Manipulating a Surface for Method Execution

Initial steps:
  1. Firstly, the attacker has to detect a vulnerable instance - either a plugin or a vulnerable callback endpoint document. A vulnerable instance is the one that leads the browser’s interpreter towards active execution of a function name supplied by a (callback) parameter value.
    Note: Instances that respond with passive mime types like application/json are not vulnerable when accessed directly. 
  2. In the second preparatory step the attacker has to choose a target webpage hosted on the same domain (http://www.vulnerable-domain.com/photoAlbums). Aiming at hijacking a web functionality (e.g. object method, javascript function) of this target webpage, the attacker shall assemble a reference using DOM navigation or a direct reference pointing to it, for example: document.body.privateAlbum.firstChild.nextElementSibling.submit
Setting up the Exploit:
  1. For setting up SOME and creating the appropriate window references, one has to create an exploitation surface/environment by opening a new browsing context (WIN1).

  2. Once the environment is ready, the initiating page (MAIN) shall redirect its document to any desired target page on the endpoint’s domain (http://www.vulnerable-domain.com/target_document).
  3. Following the redirection, the new browsing context (WIN1) shall wait for the targeted document’s DOM loading completion.
  4. Once ready, for hijacking a method execution, the new browsing context (WIN1) would redirect its document to the vulnerable instance set with an arbitrary callback parameter, for example:

    http://www.vulnerable-domain.com/flash-plugin.swf?callback=
    opener.document.body.privateAlbum.firstChild.nextElementSibling.submit


Demo of designating the execution context for executing an alert:






PoC:
@Main Page:
<script> 
function startSOME() { 
 window.open("step1.html");
 location.replace("http://www.vulnerable-domain.com/privateAlbum");
} 
document.body.addEventListener("click",startSOME); //Popup Blocker trick
</script>


@step1.html:

<script>
function waitForDOM() {
      location.replace("http://www.vulnerable-domain.com/flash-plugin.swf?callback=opener.document.body.privateAlbum.firstChild.nextElementSibling.submit");     
}
setTimeout(waitForDOM,3000);
</script>


Mitigation and Fix
  1. Static Callbacks - Exploiting Same Origin Method Execution relies on abusing a callback parameter. Many web applications can actually maintain their same existing functionality without having to dynamically set callbacks. Thus, when applicable, websites should use fixed callback values as opposed to externalizing the callback control.
  2. White-list approach – In cases where the web application is designed for supporting more than a single callback per endpoint, or, alternatively, where maintaining a high flexibility is highly important (common in Flash plugins), it is better to set a white-list and match the given callback parameter value against it. This would enforce and verify that only legitimate callback functions can execute.UPDATE: I am working on a JavaScript defense library aiming to serve as a generic and easy to deploy solution.
  3. Cross-Domain Messaging – Use postMessage for notifying events and interacting to and from cross-domains as an alternative to javascript callback execution (if applicable).

Responsible Disclosure:

Oct 30, 2014: Google fixed a vulnerable instance – Google Plus.
Nov 06, 2014: Microsoft fixed a vulnerable instance – Yammer.
April 21, 2015: Wordpress fixed a vulnerable instance – Plupload.

(Kudos to @zoczus for finding yammer and plupload instances)

The issue of callback exploitation is known to a certain level in the infosec community, although until recently the attack did not catch enough attention. For that reason website owners, including the leading players, still rely on developers’ habits and experience. More importantly, no ‘best practice’ or standard was published as of now. Thus I chose to shed some light on Same Origin Method Execution and callback endpoints during the BlackHat conference. Several aspects of Same Origin Method Execution have been discovered by top researchers namely Google's Aleksandr Dobkin and LinkedIn's Roman Shafigullin. They both certainly deserve credit here.

It is noteworthy that Google Bug Bounty deemed this attack’s impact similar to that of cross-site scripting. 

Microsoft Bug Bounty deemed this attack’s impact similar to that of cross-site scripting.

Wordpress classified this attack like "XSS" in their critical security release (Apr. 2015 - WordPress 3.9-4.1.1 - Same-Origin Method Execution).

The Same Origin Method Execution attack can lead to ugly and critically severe consequences for its targeted victims. Keep in mind that the attack’s risk is considered as high as the risk of Cross-site scripting, rated the "third most risky attack" in OWASP top 10 project - that is A3 Cross-site scripting (XSS). To conclude, it is really important to abandon the misconception that a narrow set of characters somehow guarantees safety and security, of your web applications. Further, we should strive to raise the developers’ awareness of SOME.

Monday, May 25, 2015

Stealing Private Photo Albums from Google - Same Origin Method Execution


It has been a long time since I updated this blog since I focused on company blogs and Black Hat presentations for the last couple of years. It is time to kick in with details about the vulnerable Google instance I was demonstrating during my Black Hat EU presentation – Same Origin Method Execution. Using that instance and a payload of only alphanumeric characters and a dot I was able to hijack web functionality and thereby delete or steal private photo albums from Google Plus. A white paper is currently in review stages and will be released next week in my next post! 



Same Origin Policy and OAuth overview:

From time to time and for numerous reasons web applications interact with external third-party services. Some of these reasons may be importing information (e.g. import contact list), notifying events, getting delegated access to resources such providing a "Login with" systems and etc. 

Since an external service often (if not always) means a different security context, interacting with it will require overcoming Same Origin Policy (SOP). One of the most common interfaces for such third-party interaction these days is using OAuthentication dialogs. OAuth dialogs are hosted on third-party resource providers and are designed to ask the resource owner (the user) to allow/deny access from the website to the user's (resource owner) private resources. Once an answer is given the dialog will redirect (call) the user back to a callback page hosted on the website which asked for access, this page is called the “callback endpoint”. The purpose of the callback endpoint is to receive a token from the third-party and notify the requesting website. Although, since no best practice was created for building callback endpoints, the technique web developers use to save the token and notify the initiating page (call it back) is based entirely on developers’ habit and experience. Therefore many times callback endpoints end up prone to “Same Origin Method Execution”.


The vulnerable instance:

How many times have you noticed a "Login with", import contacts or friend lists from third-party service? 



As in many other websites Google Plus provides an option to import external contacts information from third-party resource providers such as Yahoo and Microsoft, Prior to the responsible disclosure the authorization process occurred as follows:

  1. Google Plus opened a pop-up for the OAuth dialog asking secure delegated access to the user’s external contact-list on Yahoo/Microsoft, to avoid losing the currently open document content.  
  2. After the user allows/denies the access, the dialog window document is redirected to a Google Plus callback endpoint consisting a callback URL parameter.
  3. The endpoint page uses the value provided by the parameter to notify the opener and deliver the access token (JSONP style).
Callback endpoint URL:

https://plus.google.com/c/u/0/auth?src=connectedaccounts&callback=callback_function_name&dest=microsoft2&[...snip...]
Accessing the callback endpoint URL directly responded with the following markup:

<html><body><script type="text/javascript">
window.opener.callback_function_name({"status":0,"token":"ItHumYWI[...snip..]","oauthstate":"1234","tokenid":"ToKeN1234","tokenexp":"0","gid":"401223423..","siteid":6,"displayname":"Ben Hayak","profileurl":"http://profile-url.com"});
</script></body></html>



Is that Cross-site scripting?

Of course the first thing to try here was Cross-site Scripting, although fortunately ;) in similarity to most callback endpoint implementations only a specific set of characters were allowed as a callback value specifically alphanumeric a dot and underscore [A-Za-z0-9_\.]. We can however use tricks like document.write, eval, etc, though as aforementioned in the markup above no user controlled input got inside the parenthesis so XSS is out of the question.


“NULL means no!?”

When accessing the callback endpoint directly the window.opener property is null, so it appears that the instance is not vulnerable. However there is a technique to control the opener window. The first idea that came to mind was to create a bug chain, by finding another page in google plus that will force opening a window with an arbitrary URL and combine that with the callback endpoint. Although finding such a page is a little too rare and will weaken the attack.


Window Objects in memory:

So let’s try different approach, I wanted to entirely control a window and set its document to whatever page in Google Plus and then tell the Google Plus callback endpoint “This is your opener window deal with it”. That’s exactly what you can acheive in “Same Origin Method Execution” all you need is a page that opens another window and a set of redirection and you can designated any window as the opener and start hijacking methods! The key element that makes this a successful approach is the nature of user agents. When a window document is being redirected its window object remains at the original allocated memory space, therefore any other window/s that holds a reference to it as “opener” can still use the reference to access the opener window even after the document changed/redirected.

If window A opens window B, the user agent will create a reference to window A as window.opener property of window B, when window A’s document would change (redirect) the reference won’t be cleared/deleted and window B can still use the opener property to reference it.

So the answer is pretty clear, all there’s left is to make a malicious html that will open another window via “window.open(‘/step1.html’)” , then redirect the first window to a designated document on Google Plus, and redirected the pop-up window to the callback endpoint. This way you can set any page as the opener of the callback endpoint.



Stealing Private Photo Albums with SOME:

I covered how to control an opener and abuse a vulnerable callback endpoint to execute any DOM/Javascript function at the context of the opener window. All there’s left is to choose a page containing an interesting web functionality and use only alphanumeric and a dot to assemble a payload that will hijack this web functionality (Similar to the impact of CSRF but we don’t mind CSRFTokens or other protective mechanisms).

The target document I used:

Google Plus can automatically backup private cell photos to Google servers in case G+ is installed as a mobile application on your phone. Fortunately Google created a service called “Google Picker” which allows users to share their photos, videos and documents stored in Google servers with third-party websites.

Now that I've designated a target document (Google Picker) I setup the attack page as follows:
  1. Set a page that opens two pop-up windows to control their opener.
  2. Redirect the page to Google Plus instance of Picker.
  3. Wait for the DOM to complete loading.
  4. Redirect the first pop-up to the vulnerable callback endpoint with a callback parameter set to: document.activeElement.parentElement.parentElement.parentElement.previousSibling.lastChild.click
  5. Redirect the second pop-up to the vulnerable callback endpoint with a callback parameter set to: pickerApp.V.Fa.PA which made the service send all the selected photos to my own domain.
  6. Send the malicious setup to a chosen victim (In my case Google Bug bounty responsible disclosure :)
The exploit resulted in hijacking the following JavaScript functions:
  1. window.opener.document.activeElement.parentElement.parentElement.parentElement.previousSibling.lastChild.click({JSONDATA});
  2. window.opener.pickerApp.V.Fa.PA({JSONDATA});


This flow could make any user send every single photo from his/her private album to my server.

BlackHat EU Video:




Additional use cases: 
I exploited the same instance to delete Google Plus timeline posts. 



Note: The issue is now fixed as it has been reported to Google bug bounty program.



Hope you enjoyed reading!





Saturday, May 10, 2014

Deep Analysis of CVE-2014-0502 – A Double Free Story


The Adobe Flash Player zero-day that was part of a targeted attack that infected several nonprofit organizations’ websites.

The vulnerability is a double-free vulnerability caused by a bug in how shared objects are handled by Adobe Flash Player.

The full story:
http://blog.spiderlabs.com/2014/03/deep-analysis-of-cve-2014-0502-a-double-free-story.html

A double free vulnerability occurs during the termination of adobe flash worker. when a worker is being terminated, all shared objects (also called as "flash cookies") are flushed an then freed from memory. while failing to flush an off limit "shared object" to disk (for being above 100KB data) a garbage collection occurs. the garbage collection decides to free the "shared object" from memory whilst the first free operation is still in process.

a screenshot presenting a "record" shared object while exploiting the vulnerable code and controlling EIP (0xcccccccc+8):

the screenshot blow presents the internal SharedObject destructor procedure, you can notice that there's a flag that checks whether flushing data to disk is required.
the "SharedObject" has data pending for flushing but fails to do so since the data exceeds the 100KB limit. then during the flushing attempt, garbage collection fires and frees the object without clearing this "pending flush" flag.




This specific flow will result in the “Pending Flush” flag being up when the object was already freed, and therefore Adobe Flash Player will try to execute a function from a dereferenced pointer otherwise known as remote code execution. 


I originally posted this post on spiderlabs blog. for more details read the full story.



Wednesday, March 19, 2014

The Kernel is calling a zero(day) pointer – CVE-2013-5065 – Ring Ring


Here's my analysis of a PDF file which contained two different vulnerabilities, a remote-code-execution vulnerability in Adobe Reader and a new escalation-of-privileges zero-day vulnerability in Windows Kernel.

The full story:
http://blog.spiderlabs.com/2013/12/the-kernel-is-calling-a-zeroday-pointer-cve-2013-5065-ring-ring.html

A flaw in NDProxy driver while processing Telephony Application Programming Interface (TAPI) operations, was used to cause the Kernel to dispatch out-of-boundaries function. Therefore, one could exploit this vulnerability and gain SYSTEM privileges and bypass different sandbox protections.

The vulnerability allows index control of the following static function table, which get executed in the kernel context:


Dispatching the invalid PxTapi function results access to address 0x0 in memory and crash:



Sunday, November 10, 2013

The Technical Aspects of Exploiting IE Zero-Day CVE-2013-3897


Just last month, during our work at spiderlabs research, the team and myself had the chance to analyze CVE-2013-3897 Use-after-free vulnerability.
This vulnerability was basically a result of an object type CDisplayPointer being freed and used again when a richtext tries to scroll the pointer into the current view.
A flow that includes a selection, that occurs under "onpropertychange" event, and a DOM that contains a textarea structure (detailed below) results a possible remote code execution.

Breaking it to down
1. Create a TEXTAREA and apply a different element as a child using applyElement. This will place theaddress element as the child of the textarea element.
Steps1
2. Trigger a select event on the TEXTAREA element to create an instance of DisplayPointer.
Steps2
3. Inside onselect event change the value property of the TEXTAREA element, which in turn will fire the eventonpropertychange. For example, usage of appendChild or swapNode will cause this behavior. 
Steps3
Notice that id_2 (“address” element) is a child of the TEXTAREA element. By swapping that element we remove it from layout of “textarea” and insert a different element, therefore the value property changes.
4. The event onpropertychange is triggered
Steps4
5. In the next stage we basically need to change the position of the display pointer within the TEXTAREA layout. In the original exploit document.execCommand(“UnSelect”) was used. However, selecting a different element, executing the SelectAll command or any operation that causes a DisplayPointer position change will also work. 
1
The attacker used "UnSelect" command
6.  The JavaScript selection causes a call to CDisplayPointer::ScrollIntoView, which tries to set a new position for the DisplayPointer. At this stage, the reference to CMarkupPointer is already released by the CDisplayPointer::Release function (as a result of the “UnSelect” command) and therefore points to an attacker-controlled heap area.
The flow eventually gets into QIClassID, which tries to execute “CMarkupPointer::QueryInterface” (located at offset 0x0 in CMarkupPointer’s virtual table).
QIClassID (use): 
Blog 2
QIClassID disassemble crash point

At the crash we end up with the following stack trace:
Stack

CMarkupPointer freed and then used by QIClassID:
Most of this post was originally generated here:
(http://blog.spiderlabs.com/2013/10/ie-zero-day-cve-2013-3897-technical-aspects.html)


Monday, February 11, 2013

X-Framing them all! - Cross-Framing is "impossibe" - Apple’s iOS 5

Cross Framing Google, Facebook and whoever you wish. 


Jailbreak Your Device? or buy android?

This post is mostly for people who hold iPhone/iPad/iPod or any other iDevice.

As for today at least for most people, jailbreaking is a serious concern and as for my experience it can even determine whether or not to purchase IOS(Apple) or Android(Google) device.
 there are quite many differences that comes to mind, one bold example is that the exact same application (whatsapp for example) would be free if you hold an smart-device who runs android, and would cost money if you use iDevice unless it is jailbreaked.
Some people even say the reason there was no jailbreak for iPhone5 might affected the apple sales, New York Times post on “Apple Earnings”
“Once-euphoric investors, who pushed Apple’s stock to a record high of $702.10 last September, have become nervous, and in early trading on Thursday, the stock traded at $455.89, down more than 34 percent from its peak.” (http://www.nytimes.com/2013/01/24/technology/apple-earnings.html)


Are you, behind? IOS 5.1.1? 6.0.1?

Since the only reason to convince us to upgrade to IOS 6 are update you already have with your installed Cydia tweaks, people just “stay behind” and use IOS 5.1.1 or lower to still have a nice jailbreaked iPhone. 

So you use IOS 5 or lower? Are you Safe?
As for today we already know there are many web application vulnerabilities around, client side attacks and mostly cross site scripting have become one of the most common attacks in the past recent years.

Google, Facebook, Microsoft, Paypal, Mozilla, Apple and many other great companies have tried to fight against the security risks to give us - their product customers, the answer to keep our data safe.
But do they?
Many of the web application developers had to deal with many different client side attacks and design their security architecture to protect their users and avoid different hacking attempts targeting their customers, since some attacks such as frame-busting click-jacking, multiple stage attack, self-XSS exploitation etc, are not easy to deal with and require browser cooperation.
There are quite a few client side security solutions such as Anti-XSS filters; No-Script, XSS-Auditor, SoP different headers, Caching, and X-Frame-Options header which define how the interpreter handles a response from a webpage loaded insde frames.


Safari on your iPhone(or iDevice) – you CHOOSE to stay vulnerable:

So Google’s/Facebook’s/Paypal’s/Any_Other web developers(including myself) can rely on browser implemented security features and protect their webpages from Client side attacks mostly from Click-Jacking and staging attacks with X-Frame-Options, setting it so that the webpage content will only be displayed after a request coming from the Same-Origin or completely disable Framing and thinking everything is now secured, what we unfortunately forget it is basing the protection on browser's client security. 

What if the browser fail?
I reported to apple 2 months ago at 06/12/12, that I discovered that even though the web server (in this example “www.google.com”) set HTTP response header, X-Frame-Options Header to Same Origin the response will still be displayed using my iDevice.

As you can see in the following PoC HTTP response while sending HTTP request to Google.com:

HTTP/1.1 200 OK
Date: Thu, 06 Dec 2012 15:54:50 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=UTF-8
Server: gws
X-XSS-Protection: 1; mode=block

X-Frame-Options: SAMEORIGIN
Content-Length: 99283 


Setting this header suppose to provide browser client side security that will allow the iframe element to be displayed only if the parent document is at the same origin/domain of the iframe src attribute.
It appears the Safari Browser does not enforce X-Frame-Options and therefore displays our frame element as it did not even have any protection.


Normal Behavior IE9 enforcing X-Frame-Options: 




Safari on IOS 5:




PoC Test Page:
<html>
<head><title>X-Frame-Options Bypass</title></head>
<h1>Apple PoC X-Frame-Options </h1>
<iframe id="X" src="http://www.google.com"></iframe>
<script>
framex = document.getElementById("X");
framex.onload = function () { }

</script>
</html>

Btw, This also means ClickJacking Anywhere Over IOS 5 and lower victims.

So What Should I Do?

Well, Apple did good and fixed this issue in the New IOS (6.0.1)
Unless you want to stay vulnerable knowning you can be a victim to advanced client side attacks over your gmail/facebook make sure you use IOS 6.


Sunday, August 26, 2012

White-hat cyberbug bounty nets cash - NYPOST

White-hat cyberbug bounty nets cash

By SARA ASHLEY O’BRIEN

Come on, White Hats: Hack into our system, find a bug — and make it an interesting one! This seems to be the resounding message that major online businesses are spreading.
With US spending on cybercrime security estimated to exceed $23 billion this year, according to the research company Gartner, online businesses are onto the fact that cybercrime is a very real threat.`


`Businesses like Facebook, Google, Mozilla, Adobe, Microsoft and, as of June, PayPal, have developed “Bug Bounty” programs to recruit savvy security researchers like Hayak to help fight the good fight against cybercrime.


These Are snippets from a great story I got to be part of advertised in the NYPOST

Read more:
http://www.nypost.com/p/news/business/white_hat_cyberbug_bounty_nets_cash


Great Write 
I appreciate the story very much, Thank you NYPOST


Wednesday, June 27, 2012

Google Mail Hacking - Gmail Stored XSS - 2012!

Gmail Accounts Hacking Risk 2012! 

Millions of users use Gmail as their information center to perform actions such as Business, Chat, Place Orders, Payment confirmation, main password recovery mail for different web services and so on...
many people - including myself use Gmail to store and save important and personal data, none of us want our data to be at risk of steal, manipulation, and obviously not considering the Gmail account being completely hacked!
I found a possibility to do all that!


Fortunate enough for us, Google is taking a lot of efforts securing their services. mostly by doing a great job, which integrates supporting a vulnerability reward program.


I made a quick research and reported this vulnerability along with all the related details. 
I must say Google's response was very quick and so as their fix. (it is Fixed)


as it appears here :Vulnerability Reward Program even after the bounty raise:
Google's Reward for this bug: $1337 (mail.google.com)
PoC Picture:


Technical Details: 

I am quite busy at work and personal life at these days so I placed a side the reward programs of Google, Facebook And others.


I was just checking my mail the other day and I noticed something different.
Google made this nice change in Gmail , apparently around December 2011 - Google Adds circles to Gmail 
"Users can now Filter their Mails based on their Circles"


Trusting your Google+ Friends?

When I clicked this Gmail Circles feature, I saw my Google+ connections: profile pictures, nicknames and some other circles related data 
Do they Control this data?! - Yes!
I had to spend some time back in the business, Gmail Stored XSS is a serious finding!

So I imminently researched that feature's JavaScript code.
It appeared that data that comes from Google+ was not sanitized by Gmail!

    zk.prototype.Ca = function $pn(a, c, d) {
        this.xa = 0;
        if (!this.ea) {
            //Shorten/removed
            var e = this.Bb.zb().body, g = this.ea.va();
            //Shorten/removed
            e.wa = h
        }
        a: {
            if (d)
                switch (d.toLowerCase().split(",")[1]) {
                    case "l":
                        break a;
                    case "r":
                        /removed;
                        break a
                }
            e = 2
        }
        this.wa.setPosition(cka(d), e, i, -1);
        jc(this.ea.va(), "T-ays-avH");
        ud(this.ea.va(), 0, 0);
        this.ea.Mc().innerHTML = c; //c = Data from Google+;
        this.wa.To(a);
        this.wa.Me(k, 0)
    }; 


This Gmail Code was creating a Tool-tip that Included profile circles information that comes from your Google Plus friend's account, if they used a payload, your mail account would have been at a serious risk.


Exploiting the Vulnerability - malicious Google+ Account.


As First it is important to note that Anyone that already got accepted as your friend in Google+ could trigger this attack on your Gmail account!

So all that is left is crafting a very nice Google+ account with some attractive profile, then after this evil account gets many friends/victims - Attack em all!

Google+ was and still is blocking the possibility of using a payload in the required field that was used to trigger this attack, but I found a way around it, sorry but I cannot reveal how I did that. (I am sure some of you pros might know how).

After I used my technique and crafted the Google+ evil profile it was possible to attack Gmail of all of that profile's friends! 


PoC Picture: 



As always I appreciate the opportunity to preserve my skills and gain some more experience
Thank you Google security team.


"Ben Hayak" - Google Security Hall of Fame Page
http://www.google.com/about/company/halloffame.html



Friday, June 15, 2012

Layer3 DOM XSS in Latest jquery - Etsy

Turning Useless Self DOM XSS into a treat!

During my research and study over DOM XSS and developing my own detection technique, I found this interesting case which a DOM XSS undetected by any DOM XSS scanner I came across triggered, so I decided to share and provide a quick overview of how I took this self layer 3 DOM XSS into a Working and exploitable DOM XSS.
it all started with this small code:

1
2
3
4
<script type="text/javascript">
Etsy.loader.require('jquery.ba-hashchange');
Etsy.loader.require('help');
</script>

This is Going to be a long one but this covers:

  • DOM XSS.
  • Logic Flow Exploitation .
  • JQuery Vulnerability (Latest release - Unpatched yet).


Final Conclusions:
1. 1st conclusion(easy) the main javascript layer loads a second dynamic block (covered)

2. the payload goes through the dynamic code block and inside gets through a filter to avoid DOM XSS (appears as Self-Only).
3. the layer 2 code block loads another layer(3) this time it is jquery, and then exectue a function that is vulnerable to DOM XSS(latest version 1.72 and older versions as well).

Self DOM XSS?

using the help section search feature I could trigger a very simple XSS by typing the payload in the search box and hit search X_X,This is pretty lame. 
(once I used a payload directly in the url it got filtered without trigger)
We need the victim to be careless enough to actually type the payload and click the search button. I consider this situation as almost worthless and low risk Self XSS,
so I thought this might be useless and not exploitable.

Strange Behavior (not so fast...):

But, that is when I noticed a strange behavior! Look at the picture below:
 (using a payload of <img src=1 onerror=javascript......>)



Something strange?

If you do not see it you should gather yourself and look more carefully next time you think you covered the security holes and were about to report: not exploitable or low risk vulnerability.



What is so strange?


what you can see in the picture is that the XSS triggered (<img src=1> TAG) and for some reason the payload "disappeared" from the URL Query right?

Oh wait, was it??? No!
It was only filtered! the query is now changed to "http://site.com/help/2643#/afsddddddd/1" where did that "/1" came from? what is going on?
let us run more tests:
Look what happens when I used this URL:
"http://site.com/help/2643#/String     2ndString/1"

The filter turned it into the following:
http://site.com/help/2643#/String/2ndString/1

Now that is definitely worth a deeper look at the code loaded as layer 2:


Filter Details (YES It is vulnerable):

The Filter was checking for location.hash, and replaced any space with a "forward slash" to separate the query string as well as replacing any potential XSS HTML Tag with NULL using a regex.

seems right, but, There was a HUGE Security Hole.

Final Conclusions again:
1. 1st conclusion(easy) the main javascript layer loads a second dynamic block (covered).

2. the payload goes through the dynamic code block and inside gets through a filter to avoid DOM XSS (appears as Self-Only) (covered).
3. the layer 2 code block loads another layer(3) this time it is jquery, and then execute a function that is vulnerable to DOM XSS(latest version 1.72 and older versions as well).

HUGE Security Hole in legitimate XSS Filter:


This is where the magic happened! there is a javascript code block condition, this condition determines if the user is actually using the search feature and should be checked for DOM XSS using the layer 2 code block javascript code or not.
after researching all the relevant code in the javascript filter block, it appeared that exploitation is pretty simple!
legitimate behavior:
http://site.com/help/2643#/PAYLOAD/1

So once the search string starts with Forward Slash "/" the condition match, the system consider this a legitimate safe search, and the filter will replace any payload with NULL then pass filtered payload to a vulnerable jquery function.

Remember! This is a DOM event that executes jquery!

So what had to be done is:
1. Insert a Forward slash into the global URI (Before the hash sign).


2. Then insert the payload into the client-side only URI (Right after the hash sign without a slash)

Logic flow Vulnerability:
This way I managed to Trick the system to pass the Forward Slash Condition, and cause the filter to fail and step over the regex to the next stage of passing my payload directly into the vulnerable jquery function!

Final Payload:
http://site.com/help/2643/#<img src=1 onerror=javascript:alert('EXPLOITABLE!')>




but why is this vulnerable?


Vulnerable DOM XSS CODE - 

JQUERY(line 10):



 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
(function(){
        o=$("#attachment-shim");
        k=$("#file-form");
        var a="iframe"+(new Date).getTime();
        g=$('<iframe id="'+a+'" name="'+a+'" />').hide();//<iframe id="iframe1334892619493" name="iframe1334892619493" />

        k.attr("target",a).after(g);
        o.bind("change",q);
        if(a=window.location.hash.substring(1)) // sets a to "<img src=1 onerror=javascript:alert(1)>"
if($('a[name|="'+a+'"]')[0]) { // GAME OVER we got our Executer "a[name|=\"<img src=1 onerror=javascript:alert(1)>\"]" (later will be parsed with jquery " for(s.innerHTML=m[1]+l+m[2];o--;) "
            a=$('a[name|="'+a+'"]').parents("div.topic");
            a.find("ol span").removeClass("bottom");
            a.find(".view-less").show();
            a.find(".view-all").hide()
        }
        else m();
        f=true;
        topic_box=
        $("#topic");
        topic_box_val=topic_box.val();
        if(topic_box_val!=0||$("#message").val()!=""){
            d=true;
            h=topic_box_val;
            n()
        }
        
    })()
});

inside this "IF" Condition(line 10) there is a call to a vulnerable jquery function:

if($('a[name|="'+a+'"]')[0])


Which executes a function in jquery code that include the following line:
for(s.innerHTML=m[1]+l+m[2];o--;)

after bypassing all of these conditions our payload will be stored in "l" variable like this

l = "<img src=1 onerror=javascript:alert('DOM XSS')>"
and as a result of the for loop, will be injected into the innerHTML of the page triggering the XSS.

After I reported I noticed that, I never knew but it seems like there is an opened ticket in jquery bugs,
Reference: http://bugs.jquery.com/ticket/9521

Final Conclusions again:
1. 1st conclusion(easy) the main javascript layer loads a second dynamic block (covered).
2. the payload goes through the dynamic code block and inside gets through a filter to avoid DOM XSS (appears as Self-Only) (covered).
3. the layer 2 code block loads another layer(3) this time it is jquery, and then execute a function that is vulnerable to DOM XSS(latest version 1.72 and older versions as well) (covered).


It is always fun when web applications are open for a vulnerability report allowing me to research over these very interesting security flows that requires combining all the pieces together.


Thank you etsy!
Etsy Thank you list: http://www.etsy.com/help/article/2463