Safari Cross-Domain Hijacking

`OVERVIEW  
==========  
  
The 4/8/2015 security updates from Apple included a patch for a Safari  
cross-domain vulnerability. An attacker could create web content  
which, when viewed by a target user, bypasses some of the normal  
cross-domain restrictions to access or modify HTTP cookies belonging  
to any website.  
  
Most websites which allow user logins store their authentication  
information (usually session keys) in cookies. Access to these cookies  
would allow hijacking authenticated sessions. Cookies can also contain  
other sensitive information.  
  
All tested Safari versions on iOS, OS X, and Windows were vulnerable.  
The number of affected devices may be of the order of 1 billion.  
  
Technically, the attacker can spoof the ”document.domain” property.  
It’s possible that this could lead to compromise of other resources  
apart from cookies. However, cookies was the only practical attack  
scenario found with the tested versions of Safari.  
  
The HttpOnly and Secure cookie flags represent an important mitigating  
factor albeit with some caveats (see below).  
  
  
  
DETAILS  
========  
  
Safari supports the FTP URL scheme allowing HTML documents to be  
accessed via URLs beginning with "ftp://". These URLs can be of the  
form ftp://user:password@host/path. The problem arises when encoded  
special characters are used in the user or password parts.  
  
Consider the following URL:  
  
ftp://user%40attacker.com%2Fexploit.html%[email protected]/  
  
  
If correctly interpreted, the URL refers to a document on apple.com.  
However, when loaded by a vulnerable browser, the network layer uses  
an extraneously decoded version of the URL:  
  
ftp://[email protected]/exploit.html#apple.com/  
  
  
The document would be loaded from attacker.com, not apple.com. Yet the  
document properties such as ”document.domain” and ”document.cookie”  
are correctly initialised using ”apple.com”.  
  
The attacker-supplied document, exploit.html, can therefore access and  
modify cookies belonging to apple.com via JavaScript.  
  
It’s possible that cookies aren’t the only resource accessible this  
way, but at least recent Safari versions (tested desktop only) use the  
document origin instead of only host or domain for most other access  
control, e.g. password autofilling and geolocation permissions.  
  
The attack can be performed on normal web pages by embedding an IFRAME  
pointing to an FTP URL.  
  
  
  
MITIGATING FACTORS  
===================  
  
The cookie attack requires JavaScript so existing cookies with the  
HttpOnly flag can’t be seen by the attacker. Support for this flag  
reportedly appeared in Safari 4. Earlier versions would be vulnerable  
even with the HttpOnly flag.  
  
Safari allows (over)writing of HttpOnly cookies so the flag doesn’t  
prevent this vulnerability to be exploited for session fixation and  
similar attacks.  
  
Cookies with the Secure flag aren’t accessible for documents loaded via FTP.  
  
  
  
VULNERABLE VERSIONS  
=====================  
  
The following versions were tested and found vulnerable:  
  
- Safari 7.0.4 on OS X 10.9.3  
- Safari on iPhone 3GS, iOS 6.1.6  
- Safari on iOS 8.1 simulator  
- Safari 5.1.7 on Windows 8.1  
  
Earlier versions weren’t available for testing, but according to  
available statistics their usage should be negligible.  
  
  
  
SOLUTION  
=========  
  
Apple was notified on January 27, 2015. The following patches were  
released in April 2015:  
  
- APPLE-SA-2015-04-08-3 iOS 8.3 - iPhone 4s and later, iPod touch (5th  
generation) and later, iPad 2 and later  
- APPLE-SA-2015-04-08-1 Safari 8.0.5, Safari 7.1.5, and Safari 6.2.5 -  
OS X Mountain Lion, Mavericks, Yosemite  
  
For more information see: https://support.apple.com/en-us/HT201222  
  
  
  
WORKAROUND  
=============  
  
The attacker has to set up an FTP server or use an existing public  
one. Such server can run on any TCP/IP port number.  
  
One way to stop such attacks (e.g. for older devices with no available  
patch) would be to deny all traffic to the public internet and  
configure the device to use a HTTP proxy located in the internal  
network. This should prevent access to all FTP URLs.  
  
  
  
CREDITS  
========  
  
The vulnerability was found and researched by Jouko Pynnönen of Klikki  
Oy, Finland.  
  
  
  
--   
Jouko Pynnonen <[email protected]>  
Klikki Oy - http://klikki.fi - @klikkioy  
`