A security researcher based in Delhi recently found a rather significant flaw with the Sign in with Apple feature. The vulnerability meant that attackers could have accessed other users’ accounts or created accounts while posing as another user. The impact that this vulnerability could have had makes it an obvious critical flaw, but thankfully, Apple has already addressed the issue and assured customers there was no evidence that this was exploited. However, given the mistake, our very own Sean Wright, Lead Application Security SME here at Immersive Labs, thinks there are a few lessons to be learnt.
The vulnerability itself
Let’s take a quick look at the issue at hand. Without going into the fine details (of which the researcher who found it does a great job), one of the features Sign in with Apple allows is the ability to create a private email address with which to sign in. This means that while the user authenticates to Apple with their actual email address, they can specify a different email address to use when authenticating to the requested service, which they are ultimately signing into. Now the problem lies with Apple not validating this specified email address appropriately.
This means that any authenticated user could simply request to authenticate to a service, or create an account, using any email address. Since most systems would then take this email address to map a user within its own system, the user here could use the Sign in with Apple feature to authenticate as any user in the service.
Lesson One – Security testing
Initially, Sean was surprised that a large, well-resourced company like Apple had missed such a vulnerability, as appropriate security testing should have found the issue.
This is a common test to perform during a security or system review. It ensures that any requested resource or data actually belongs to the user requesting it, a process that should have been especially scrutinized for a single sign on (SSO) feature.
Here, it’s also important to note that while tools like web application scanners are extremely helpful at times, they are limited, and cannot replace the vital element of human testing. In addition, they also cannot typically test authorization or access-based flaws.
Lesson 2 – Avoid reinventing the wheel
Sometimes, trying to create your own custom solution is not a good idea. Apple decided to reinvent the wheel here, for reasons that must have made sense to them. However, there are many well-established SSO protocols in place that have existed for years, and therefore experienced much scrutiny and testing. It begs the question why Apple felt the need to custom-build its own sign in solution, when the working tools, implementations, and frameworks for this already function well.
Lesson 3 – Bug bounties
The researcher who discovered the vulnerability earned himself a hefty payday of $100k. Thankfully, he reported the issue in a responsible manner and allowed Apple to fix it before going public. If it had been exploited publicly, the company would have suffered a huge negative impact on its reputation and business as a whole. It proves once again to the humans of cyber that additional sets of eyes – not computers – will faster identify a significant vulnerability.
Conclusion
While there’s no doubt that Apple had its own reasons for choosing the route it did, this vulnerability does highlight the risks that choosing such a path can lead to. It also accentuates the need for appropriate and thorough testing, especially on security sensitive systems, preferably by many sets of eyes.
To learn more about JWTs and their potential weaknesses, head to this lab.