Interesting. But this kind of GUI trick attack has been performed before in practice, and in my opinion they are somewhat easier to exploit if the user is stupid enough.
Well.. that's almost always the case ;) On 10月8日, 上午2时58分, 大风 <[EMAIL PROTECTED]> wrote: > Today is the day we can finally start talking about clickjacking. This is > just meant to be a quick post that you can use as a reference sheet. It is > not a thorough advisory of every site/vendor/plugin that is vulnerable - > there are far too many to count. Jeremiah and I got the final word today > that it was fine to start talking about this due to the > <http://blog.guya.net/2008/10/07/malicious-camera-spying-using-clickja...> > click jacking PoC against Flash that was released today (watch the video > > for a good demonstration) that essentially spilled the beans regarding > several of the findings that were most concerning. Thankfully, Adobe has > been working on this since we let them know, so despite the careless > disclosure, much of the work to mitigate this on their end is already > complete. > > First of all let me start by saying there are multiple variants of > clickjacking. Some of it requires cross domain access, some doesn’t. Some > overlays entire pages over a page, some uses iframes to get you to click on > one spot. Some requires JavaScript, some doesn’t. Some variants use CSRF to > pre-load data in forms, some don’t. Clickjacking does not cover any one of > these use cases, but rather all of them. That’s why we had to come up with > a new term for it - like the term or not. As CSRF didn’t fit the > requirements for clickjacking, we had to come up with a new term to avoid > confusion. If you like Michael > <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/01... > tml> Zalewski’s term “UI redress attack” better use that one, it’s just > not CSRF and shouldn’t be mistaken for any other attack, since it really is > different. Here is the technical detail: > > Issue #1 STATUS: Unresolved. Clickjacking allows attackers to subvert clicks > and send the victim’s clicks to web-pages that allow themselves to be > framed with or without JavaScript. One-click submission buttons or links are > the most vulnerable. It has been known since at least 2002 > <https://bugzilla.mozilla.org/show_bug.cgi?id=154957#c6> and has seen at > least three different PoC exploits (Google Desktop MITM attack, Google > Gadgets auto-add and click fraud). All major browsers appear to be affected. > > Issue #1a STATUS: Unresolved. JavaScript is not required to initiate the > attack as CSS can place invisible iframes over any known target (EG: the > only link on the red herring page). Turning off JavaScript also neuters one > of the only practical web based defenses against the attack which is the use > of frame busting code. > > Issue #2 STATUS: Unresolved. ActiveX controls are potentially susceptible to > clickjacking if they don’t use traditional modal dialogs, but rather rely > on on-page prompting. This requires no cross domain access, necessarily, > which means iframes/frames are not a prerequisite on an attacker controlled > page. > > Issue #2a STATUS: To be fixed in Flash 10 release. All prior versions of > Flash on Firefox on MacOS are particularly vulnerable to camera and video > monitoring due to security issues allowing the object to be turned opaque or > covered up. This fix relies on all users upgrading, and since Flash users > are notoriously slow at upgrading, this exploit is expected to persist. > Turning off microphone access in the bios and unplugging/removing controls > to the camera are an alternative. Here is the information directly > <http://www.adobe.com/support/security/advisories/apsa08-08.html> from > Adobe. > > Issue #2b STATUS: Resolved. Flash security settings manager is also > particularly vulnerable, allowing the attacker to turn off the security of > Flash completely. This includes camera/microphone access as well as cross > domain access. Resolved using frame busting code, bug #4 below > notwithstanding. > > Issue #2c STATUS: To be fixed in Flash 10 release. All versions of Flash on > IE7.0 and IE8.0 can be overlayed by opaque div tags. Using an onmousedown > event handler the object click registers as long as the divs are removed by > the onmousdown event handler function. Demo here > <http://ha.ckers.org/weird/cjdivtest.html> of stealing access to the > microphone. > > Issue #3 STATUS: To be fixed in the final release candidate. Flash on IE8.0 > Beta is persistent across domains (think “ghost in the browser”). This > would be a much worse vulnerability except for the fact that it beta and > almost no one is using it. > > Issue #4 STATUS: Unresolved. Framebusting code does not appear to work well > on some sites on IE8.0 Beta. Instead it is marked as a popup which is > blocked by the browser - disallowing the frame busting code from executing. > > Issue #5 STATUS: Unresolved. State of clicks on other domains can be > monitored with JavaScript (works best in Internet Explorer but other > browsers are vulnerable too) which is cross domain leakage and can allow for > more complex multi-click attacks. For example a page that has a check box > and a submit button could be subverted upon two successful clickjacks. > Additionally, this can make the attack completely seemless to a user by > surrendering control of the mouse back to the user once the attack has > completed. > > Issue #6 STATUS: Unresolved. “Unlikely” XSS vulnerabilities that require > onmouseover or onmousedown events on other parts of pages on other domains > are suddenly more likely. For example if a webpage has a XSS vulnerability > where the only successful attacks are things like onmouseover or > onmousedown, etc… on unlikely parts of the page, an attacker can promote > those exploits by framing them and placing the mouse cursor directly above > the target XSS area. Therefore, otherwise typically uninteresting or > unlikely XSS exploits can be made more dangerous. > > Issue #7 STATUS: Fixed in current releases post 1.8.1.9. Firefox’s Noscript > plugin’s functionality to forbid iframe’s can be subverted by iframing a > page that contains a cross domain frame or as Ronald found > <http://www.0x000000.com/index.php?i=316> by using object tags. Giorgio > Maone <http://noscript.net/changelog> validated the issues and issued > patches in future releases of the code as well as other potential > clickjacking mitigation. 1.8.1.6, 1.8.1.7, 1.8.1.8, 1.8.1.9, 1.8.2 and > 1.8.2.1 all contain anti-clickjacking code. All prior versions to 1.8.1.9 > were vulnerable to cross domain clickjacking. > > Issue #8 STATUS: Unresolved. Attempts to protect against CSRF using nonces > can often be overcome by clickjacking as long as the URL of the page that > contains the link that includes the nonce is known. Eg: Google Gadgets > exploit discussed in Blackhat “Xploiting Google Gadgets” speech. The only > semi-decent defenses against this are to omit the nonces in JavaScript space > and also include the frame busting code in the same JavaScript. This will > break for users who do not use JavaScript though, so it is not an ideal > solution. > > From an attacker’s perspective the most important thing is that a) they > know where to click and b) they know the URL of the page they want you to > click, in the case of cross domain access. So if either one of these two > requirements aren’t met, the attack falls down. Frame busting code is the > best defense if you run web-servers, if it works (and in our tests it > doesn’t always work). I should note some people have mentioned > security=restricted as a way to break frame busting code, and that is true, > although it also fails to send cookies, which might break any significant > attacks against most sites that check credentials. > > Thanks to Adobe, Microsoft, Firefox, Apple and the various other vendors and > people who have been helpful/supportive and care to fix the issue. Also > thanks to the researchers who found these issues independently after > Jeremiah and I were unable to do our speech, but kept it to themselves > (Arshan Dabirsiaghi, Jerry Hoff, Eduardo Vela, Matthew Matracci, and Liu Die > Yu). I will release a whitepaper to the informer > <http://informer.ihackstuff.com/> via hackers for charity > <http://www.hackersforcharity.org/> sometime today or tomorrow. I’ll also > make that whitepaper available publicly sometime next week and information > forthcoming when I have some time to put it up. Source to generic > clickjacking code available here <http://ha.ckers.org/weird/cj.cgi.gz> . I > will keep this post up to date with additional issues and updates as I am > aware of them. > > [Ph4nt0m] <http://www.ph4nt0m.org/> > > [Ph4nt0m Security Team] > > <http://blog.ph4nt0m.org/> [EMAIL PROTECTED] > > Email: [EMAIL PROTECTED] > > PingMe: > <http://cn.pingme.messenger.yahoo.com/webchat/ajax_webchat.php?yid=han... > hq&sig=9ae1bbb1ae99009d8859e88e899ab2d1c2a17724> > > === V3ry G00d, V3ry Str0ng === > > === Ultim4te H4cking === > > === XPLOITZ ! === > > === #_# === > > #If you brave,there is nothing you cannot achieve.# > > image001.gif > 5K查看下载 --~--~---------~--~----~------------~-------~--~----~ 要向邮件组发送邮件，请发到 [email protected] 要退订此邮件，请发邮件至 [EMAIL PROTECTED] -~----------~----~----~----~------~----~------~--~---
