Apple patches iOS captive portal bug that let hackers impersonate victims online
An iOS bug that allowed malicious agents to impersonate end users' identities by granting read/write access to website cookies was fixed with the release of iOS 9.2.1 on Tuesday, some two and a half years after it was first reported to Apple.
According to security firm Skycure, the iOS flaw involved a shared cookie store installed between Safari and embedded browsers used to facilitate "captive portals" like those employed by gated Wi-Fi networks at coffee shops, hotels and other public locales, reports ArsTechnica.
The vulnerability allowed attackers to set up a captive portal, attach it to a public Wi-Fi network and, after an unprotected iOS device connected, redirect the Apple Captive request to trigger a captive portal. The resulting embedded browser, which shares its cookie store with Safari, might be designed to load and execute malicious JavaScript content like an operation to steal HTTP cookies.
Armed with resources gleaned from the shared cookie store, attackers had free rein to impersonate end users online, force victims to log into an unwanted account without their knowledge or trigger malicious code.
Apple fixed the issue in iOS 9.2.1 by creating an isolated cookie store for all captive portals instead of relying on a shared store connected to Safari.
Skycure first reported its findings to Apple in June 2013, but notes the fix "was more complicated than one would imagine." There is no evidence to suggest the vulnerability was exploited outside of controlled experiments.
According to security firm Skycure, the iOS flaw involved a shared cookie store installed between Safari and embedded browsers used to facilitate "captive portals" like those employed by gated Wi-Fi networks at coffee shops, hotels and other public locales, reports ArsTechnica.
The vulnerability allowed attackers to set up a captive portal, attach it to a public Wi-Fi network and, after an unprotected iOS device connected, redirect the Apple Captive request to trigger a captive portal. The resulting embedded browser, which shares its cookie store with Safari, might be designed to load and execute malicious JavaScript content like an operation to steal HTTP cookies.
Armed with resources gleaned from the shared cookie store, attackers had free rein to impersonate end users online, force victims to log into an unwanted account without their knowledge or trigger malicious code.
This issue allows an attacker to:
- Steal users' (HTTP) cookies associated with a site of the attacker's choice. By doing so, the attacker can then impersonate the victim's identity on the chosen site.
- Perform a session fixation attack, logging the user into an account controlled by the attacker-because of the shared Cookie Store, when the victims browse to the affected website via Mobile Safari, they will be logged into the attacker's account instead of their own.
- Perform a cache-poisoning attack on a website of the attacker's choice (by returning an HTTP response with caching headers). This way, the attacker's malicious JavaScript would be executed every time the victim connects to that website in the future via Mobile Safari.
Apple fixed the issue in iOS 9.2.1 by creating an isolated cookie store for all captive portals instead of relying on a shared store connected to Safari.
Skycure first reported its findings to Apple in June 2013, but notes the fix "was more complicated than one would imagine." There is no evidence to suggest the vulnerability was exploited outside of controlled experiments.
Comments
There may be good reasons we don't hear about some things like this.