Hacking Apple OS
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 issue if an attacker can control this functionality. OS X detects the captive portal by requesting the URL:
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.
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 broadsp_ConvertSQLServerDateing 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
- Attacker may set up their own network with an AP, spoofing a popular SSID known by their victim
- Connect to an existing wireless network and deplete the DHCP pool of all addresses
- 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:
- Configure the Target to be 0 (Generic Java Payload)
- Leave SRVPORT 8080
- Set URIPATH to /portal
- Configure SigningCert and SigningKey
Figure 1: Example of settings for the java_signed_applet module.
Contents of the index.html page:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
Captive Portal<br />
6) Wait for users to connect and profit.
Figure 2: Interacting with the Java-Meterpreter shell.
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.
Figure 3: The user’s perspective of the Captive Portal’s malicious dialog box.
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: