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:
?php
usleep(300);
header(Location: http://www.dailymail.co.uk/;);
die();
?
?php
sleep(3);
header(Location: http://www.dailymail.co.uk/;);
die();
?
?php
sleep(10);
header(Location: http://www.dailymail.co.uk/;);
die();
?
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://innerht.ml/blog/ie-uxss.html)) 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:
?php
sleep(2);
header(Location: http://www.dailymail.co.uk/robots.txt;);
?
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://www.milw00rm.com/exploits/7057
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?
--
Joey Fowler
Senior Security Engineer, Tumblr
On Sat, Jan 31, 2015 at 9:18 AM, David Leo david@deusen.co.uk
wrote:
Deusen just published code and description here:
http://www.deusen.co.uk/items/insider3show.3362009741042107/
which demonstrates the serious security issue.
Summary
An Internet Explorer vulnerability is shown here:
Content of dailymail.co.uk can be changed by external domain.
How To Use
1. Close the popup window(confirm dialog) after three seconds.
2. Click
