tl;dr Apple Safari for OS X was prone to URI spoofing vulnerability (and more general a user interface spoofing). Apple released security updates for Safari 9 on OS X and assigned CVE-2015-5764. Accidentally this vulnerability was also present in iOS.
In Safari up to 8.0.8 :
Well this looks a clear caching problem to me, right :) ?
Several months ago (almost a year!!) I was reading the great book written by lcamtuf (aka Michal Zalewski) named The Tangled Web . I know, I know I was a bit late for the party :)
As for almost all the parts of this book I wanted to try what it was written and I started a bit to poke around. The followers of this blog know that I kind of like to "play" with OAuth. Hence I combined the two things and started to see what I could do.
The first issue I found was the one mentioned in the Instant demo section above.
Now, in order to understand the issue we need to look at the code of <https://asanso.github.io/CVE-2015-5764/file0.html>
<a href="http://www.intothesymmetry.com/CVE-2015-5764/file0.php">click me! </a>
As you can see this is simply pointing to a PHP page in my website (http://www.intothesymmetry.com/CVE-2015-5764/file0.php). So let's take a look at it:
This is simply an HTTP 302 redirect to data:text/html,data:text/html,<H1>Hi!!</H1>
Now when clicking at the link all the browser but Safari showed properly the address bar being data:text/html,%3CH1%3EHi!!%3C/H1%3E . Safari instead from the second visit onward would show the original website namely http://www.intothesymmetry.com/CVE-2015-5764/file0.php but with the HTML contained in the data:text/html pseudo-URI!!!
Well well this looks like an URI spoofing according to my book ;)
Safari was not unkown to this kind of vulnerability in 2015, same as Google Chrome
At this point your question can easily be why on earth should exists a website that allow an attacker to manipulate a 302 redirect versus a data:text/html URI and how did you find this weird vulnerability :D ? The answer is: because of some OAuth 2.0 implementations!!!
One of steps in order to obtain an OAuth client is to register a client application providing client name and a list of redirect_uri.
Below a little reminder on how a typical OAuth flow would look like
It turns out that exists some OAuth Autorization server that allows the registration of redirect_uri of the form of data:text/html. One example ~~is~~ (was as Facebook fixed this in the meantime) Moves on of Facebook acquisitions
The final piece of the puzzle is an Open Redirect vulnerability that exists in rfc6749 aka 'The OAuth 2.0 Authorization Framework' and some of its implementation . You can see an example of it clicking one of the links below:
would have redirected you to data:text/html,a&state=<script>alert('hi')</script>
So far so good. Now let's try to sum up. Indeed we have all we need for a real attack. For an attacker would be enough to:
- find a website that offers OAuth support
- this website needs to allow registration of redirect_uri also of the type data:text/html
- this website implements OAuth 2 verbatim hence has an open redirect
- craft a URI of the form https://api.moves-app.com/oauth/v1/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&redirect_uri=data%3Atext%2Fhtml%2Ca&state=<script>alert('hi')</script>
And here we go, you would have a spoofed website (thanks to CVE-2015-5764)
Apple released two security updates this month that include a fix for this issue:
It looks like Apple Security team broke down the fix for this issue in two tranches. Indeed if you careful read the description of CVE-2015-5764
Description: Multiple user interface inconsistencies may have allowed a malicious website to display an arbitrary URL. These issues were addressed through improved URL display logic.
This means that also other user interface were vulnerable and not only the address bar. One of the vulnerable component was the title of the alert box (that is commonly used for anti-phishing) .
But looks like Apple fixed this part of vulnerability in the previous security update.
If you want to give a look to it with Safari 8.0.7 :