exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

Safari Cross-Domain Hijacking

Safari Cross-Domain Hijacking
Posted Apr 12, 2015
Authored by Jouko Pynnonen | Site klikki.fi

Details are included in this document for the 04/08/2015 path for Safari that addressed a cross-domain vulnerability.

tags | exploit
SHA-256 | 9f8ec067d40310ecc23e25b016e3f45ab775e1b132ddc241efdac303005fee15

Safari Cross-Domain Hijacking

Change Mirror Download
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%23@apple.com/


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://user@attacker.com/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 <jouko@iki.fi>
Klikki Oy - http://klikki.fi - @klikkioy
Login or Register to add favorites

File Archive:

July 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jul 1st
    27 Files
  • 2
    Jul 2nd
    10 Files
  • 3
    Jul 3rd
    35 Files
  • 4
    Jul 4th
    27 Files
  • 5
    Jul 5th
    18 Files
  • 6
    Jul 6th
    0 Files
  • 7
    Jul 7th
    0 Files
  • 8
    Jul 8th
    28 Files
  • 9
    Jul 9th
    44 Files
  • 10
    Jul 10th
    24 Files
  • 11
    Jul 11th
    25 Files
  • 12
    Jul 12th
    11 Files
  • 13
    Jul 13th
    0 Files
  • 14
    Jul 14th
    0 Files
  • 15
    Jul 15th
    28 Files
  • 16
    Jul 16th
    6 Files
  • 17
    Jul 17th
    34 Files
  • 18
    Jul 18th
    6 Files
  • 19
    Jul 19th
    0 Files
  • 20
    Jul 20th
    0 Files
  • 21
    Jul 21st
    0 Files
  • 22
    Jul 22nd
    0 Files
  • 23
    Jul 23rd
    0 Files
  • 24
    Jul 24th
    0 Files
  • 25
    Jul 25th
    0 Files
  • 26
    Jul 26th
    0 Files
  • 27
    Jul 27th
    0 Files
  • 28
    Jul 28th
    0 Files
  • 29
    Jul 29th
    0 Files
  • 30
    Jul 30th
    0 Files
  • 31
    Jul 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close