Bypassing Javascript based anti-framing protections

10 Jan 2012

Adobe Flash Webcam clickjacking - The security fix that wasn’t

Adobe and clickjacking, sound familiar? Recently I found a vulnerability in Adobe Flash that allows any website to spy on its visitor’s webcam silently and microphone feeds with absolutely zero permission. And wait, here’s the most exciting part, this issue has been there for the past four 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:

TLDR Version - 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, someone named 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 entire 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 — only the remote .SWF file. I was amazed to find out that this works!

Adobe fixed the clickjacking issue on the SWF file some three 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 broken. 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,

    if (top!=self){
        top.location.href=self.location.href;
    }

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,

 var kill = 0;
   window.onbeforeunload = function() { kill++; }
   setInterval(function() {
     if (kill > 0) {
       kill -= 2;
       // A Web Server that serves a 204 - No Content
       window.top.location = "http://test.skepticfx.com/204.php"; 
     }
   }, 1)

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 it’s terrible 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 server configurations unless people want to mash up stuff.

Apache servers can be made to send this 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 here’s the one for Nginx, add_header X-Frame-Options DENY;

Adobe did respond pretty fast on 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.

ReadWrite