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

"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