Twitter's Clickjacking Saga Continues
Posted by: Giorgio in Clickjacking, Mozilla, NoScriptThe latest epiphany of the vicious Clickjacking poltergeist that Twitter apparently can't exorcise has a tiny face :)
Archive for February, 2009
27
02
2009
Twitter's Clickjacking Saga ContinuesPosted by: Giorgio in Clickjacking, Mozilla, NoScriptThe latest epiphany of the vicious Clickjacking poltergeist that Twitter apparently can't exorcise has a tiny face :)
25
02
2009
Upgrade Flash and Turn Off Acrobat, NOW!Posted by: Giorgio in Flash, Mozilla, Security, NoScriptUsers of Adobe products (i.e. almost all the web surfers) are in serious danger (well, not exactly breaking news). Adobe just released a Flash Update addressing the player vulnerability, which has been abused in real world attacks for more than 6 weeks. Notice that the FlashBlock work-around suggested by the iDefense bulletin is bogus: as we already clarified a few times, FlashBlock can't be relied upon as a security defense. The only reliable means to protect yourself against Flash-based 0 day attacks like these are either disabling the Flash Player plugin globally, or using NoScript's content blocking features to selectively enable only the Flash applets you trust. Regarding the Acrobat flaw, Adobe announced that a patch won't be available until March the 11th. In the meanwhile many sources, including Adobe itself, recommend to disable JavaScript execution in Acrobat's options, but again the suggested work-around is not effective: disabling Acrobat's JavaScript does not prevent the vulnerability from being exploited. As always, you should be very careful in opening PDF files you receive by email, and use NoScript to prevent automatic exploitation on the web: NoScript's default deny policy applies to all the plugin content, indeed, including PDF. As we already noticed, 2008 had not been a great year for Internet Security, and especially for SSL and HTTPS. Today, web sites relying upon encryption and certified identity got another blow: at the Black Hat DC 2009 conference, independent researcher Moxie Marlinspike demonstrated how to defeat HTTPS, successfully impersonating a "secured" site over a proxied, public or otherwise hostile network. The proposed attack, performed with a tool called "sslstripâ€, is very interesting and clever, involving forced redirections, "secure UI" simulation and a smart homograph trick which makes the final attacker-controlled page look identical and as secure as the original, so I strongly recommend to take a look at these slides. The danger is far from being theoretical:
Browser vendors are already trying to figure out ways to mitigate this scary stuff, especially the homograph stunt which shows you a "secure" page from an address (as displayed on the location bar) like https://www.paypal.com╱login╱abcdef.g54321.cn: this definitely appears to be a legitimate Paypal login page, but is really an evil phishing bait from the g54321.cn
Chinese domain. The "╱" character is not a true slash, but a different unicode character looking like (i.e. homograph of) a slash and valid as an IDN subdomain part. However, for the full attack to succeed, the target site must allow its entry point (e.g. the home page or the login box) to be initially served over HTTP (not encrypted), even if it correctly exchanges login credentials and other sensitive data over HTTPS (encrypted). Unfortunately, this is too much a common scenario (as the 254 password collected in 24 hours testify): various Google services, social networks, financial institutions like Bank Of America, Wachovia and even my own bank (Fineco), all do suffer of this flaw. Good news: once again "unexpectedly", a NoScript feature can protect you, if correctly configured:
UpdateAs commenter Fantomas hinted, you can deploy a band-aid countermeasure against the homograph exploit by forcing Firefox to always show punycode for IDN address. If you do so, the https://www.paypal.com╱login╱abcdef.g54321.cn address will be displayed in your location bar as https://www.paypal.xn--comloginabcdef-d29if.g54321.cn/, which is obviously much less effective as a disguise. Of course this was just the "final touch", albeit impressive, of this multi-faceted attack: in facts, the 254 passwords have been harvested without this trick! So be sure you configure force HTTPS as well, and always type your sensitive addresses or, much better, use bookmarks... As usual for very ambitious projects, more than one week later than the planned release date.
07
02
2009
Browser Plugins, Add-Ons and Security AdvisersPosted by: Giorgio in Flash, Mozilla, NoScriptAs you probably know, plugins are external software components which the web browser delegates to render custom content inside web pages, and/or to play audio clips and potentially much more: they actually can do anything, since they're executable code running inside the browser process, with the same privileges as their host. This can cause major security concerns, no doubt about that. They've accumulated lots of security issues of their own over the time, and the scriptable ones (like Flash or Java) are often used in combination with JavaScript to prepare memory for attacks working around protection features deployed by modern OSes. That's why one of the major features of NoScript is blocking plugin content from untrusted web sites, and optionally from trusted too, in an easy "click to activate" fashion: this way you can considerably reduce your attack surface, while retaining the power of accessing plugin content on sites where you really need to. Add-ons, in mozillaspeak, are a broader category, including plugins of course, but also themes (packages which can change your browser appearance, also called "skins" in other communities) and extensions. NoScript itself is an add-on, or more precisely an extension. Extensions are tiny applications developed with the same technologies which Firefox is made of (i.e. XUL, JavaScript, XPCOM and, possibly but rarely, C++) which upon installation get tightly integrated in the browser, extending (and hopefully enhancing) its functionality. They can access and modify practically any aspect of the browser, and are granted the same privileges as the browser. With great power comes great responsibility, and add-ons are obviously not immune of bugs which can compromise browser security. There are some differences, though, between extensions and plugins in regard of security:
Wladimir is also engaged in a laudable effort for educating extension developers to safer coding practices: whoever maintains or wants to develop a Firefox extension should subscribe his feed. Coming to "Security Advisers", Roger A. Grimes (a CPA, a CISSP, a CEH, a CHFI, a TICSA, and an MCSE: Security, which in plain English means more or less "security consultant with a strong Microsoft background") recently wrote a serie of articles comparing security features of all the major browsers. The one about Firefox contained, among others, a quite disturbing (for me at least) paragraph (emphasis is mine):
So I decided to send Roger an email, sparking a pretty intense exchange (in the meanwhile, I was implementing PoC X-Frame-Options compatibility for Firefox with my left hand). Yesterday I noticed he published a synthesis of our discussion. Even though he cut some logic passages, making our reasoning a bit hard to follow, I have been positively impressed by his openness and I'd like to rectify just two little things:
That said, I appreciate Roger's transparency and I hope we'll have chances for new constructive discussions. * Note: JJ Barton correctly made me notice that sites different than AMO can adopt the same hosting security policies (automatic update over a SSL channel, which by the way is required by the Mozilla browser toolkit itself, and possibly blacklisting of unsafe versions), e.g. GetFirebug.com for the Firebug extension. However AMO is the place where you're automatically directed by Firefox itself when you look for an add-on, so stressing its security features was very important.
|
Bad Behavior has blocked 729 access attempts in the last 7 days.