Security has become the main focus of marketing campaigns for Apple devices, although we should not forget that any product is completely safe from some threats, as mentioned by iOS pentesting specialists. A researcher has revealed a flaw that would allow threat actors to gain unauthorized access to an iCloud account, abusing a feature to log in via TouchID.
Researcher Thijs Alkemade notes that iOS 13 and macOS 10.15 systems included a feature to sign in to Apple sites using TouchID or FaceID, as long as the device has hardware support for reading biometric data. This feature works as multi-factor authentication, as Apple relies on the device used and the user’s biometric logs to log in; the function can be disabled at any time.
The iOS pentesting specialist claims that the vulnerability is present on any device that uses AppleID login, so the extent of a potential attack is significant.
Sign in to Apple domains using OAuth2
In iCloud, sign-in with OAuth2 is done with https://icloud.com, using the “web_message” mode. This works as follows:
- https://icloud.com incorporates an iframe aimed at:
https://idmsa.apple.com/appleauth/auth/authorize/signin?client_id=d39ba9916b7251055b22c7f910e2ea796ee65e98b2ddecea8f5dde8d9d1a815d&redirect_uri=https%3A%2F%2Fwww.icloud.com&response_mode=web_message&response_type=code
- The user logs in inside the iframe
- If authentication succeeds, the iframe publishes a message to the main window with a grant code for the user using window.parent.postMessage (<token>, “https://icloud.com”) in JavaScript
- The icloud.com page uses grant_code to continue the login process
Two of the parameters are very important in the iframe:client_id and redirect_uri URL. The server idmsa.apple.com tracks a list of registered OAuth2 clients and the redirect URIs allowed for each client. In the case of the web_message flow, the redirect URI is not used as an actual redirect, but is used as the required page source of the message published with the grant code (the second argument for postMessage).
When the user authenticates with TouchID, the iframe is handled differently, but the external page remains the same, the iOS pentesting expert mentions. In the case of Safari, when a new page with a URL that matches that of the scenario described is detected, the page is not downloaded, but the AKAppSSOExtension process is invoked.
The AuthKit daemon (akd) is then contacted to handle biometric authentication and retrieve the grant code. If the user is successfully authenticated, Safari injects a false response to the iframe request, which returns the message in the same way as a regular website would. The akd daemon communicates with an API in gsa.apple.com, sending the request details.
An error was eventually discovered in the gsa.apple.com API; Even though URLs are included in the data sent by akd, the redirect URL is not verified to match the client ID, so any domain that ends with apple.com, icloud.com, or icloud.com.cn is allowed. Although this seems normal, it is necessary to remember that Apple has hundreds, or even thousands of domains, so threat actors can deploy all kinds of attacks to redirect users to unsafe sites and thus gain control over compromised iCloud accounts.
Alkemade confirmed that Apple received the report and announced the correction of this flaw. The update is now ready, so it’s only necessary for users to verify that their devices have the latest version of the affected operating system.
He is a well-known expert in mobile security and malware analysis. He studied Computer Science at NYU and started working as a cyber security analyst in 2003. He is actively working as an anti-malware expert. He also worked for security companies like Kaspersky Lab. His everyday job includes researching about new malware and cyber security incidents. Also he has deep level of knowledge in mobile security and mobile vulnerabilities.
