Re: [FD] Major Internet Explorer Vulnerability - NOT Patched

Hi David. When I tried to reproduce it using code hosted on one of my domains, I tried three variations of what I assumed at the time the PHP code from the original was: I wasn't able to get it working, so as I said, I used Burp Suite to modify your demo in realtime as it came down to my browser, with the Daily Mail domain being replaced in response headers and bodies with a different target domain, but no other changes made. It worked with another CloudFlare customer's site (tickld.com), but not a non-CloudFlare customer's site (can't share that one without giving away information I'm not supposed to). It seems like that was a coincidence, and that the reason it didn't work on the other site was something other than them not being a CloudFlare customer. Enough other people (in particular, @filedescriptor, who Justin Steven sent a link to (http://ift.tt/1KsbrVG)) have validated the way the exploit works that I agree it appears to be essentially universal. When are you going to give it a cool name and logo to ensure it gets the media coverage it deserves? :) - Ben On 2015-02-04 21:06, David Leo wrote: > "is this entirely an IE flaw" > Yes. > > "is it tied to the use of Cloudflare" > No. > > "I tried to reproduce... was unsuccessful" > Likely, this detail is missing: > > Please tell us whether you reproduce(with the PHP code). > > "am I correct... JavaScript hosted on shared domains" > In the demo, it's first injected into page without any JavaScript. > (robots.txt) > > "I don't have time to to a teardown on CloudFlare.JS" > Honestly we don't even know such file exists :-) > We uploaded and took a screenshot - that's all. > > "it's a very impressive exploit" > Thanks. > > 'make sure the label "universal" is actually justified' > It has also been tested against Yahoo etc. > > "Sorry if this has already been discussed elsewhere" > Many asked - for example: > http://ift.tt/1zv21Xy > > Again, please tell us whether you reproduce with the PHP code. > > Kind Regards, > > On 2015/2/5 3:29, Ben Lincoln (F7EFC8C9 - FD) wrote: >> So here's a possibly stupid question: is this entirely an IE flaw, or >> is it tied to the use of Cloudflare by the targeted site as well as >> the attacking site? >> >> I ask because: >> >> 1 - I tried to reproduce the attack in a number of ways without using >> CloudFlare, and was unsuccessful. >> 2 - Since I don't have access to a CloudFlare account, I used Burp to >> do a find/replace for proxied response headers and bodies on >> "www.dailymail.co.uk" and then "dailymail.co.uk" with a target domain >> which does not use Cloudflare, then accessed the Deusen demo page. >> The injection attempt failed. >> 3 - I then used Burp in the same way, but replaced >> "www.dailymail.co.uk"/"dailymail.co.uk" with a target domain which >> *does* use CloudFlare, and the injection attempt succeeded. >> >> If this is true, am I correct in thinking that while this definitely >> involves a vulnerability in IE, it also depends at least on targeting >> website owners who use JavaScript hosted on shared domains >> (CloudFlare, in this case), which is inherently riskier than hosting >> it all on one's own domain due to the way cross-domain security works >> in modern browsers? >> >> I don't have time to to a teardown on CloudFlare.JS, but does this >> also depend on some sort of code vulnerability in that file? >> >> Even if one or both of those caveats are true, it's a very impressive >> exploit, but I'd like to make sure the label "universal" is actually >> justified. >> >> Sorry if this has already been discussed elsewhere. I couldn't find >> anything when I looked. >> >> - Ben >> >> On 2015-02-02 12:53, Joey Fowler wrote: >>> Hi David, >>> >>> "nice" is an understatement here. >>> >>> I've done some testing with this one and, while there *are* quirks, >>> it most >>> definitely works. It even bypasses standard HTTP-to-HTTPS restrictions. >>> >>> As long as the page(s) being framed don't contain X-Frame-Options >>> headers >>> (with `deny` or `same-origin` values), it executes successfully. >>> Pending >>> the payload being injected, most Content Security Policies are also >>> bypassed (by injecting HTML instead of JavaScript, that is). >>> >>> It looks like, through this method, all viable XSS tactics are open! >>> >>> Nice find! >>> >>> Has this been reported to Microsoft outside (or within) this thread? >>> >>>



Source: Gmail -> IFTTT-> Blogger