Vulnerability in New TouchID Feature Puts iCloud Accounts at Risk of Break-In
Article content
Logging in via TouchID/FaceID in Safari - no 2FA?
In iOS 13 and macOS 10.15, Apple added the ability to log in to Apple's own sites with TouchID/FaceID in Safari. When you visit a page with an Apple account login form, a prompt appears to authenticate with TouchID. If authentication succeeds, you are immediately logged in - skipping the two-factor authentication step you normally have to perform.
The Vulnerability
Two parameters are very important in the iframe URL: the client_id and redirect_uri. The idmsa.apple.com server maintains a list of registered OAuth2 clients and the redirect URIs allowed for each client. For all OAuth2 modes, it is very important that the authentication server correctly validates the redirect URI.
What we discovered was that the gsa.apple.com API had a bug: although the client_id and redirect_uri were included in the data sent by akd, it did not check whether the redirect URI matched the client ID. Instead, only a whitelist was applied to the domains: all domains ending in apple.com, icloud.com, and icloud.com.cn were allowed.
Apple.com has hundreds of subdomains. If any of these subdomains could be made to execute malicious JavaScript, they could be used to trigger the prompt for a login with the iCloud client_id, allowing that script to retrieve the user's grant code. The page could then send this to an attacker who could use it to obtain a session on icloud.com.
Use of Captive Portal
A particularly interesting attack scenario: captive.apple.com. When an Apple device connects to a Wi-Fi network, it tries to access http://captive.apple.com/hotspot-detect.html. By setting up a rogue hotspot at a location where users expect a captive portal (airport, hotel, train station), it would have been possible to gain access to a significant number of iCloud accounts - bypassing the normal 2FA approval and 6-digit code step.
Apple's Response
We reported this vulnerability to Apple through their responsible disclosure program, and they resolved it the same day after reviewing it. The gsa.apple.com API now correctly checks whether the redirect_uri matches the client_id. This meant it could be fully resolved on the server side.