Breaking SSL/TLS with SPDY

We've been hearing a lot about CRIME recently. And also a lot about security researchers predicting that CRIME may be some form of a chosen plain text attack exploiting TLS data compression. With fingers crossed, we are waiting to see whether Juliano Rizzo and Thai Duong were trying to do something similar with CRIME. Lets hope it is and we'll have one less thing to worry about.

Some homework first: 

Before diving in to SPDY and the attack, please feel to read the existing research done on this, by Thomas Pornin and the solid Proof of Concept by Kotowicz to get some idea on data leakage using TLS compression.

   Now what makes the above attack less interesting to me is because browsers have started disabling TLS compression already, take Chrome for instance.

SPDY - Probable successor of HTTP/1.1:

  SPDY is Google's proposal to make HTTP much faster and acts like a wrapper to the already existing HTTP and works only over SSL connections. You should read this article on SPDY vs HTTP if you're new to SPDY. Chances are that SPDY is behind the curtains, if you use any of Google's services on a Chrome browser.

SPDY's Design:

"The goal of SPDY is to reduce web page load time. This is achieved by prioritizing and multiplexing the transfer of web page subresources so that only one connection per client is required. TLS encryption is nearly ubiquitous in SPDY implementations, and transmissions are gzip-or DEFLATE-compressed by design (in contrast to HTTP, where the headers are not compressed)." --Wikipedia

The real problem here is SPDY's compression by design to make it faster (they get ~88% efficiency in doing so). This whitepaper contains details on how SPDY compresses headers using zlib and a new idea on how to make it more efficient (Well, we are not bothered about that now)

The Attack:

Now the idea is if we can control the headers of the request being sent and use chosen plain text attacks just like the ones discussed above, we can leak encrypted data - especially the user's cookies which are a part of the request headers. Now it doesn't come easy, we need to take care of a few issues like setting custom header values as part of the cross domain request,  and adding the chosen plain text as part of the header itself. 

The sometimes harmful CORS:

 So as we know the XMLHttpRequest object in latest browsers use XHR Level 2 (Cross Origin Resource sharing)and they have some subtle bypasses which enables us to send specific Cross domain requests with certain headers like Allow, Content-Type to be set. Now that is good news for us. We could do something like,

Content-Type: text/plain;--Chosen Plain Text to be Bruteforced--

I like playing scenario:

 Lets take this attack to Google services. Google as I said already serves almost 90% of its https pages using SPDY if you are using a supported browser like Chrome/ Firefox. Now, lets assume that am interested in cookies which has a secure/httpOnly flag set. There are already a few of them, but lets try leaking the cookie named SSID which must have something to do with the session of the currently logged in user.

SSID=BhjKLJFRhgpeC2Ir

Brute-forcing a cookie like this requires a charset of 26 + 26 + 10 = 62 Characters. And imagine the possibilities like HTML5's WebWorkers which can be used to spawn new threads and make brute-forcing easier.

I've tested this locally and yea SSL can leak data using a PoC like what Koto made. Now that, we have to wait and see how this technique can be used on a real SPDY enabled web application with a tool similar to BEAST.

The real deal:

I would come up with a PoC soon which works specific to the zlib compression context used in SPDY. And also this sends a message across that, any encrypted payload which incorporates compression opens up a new attack surface to leak encrypted information. 

Adobe Flash Webcam clickjacking - The security fix that wasn't and the hole that was.

Update : Adobe added me to their Security Acknowledgments page, following the fix.

Adobe and clickjacking, sounds familiar? Recently I found a vulnerability in Adobe Flash that allows any website to silently spy on its visitor's webcam and microphone feeds with absolutely zero permission. And wait, heres the most interesting part, this issue has been there for the past 4 years and am pretty sure that this must have been exploited in the wild until recently. The flaw is ironically in one of Adobe's security fix, following a clickjacking vulnerability in their Flash Settings Manager page.

For security researchers:
TL;DR -  Its all about frame buster busting with the 204 - No Content trick. 

Others read more.

    "Clickjacking is a malicious technique of tricking Web users into revealing confidential information or taking control of their computer while clicking on seemingly innocuous web pages." -- Wikipedia 

    "The Adobe Flash Player Settings panels let you make decisions about privacy, data storage on your computer, security, notifications of updates, and use of the camera and microphone installed on your computer." -- Adobe website

A little bit of history:
  In 2008 a security researcher Guy Aharonovsky discovered a way to maliciously spy web cameras using Clickjacking on the Adobe Flash Settings panel. This video demonstrates the attack using a small game, which has an Iframed Flash Settings page, well hidden using CSS properties. And Adobe followed up with their fix, pretty fast. As the researcher quotes,

"Adobe has fixed this issue by framebusting the Settings Manager pages. Now, 99.9% of the users are protected from this specific exploit. Congrats on the fast response." 

A pretty sad fix I should say, which I'll explain soon. Then in 2011, another security researcher Feross, found a new way to clickjack the Flash Settings panel. This attack works by Iframing the settings SWF file instead of the whole Settings page, as he quotes in his blog,

"Instead of iframing the whole settings page (which contains the framebusting code), I just iframe the settings SWF file. This let me bypass the framebusting JavaScript code, since we don’t load the whole page — just the remote .SWF file. I was really surprised to find out that this actually works!"

Adobe fixed the clickjacking issue on the SWF file some 3 months back.

Bypassing the Frame Busting code or why that fix from Adobe in 2008 wasn't a secure fix:
   There are many ways in which a Frame Buster can be Busted. Yeah!  There are Frame-Buster busters too. The sad truth is that many websites are still under the impression that this small junk of code is a frame buster and that it can keep their clickjacking miseries at bay,
Programmers usually bust Iframes by using JavaScript's power with the above code. Security researchers and attackers then go beyond that and show the true power of JavaScript by using something like the one below,

    On modern browsers a 204 -No Content HTTP response from the server will do nothing, meaning it will leave the current page intact. Thus it will override the previous frame busting attempt, rendering it futile.
This technique has been there for a while, but its really bad most of them are not aware of it.

How to fix clickjacking issues once and for all:
 The answer lies in a Custom HTTP Response Header called X-Frame-Options . This response can be used to indicate whether or not the browser should allow the response to be allowed in a Frame or not. Most of the top websites are fast adopting this header and I feel this should be there by default for all the Apache Server configurations, unless people want to mash up stuff. Apache servers can be made to send X-Frame-Options header for all pages, by using the following line in the site's configuration.
     Header always append X-Frame-Options DENY
And heres the one for nginx,
     add_header X-Frame-Options DENY;

Adobe did respond pretty fast and smart to this one:

Vulnerability reported: 28-11-2011, Proof submitted with a Private POC Code to exploit Flash Settings.
First Response from Adobe: 29-11-2011, Suggested X-Frame-Options for the fix.
Fix is ready and is being tested: 15-12-2011.
Fix deployed: 20-12-2011.

ECMAScript 5 - What stops websites from thwarting malicious browser extensions?

     Browser extensions have always questioned online security, as they are developed by third-party developers. An extension can be directly malicious or a benign extension can be seized up by an attacker owing to some buggy code. Both Chrome and Firefox have a huge collection of extensions/add-ons and millions of people use it every day. Among the Browser Extension systems, Chrome's Architecture is considered pretty secure with its Least privilege and Privilege separation mechanisms. These two mechanisms helps thwart attacks originating due to insecure coding. In this post, Ill be writing about how ECMAScript 5 Specifications can be used in the future to prevent malicious extensions from targeting a particular website.

First things first:

  Keeping in mind the HTML design principles and its Priority of constituencies,

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone.

So the priority goes like,  
Users(The one who uses the browsers) > Authors(Website creators) > Implementors(Browser vendors)  

A little bit of ECMAScript 5:
ECMAScript 5, the latest edition of the standard, is upon which JavaScript is based. There are some new APIs included in the specification, among which the most interesting  one comes in the way you manipulate an Object. Read this post by John Resig on the various ways of locking down / sealing an Object using the ECMAScript 5 Specifications. And moreover, the latest browsers have already implemented most of these specs.

Content Scripts in Chrome Extensions:

   Content scripts is the means by which Google Chrome allows an extension to interact with the webpage's Document Object model (DOM), that its acting on. Actually, the DOM  is shared between the page's JavaScript and the different content scripts used by extensions. In order to avoid confusion, the content scripts and the JavaScript of the page are separated from each other using 'Isolated Worlds'. So each script that is accessing the DOM runs on its own isolated worlds each having its own JavaScript environment.

The malevolence of some Extensions:
  There are a bunch of nasty extensions in the wild. Most of them are drive-bys, where the extensions are installed from a third party source, rather from the Google Web Store. Here is a code sample which can steal a twitter login information and send it to the attacker's server, every time the user logs in. The code needs no explanation.


Extensions which steals login details, credit card credentials or which sends each and every key stroke to the attacker are sometimes unavoidable. Its up to the user's knowledge, to trust extensions and install them. Recently a lot of spams which affected Facebook had well crafted extensions behind the scenes, in the name of 'YouTube Premium Plugin'. The issue has already been notified to Google and there is nothing they can do about it, because this is by design.

Getting to the point:
  I've always been amused by the way .mario trying to lock down DOM using the ECMAScript 5 specs such as Object.defineProperties to prevent XSS, even though it wasn't a completely successful one. I've been thinking about this for a while with a different approach to lock down a website's Objects, so that the extensions can only alter the objects allowed by the website author. Unfortunately, as already mentioned a few paragraphs before, the Chrome Extension System doesn't respect this way of locking down objects across different JavaScript enivroments. ie) If an Object is sealed or locked down in one JavaScript Environment such as the Web Page's JavaScript, then the same object is not locked in another environment such as another Content Script which an extension might be using.

And there is a reason why Chrome does this thing of isolating Objects into different environments. Ironically though, its a security reason. Chrome doesn't want websites to use the shared DOM to break out of normal webpage sandbox and access the content scripts or high privileged APIs. But there must be a way in which browsers lock down the Objects globally, allowing website authors to have a real control over their DOM and Objects. The extension architecture must allow for websites to lock down any DOM node and prohibit the deletion of the same and thus adding more value to these ECMAScript 5 specifications and also by remembering the priority of constituencies (Authors > Implementors) .

Stealing Facebook Graph API Access Token : Yet Another UI Redressing Vector

A week after my first Facebook Bounty , i found another place where Facebook did the same mistake of not busting IFrames.And guess what , its another whole domain developers.facebook.com.It includes all the documentation and examples for using the Facebook Graph API and other products like the Legacy REST API , FQL , Chat API . An attacker can do a whole lot of stuff with this once he Iframes this.

I decided to write on one of the attacks that is possible with this bug. As we all know, the documentation includes some real good examples for using the API with some nifty access tokens with the credentials of the currently logged in user. This special token in the documentation comes with some extra special rights like read_stream, user_status, user_birthday, user_relationships and much more rights which even your normal friends can't see. 

Stealing the Access Token :

Now the interesting part is to get the token sitting inside the source code. Its possible to steal this with many attack vectors and i decided to write a PoC using a Double Drag and Drop Technique which works on Firefox and IE . Google chrome can resist this attack , because it disallows X-Domain Drag & drop and also view-source can't be IFRAMED.

Double Drag & Drop:

Heres the PoC which uses view-source to IFRAME the source code of the page containing the access token. Its better to use a double view-source to make everything as a text and disable all links , which are click-able. The trick is to fool the user (any chicken is fine) , by making him play a game with a ball and a trash can. 

I'll now show some screenshots of what a real attack would look like . A video would have been better , but am just lazy sometimes. 

What Really happened ? Heres what happened behind the scenes !

First Drag, everything in the IFRAME gets Selected                          Second Drag , the mighty cross-domain drag

The user clicks go and the source of the page is sent to the attacker 

What can the attacker do ?

Here's a gist of what the attacker can get if I get owned by this attack ! 

Heres the PoC code for that works on Firefox . Download Code 

Response from Facebook Security:

I reported this bug to facebook on August 28th, 2011 and the fix was up the very next day.

Facebook UID disclosure - Start of something new

     Security researchers would be well aware of the way, Facebook serves a custom page once they try to iframe any of their pages. (Personally, i like the way they do it , you don't have to worry about insanely wicked anti-frame busting techniques.) Unfortunately, there are some pages under the domain Facebook.com which dont do any frame busting whatsoever. Neither do they set a X-Frame-Options header.

The Vulnerability
The one i came across was this interesting AJAX Request which responds with a JSON object, which includes the currently logged in user's Profile UID and another Boolean value which denotes whether the user is a Facebook employee or not. So bad, that this interesting JSON response was not protected against any kind of iframing. All an attacker had to do was to do a cross-domain content extraction and he gets the visitor's Facebook profile .

Getting the UID
There are some few ways in leveraging this particular JSON response. One thing that came to my mind was JSON Hijacking . I felt that the modern day browsers stopped them most of the times. (Do let me know if JSON Hijacking works still) .
The one i used was something inspired by the Fake Captcha technique (A neat work by Kotowicz). Though this particular attack is a hard one to exploit ,it does work most of the time.

Download the POC Code here

What if Mark Zuckerberg visited this page ?
 Lets imagine that ,Mark Zuckerberg (Facebook UID=4) visits the attacker.html page, and fills in the captcha details. Here are some Screenshots for you ,

Attack Page








The attacker gets the visitors details.