大风，你把那个dns投毒啥的，有图的url给我吧 之前这里看见过，现在又找不到了
On 10月8日, 下午8时56分, Atomic <[EMAIL PROTECTED]> wrote: > 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] -~----------~----~----~----~------~----~------~--~---
