
CEO of Bit Discovery, Professional Hacker, Black Belt in Brazilian Jiu-Jitsu, Off-Road Race Car Driver, Founder of WhiteHat Security, and Maui resident.
Friday, October 10, 2008
Maui Vacation 2008

Tuesday, October 07, 2008
Clickjacking: Web pages can see and hear you
Web pages know what websites you’ve been to (without JS), where you’re logged-in, what you watch on YouTube, and now they can literally “see” and “hear” you (via Clickjacking + Adobe Flash). Separate from the several technical details on how to accomplish this feat, that’s the big secret Robert “RSnake” Hansen and myself weren’t able to reveal at the OWASP conference at Adobe’s request. So if you’ve noticed a curious post-it note over a few of the WhiteHat employee machines, that’s why. The rest of clickjacking details, which includes iframing buttons from different websites, we’ve already spoken about with people taking note.
Predictably several people did manage to uncovered much of what we had withheld on their own, whom thankfully kept it to themselves after verifying it with us privately. We really appreciated that they did because it gave Adobe more time. Today though much of the remaining undisclosed details we’re publicly revealed and Adobe issued an advisory in response. Let’s be clear though, the responsibility of solving clickjacking does not rest solely at the feet of Adobe as there is a ton of moving parts to consider. Everyone including browser vendors, Adobe (plus other plug-in vendors), website owners (framebusting code) and web users (NoScript) all need their own solutions to assist incase the other don’t do enough or anything at all.
The bad news is with clickjacking any computer with a microphone and/or a web camera attached can be invisibly coaxed in to being a remote surveillance device. That’s a lot of computers and single click is all it takes. Couple that with clickjacking the Flash Player Global Security Settings panel, something few people new even existed, and the attack becomes persistent. Consider what this potentially means for corporate espionage, government spying, celebrity stalking, etc. Email your target a link and there isn’t really anyone you can’t get to and snap a picture of. Not to mention bypassing the standard CSRF token-based defenses. I recorded a quick and dirty clickjacking video demo with my version having motion detection built-in.
Robert and I are currently scheduled to give more or less simultaneous presentations in Asia about clickjacking. For myself, I’ll be delivering a keynote at HiTB 2008 Malaysia (Oct 29) and RSnake will be speaking at OWASP AppSec Asia 2008 (Oct 28). The timing just happened to work out well. The next couple weeks will give us time to put our thoughts in order, explain the issues in a more cohesive fashion, and bring those up to speed who’ve gotten lost in all the press coverage. For those that have been following very closely, you’ll probably not find any meaningful technical nuggets of information that are not already published. Our job now is to make the subject easier to understand and help facilitate solutions to the problem. Unless the browser is secure, not much else is.
Prevention?
Put tape over your camera, disable your microphone, install NoScript, and/or disable your plugins. In the age of YouTube and Flash games, who’s really going to do the latter? For website owners their CSRF token-based defenses can be easily bypassed, unless they add JavaScript framebusting code to their pages, but the best practices are not yet fully vetted. Again, browser behavior is not at all consistent.
What a couple of a weeks this has been. Thank you to Adobe PSIRT for their diligence and hard work.
Predictably several people did manage to uncovered much of what we had withheld on their own, whom thankfully kept it to themselves after verifying it with us privately. We really appreciated that they did because it gave Adobe more time. Today though much of the remaining undisclosed details we’re publicly revealed and Adobe issued an advisory in response. Let’s be clear though, the responsibility of solving clickjacking does not rest solely at the feet of Adobe as there is a ton of moving parts to consider. Everyone including browser vendors, Adobe (plus other plug-in vendors), website owners (framebusting code) and web users (NoScript) all need their own solutions to assist incase the other don’t do enough or anything at all.
The bad news is with clickjacking any computer with a microphone and/or a web camera attached can be invisibly coaxed in to being a remote surveillance device. That’s a lot of computers and single click is all it takes. Couple that with clickjacking the Flash Player Global Security Settings panel, something few people new even existed, and the attack becomes persistent. Consider what this potentially means for corporate espionage, government spying, celebrity stalking, etc. Email your target a link and there isn’t really anyone you can’t get to and snap a picture of. Not to mention bypassing the standard CSRF token-based defenses. I recorded a quick and dirty clickjacking video demo with my version having motion detection built-in.
Robert and I are currently scheduled to give more or less simultaneous presentations in Asia about clickjacking. For myself, I’ll be delivering a keynote at HiTB 2008 Malaysia (Oct 29) and RSnake will be speaking at OWASP AppSec Asia 2008 (Oct 28). The timing just happened to work out well. The next couple weeks will give us time to put our thoughts in order, explain the issues in a more cohesive fashion, and bring those up to speed who’ve gotten lost in all the press coverage. For those that have been following very closely, you’ll probably not find any meaningful technical nuggets of information that are not already published. Our job now is to make the subject easier to understand and help facilitate solutions to the problem. Unless the browser is secure, not much else is.
Prevention?
Put tape over your camera, disable your microphone, install NoScript, and/or disable your plugins. In the age of YouTube and Flash games, who’s really going to do the latter? For website owners their CSRF token-based defenses can be easily bypassed, unless they add JavaScript framebusting code to their pages, but the best practices are not yet fully vetted. Again, browser behavior is not at all consistent.
What a couple of a weeks this has been. Thank you to Adobe PSIRT for their diligence and hard work.
Subscribe to:
Posts (Atom)