On Tuesday, researchers from Skycure disclosed at the RSA conference that a previously known iOS flaw related to automatic Wi-Fi network connection and a newly discovered SSL certificate handling error could cause an iPhone or iPad to crash and endlessly reboot as long as it remains within range of the network. (Skycure sells monitoring and mitigation systems.)
The problem of devices automatically joining Wi-Fi networks is longstanding, and the researchers highlighted a specific aspect of it that they first uncovered in 2013 and labeled it WiFiGate: mobile carriers in some markets preconfigure iPhones to connect automatically to certain Wi-Fi network names.
These network names are easily spoofable, allowing an iPhone (or Mac or any Wi-Fi-enabled device) to connect to what is often called an “evil twin” network. That network can attempt to deliver malware or redirect to look-alike pages among other activity.
But it’s often hard to exploit iOS unless there’s an active, unpatched problem, as is currently the case. The researchers reported this to Apple, didn’t release the precise details of the validation crash, and iOS 8.3 appears to fix some, but not all, of the potential for exploitation.
Promiscuous Wi-Fi connections
Wi-Fi was developed so long ago that it carries with it a lot of cruft and difficulties. The first flavors of what is certified as Wi-Fi as an industry trade group were 802.11b and 802.11a, standardized in 1999. Some aspects of that 1999 technology remains.
Every Wi-Fi base station and network adapter, as in a mobile or laptop, has a unique factory-assigned address, just like every ethernet adapter. (On some devices, that number can be changed through software or firmware.) A base station’s address is a BSSID, or basic service set identifier, and it has a unique BSSID for 2.4GHz and 5GHz networks if it supports both simultaneously or as an option at startup. These IDs are represented as a set of six hexadecimal (base 16) numbers separated by colons, like 00:19:E3:32:D3:6F.
But we don’t, of course, connect to a base station by number. Instead, we use a name, the Service Set Identifier (SSID). In a network with multiple base stations, this is called an Extended SSID (ESSID), in which every base station has its own numeric address but they all share the network name.
When you select the network name, your computer or mobile will examine all the base stations associated with the name, and pick one, typically based on a combination of signal quality, signal strength, and throughput. Almost all devices freely roam, and disconnect and reconnect as you move among as set of base stations with the same name. On a Mac, hold down Option and click the Wi-Fi menu, and the BSSID appears along with other connection parameters for the base station to which you’re currently connected.
Here’s the 1999 part of this equation. For encrypted networks, your device will only connect to a network for which it’s stored a password. If another network appears with the same name and a different password (or even login method) or without a password at all, your device won’t connect.
However, there’s no authentication or any kind for password-free networks used for public space Wi-Fi in cafés, conference centers, airports, and hotels. This is true even when there’s a portal at which you’re redirected to enter login information, a usage code, or payment details. The network is still open.
This is an obvious problem, and has been for some time. There’s no way to prevent a device that has a stored network connection for an open network from connecting to any network with the same name, regardless of which base stations are attached.
Because mobile carriers have built up big Wi-Fi networks of their own and partnered with other networks for use to offload data (and sometimes voice) traffic from cellular networks, a malicious party can pick from among many networks names while also being assured in any dense portion of a city of having a large attack surface—thousands or tens of thousands of people every day.
The particular attack in question
The attack detailed by Skycure is fascinating because it apparently arose from simply plugging in a router that delivered a malformed SSL certificate. This isn’t strange. A lot of network gear is cheaply and hastily made, and uses generic and outdated firmware, sometimes lightly or unmodified open-source software builds.
The researchers found that their iOS devices crashed when connected and sorted out the flaw. By using a similarly malformed certificated on an “evil twin” access sharing the name of any of a number of popular carrier-associated networks, an attacker could cause any iOS device that connects to crash and restart.
But the reason this attack is interesting is twofold. First, you don’t have to have previously connected to the Wi-Fi network’s name in the case of networks carriers bake into a profile. Second, the crash happens at the initial connection, so after reboot (as shown in a video on the firm’s site) the Wi-Fi network re-association happens and the crash occurs before you can disable Wi-Fi on the phone.
Your only recourse is perhaps to wrap the phone securely in aluminum foil or leave the vicinity of the attacking network. To a regular user, it would appear as if their phone was simply broken and rebooting over and over again. Even restoring the phone in the vicinity wouldn’t work, because once it’s activated on the carrier network, it would install or retrieve the connection setting profile.
And the attack isn’t active. With a fake base station set up, it needs no Internet connection and it can fake multiple names using virtual networks, a Wi-Fi feature that lets one hardware base station sport many names. (That’s how guest networking works with Apple’s equipment.)
The repair is surely coming from Apple for the SSL certificate parsing flaw. But the bigger issue in the industry that remains requires time to fix. There has to be a way to let users more effectively only connect to networks to which they intend to, and none yet exists.