When Apple unveiled Sign in with Apple last year, it touted the new single-sign-on feature as a great way for privacy-conscious users to take advantage of the kind of simplified and unified sign-on features that have long been offered by other tech giants like Facebook and Google without having to give up needless amounts of personal data.
While Google insists it’s not collecting personal data as part of its sign-on feature, it’s definitely been more opaque about the process, and on the other hand there’s little doubt that Facebook has a much worse track record in this regard, so Sign in with Apple came as a breath of fresh air — a solution where Apple was guaranteeing that you wouldn’t even need to supply your e-mail address when signing up for third-party services.
However, while Apple’s unified sign-on feature has undoubtedly been great for privacy, it may not have been quite as good for security, as a new researcher has just discovered.
‘Full Account Takeover’
Security researcher Bhavuk Jain recently discovered a zero-day vulnerability in the Sign in with Apple feature that would allow a hacker to access any third-party site that a user had linked to their Apple ID, assuming the site didn’t also have its own additional security measures.
Similar to other unified login services, Sign in with Apple works by generating a “token” based on the user’s Apple ID. This token is “signed” by Apple’s servers to validate its legitimacy, and is sent to the third-party service to validate the user as belonging to that particular Apple ID. The service checks the token, the signature, and the payload and then either creates a new account for the user or logs them into their existing one if they’ve previously used the service.
As Jain explains in his blog, however, it was possible to programmatically ask Apple’s servers to generate a “token” for any e-mail address, not just the requester’s own. By using an e-mail address that matches an Apple ID belonging to somebody else, an attacker could generate a token for just about anybody and then feed that to a third-party service using the Sign in with Apple feature to authenticate as that user — either to log into their existing account or to set up a new one.
The security hole was that while Apple’s servers would only generate valid tokens for users who were signed in, it was missing the second step of ensuring that the token request actually matched the e-mail address of the currently authenticated user. So you could log in to an Apple ID for “John Doe” and request a token for “Fred Smith” and Apple would happily give you a legitimate, signed token. Feed that token to a service like Dropbox, and it would happily let you into Fred’s account.
To be clear, this had to be a somewhat targeted attack, as the attacker would have to know your e-mail address specifically, but it’s also important to note that even users who chose to use a Sign in with Apple hidden “privacy” e-mail address were still vulnerable, since it’s the user’s actual e-mail address that’s used to request the token — the private email address is just what gets sent to the third-party service provider when the user first signs up for a new account.
Only those services that relied exclusively on Sign in with Apple for authentication were vulnerable, so if the service relied on a second factor for authentication, the attacker would be blocked at that point. Also, if a user already had an account on a service but hadn’t yet associated it with their Apple ID, the vulnerability couldn’t be exploited as most third-party services require the user to supply the password for their existing account before they can link it to their Apple ID.
It’s also important to note that this only affected third-party services where Sign in with Apple was used. It could not be used to access a user’s Apple ID or iCloud data, merely to forge Apple ID credentials for third-party services.
All of this having been said, however, Jain actually reported the bug to Apple back in April as part of its bug bounty program before he went public with the information, giving Apple time to fix the problem, which it’s now done, Jain said in an interview with The Hacker News.
Jain was paid $100,000 bounty by Apple for his discovery, which allowed the company to find and patch the problem before it could do any damage; according to Apple an investigation of its servers logs confirmed that the flaw had not been exploited to actually compromise any account.