Skip to main content

Apple Safari URI spoofing (CVE-2015-5764)

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.

Instant demo

In Safari up to 8.0.8 :
  • go to https://asanso.github.io/CVE-2015-5764/file0.html
  • click "click me!"
  • notice the address bar being "data:text/html,%3CH1%3EHi!!%3C/H1%3E"
  • go back using the browser button
  • click "click me!"
  • notice the address bar being http://www.intothesymmetry.com/CVE-2015-5764/file0.php !!!! 

Well this looks a clear caching problem to me, right :) ?

The Introduction (Oldie but goldie)

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 :)
Said that, this book contained a really interesting Chapter (for the record Chapter 10) that is dedicated almost entirely to pseudo-URLs such as (about:, javascript:, or data:). 
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 Issue

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

<html>
<a href="http://www.intothesymmetry.com/CVE-2015-5764/file0.php">click me! </a>
</html>


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:

<?php
header("Location: data:text/html,<H1>Hi!!</H1>");
exit();
?>


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

The Vulnerability(ies)

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. 

<snip>
//SHAMELESS SELF ADVERTISEMENT
If you are not too much familiar with OAuth 2.0 here you can find a book on OAuth that Justin Richer and myself have been writing on the subject.
</snip>

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:
The link will redirect to the registered_uri (without any user interaction). Before Facebook fixed the data:text/html redirect_uri clicking the following URL


 would have redirected you to  data:text/html,a&state=<script>alert('hi')</script>

The Attack

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)



The Fix

Apple released two security updates this month that include a fix for this issue:

Beyond URI spoofing

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 :

Visit

https://asanso.github.io/CVE-2015-5764/file.html
https://asanso.github.io/CVE-2015-5764/file2.html
https://asanso.github.io/CVE-2015-5764/file3.html

Comments

Lee Wei said…
Not working for me.

I'm on Mac OSX 10.10.5, Safari web browser 8.0.8 (10600.8.9).
Antonio Sanso said…
@Lee Wei, I reported this issue to Apple in November 2014 (almost a year ago) as said in the blog post Apple Security fixed this in progressively so might well be ....
Lee Wei said…
I'm writing that comment because in your blog post, under "Instant demo", it reads "In Safari up to 8.0.8 :...."

you don't mean to say 8.0.8 (inclusive), since at the end of your article you state 8.0.7...

Popular posts from this blog

Slack SAML authentication bypass

tl;dr  I found a severe issue in the Slack's SAML implementation that allowed me to bypass the authentication. This has now been solved by Slack.
Introduction IMHO the rule #1 of any bug hunter (note I do not consider myself one of them since I do this really sporadically) is to have a good RSS feed list.  In the course of the last years I built a pretty decent one and I try to follow other security experts trying to "steal" some useful tricks. There are many experts in different fields of the security panorama and too many to quote them here (maybe another post). But one of the leading expert (that I follow) on SAML is by far Ioannis Kakavas. Indeed he was able in the last years to find serious vulnerability in the SAML implementation of Microsoft and Github. Usually I am more an "OAuth guy" but since both, SAML and OAuth, are nothing else that grandchildren of Kerberos learning SAML has been in my todo list for long time. The Github incident gave me the final…

Bug bounty left over (and rant) Part III (Google and Twitter)

tl;dr in this blog post I am going to talk about some bug bounty left over with a little rant.

Here you can find bug bounty left over part I and II
Here you can find bug bounty rant part I and II
Introduction In one of my previous post I was saying that: 

"The rule #1 of any bug hunter... is to have a good RSS feed list."
Well well well allow me in this post to state rule #2 (IMHO)

"The rule #2 of any bug hunter is to DO NOT be to fussy with 'food' specifically with left over"

aka even if the most experience bug hunter was there (and it definitely was my case here, given the fact we are talking about no one less than filedescriptor) do not assume that all the vulnerabilities have been found! So if you want some examples here we go.
Part I - GoogleI have the privilege to receive from time to time Google Vulnerability Research Grant. One of the last I received had many target options to choose from, but one in particular caught my attention, namely Google Issue T…

OpenSSL Key Recovery Attack on DH small subgroups (CVE-2016-0701)

Usual Mandatory Disclaimer: IANAC (I am not a cryptographer) so I might likely end up writing a bunch of mistakes in this blog post...

tl;dr The OpenSSL 1.0.2 releases suffer from a Key Recovery Attack on DH small subgroups. This issue got assigned CVE-2016-0701 with a severity of High and OpenSSL 1.0.2 users should upgrade to 1.0.2f. If an application is using DH configured with parameters based on primes that are not "safe" or not Lim-Lee (as the one in RFC 5114) and either Static DH ciphersuites are used or DHE ciphersuites with the default OpenSSL configuration (in particular SSL_OP_SINGLE_DH_USE is not set) then is vulnerable to this attack.  It is believed that many popular applications (e.g. Apache mod_ssl) do set the  SSL_OP_SINGLE_DH_USE option and would therefore not be at risk (for DHE ciphersuites), they still might be for Static DH ciphersuites.
Introduction So if you are still here it means you wanna know more. And here is the thing. In my last blog post I was …