I’m thankful for all the smart, diligent people working hard to keep us all safe.
Zero-day in Sign in with Apple
71–80 of 280 posts
Re: Zero-day in Sign in with Apple
#72> The Sign in with Apple works similarly to OAuth 2.0. > similarly I understand why they wanted to modify OAuth 2.0, but departing from a spec is a very risky move. > $100,000 That was a good bounty. Appropriate given scope and impact. But it would have been a lot cheaper to offer a pre-release bounty program. We (Remind) occasionally add unreleased features to our bounty program with some extra incentive to explore…
> I understand why they wanted to modify OAuth 2.0, but departing from a spec is a very risky move. The token described in this disclosure is an OpenID Connect 1.0 Token. OIDC is a state of the art AuthN protocol that supersets OAuth with additional security controls. It's used by Google, Facebook and Twitch amongst others. I'd do more analysis, but the author leaves off the most important part here (not sure why) ht…
The important part is in the author’s article. The POST to the opened endpoint generates a valid JWT token for the email address in the payload, not for the one in the logged-in session. Everything else is extraneous.
Re: Zero-day in Sign in with Apple
#73> I found I could request JWTs for any Email ID from Apple and when the signature of these tokens was verified using Apple’s public key, they showed as valid. This means an attacker could forge a JWT by linking any Email ID to it and gaining access to the victim’s account. Great writeup there. Looks like a Apple JWT bug and the verification went through despite it being 'signed' and 'tamperproof'. Clearly its footgun…
No one should be using JWT but it's unfair to blame JWT here. Apple wasn't verifying the supplied email address belonged to the signed in user - that's completely outside of the token format they chose.
> No one should be using JWT
I've heard criticisms of JWT -- mostly around the lack of ability to revoke a JWT.
One could then introduce a refresh token with a longer ttl, which can be revoked on the server. But of course then you lose some of the statelessness that JWT benefits from.
But still, it seems like a reasonable approach to authentication to me. I can authenticate with several services if need be, and I can check locally if my token is 'likely' valid.
Care to expand why you think one shouldn't use JWT tokens?
Re: Zero-day in Sign in with Apple
#74How is this something that can happen? I mean, the only responsibility of an "authentication" endpoint is to release a JWT authenticating the current user.
At least from the writeup, the bug seems so simple that it is unbelievable that it could have passes a code review and testing.
I suspect things were maybe not as simple as explained here, otherwise this is at the same incompetence level as storing passwords in plaintext :O.
Re: Zero-day in Sign in with Apple
#75Wow that’s a really simple bug. Kudos to the OP to even try that. Most people would just look elsewhere thinking Apple of all companies would get such a basic thing right.
What do you mean simple? The result/exploit is simple, but what is the reason the bug is there? Surely the Apple code base is not that simple.
Re: Zero-day in Sign in with Apple
#76Wow, I'm in shock. How could Apple let this one slip in? When I was a junior fullstack I had to design a very similar system and this was one of the very basic checks that I had in mind back then. I don't know how could anyone excuse this very basic bug in such critical service.
Re: Zero-day in Sign in with Apple
#77How is this something that can happen? I mean, the only responsibility of an "authentication" endpoint is to release a JWT authenticating the current user. At least from the writeup, the bug seems so simple that it is unbelievable that it could have passes a code review and testing. I suspect things were maybe not as simple as explained here, otherwise this is at the same incompetence level as storing passwords in pl…
Apple has had more simple "unbelievable" bugs, e.g
https://news.ycombinator.com/item?id=15800676 (Anyone can login as root without any technical effort required)
And to top it off (https://news.ycombinator.com/item?id=15828767)
Apple keeps having all sorts of very simple "unbelievable" bugs.
Re: Zero-day in Sign in with Apple
#78Wow. That's almost inexcusable, especially due to the requirement of forcing iOS apps to implement this. If they didn't extend the window (from originally April 2020 -> July 2020) so many more apps would have been totally exploitable from this. After this, they should remove the requirement of Apple Sign in. How do you require an app to implement this with such a ridiculous zero day?
I’m of the mind that just about any security bug is “excusable” if it passed a good faith effort by a qualified security audit team and the development process is in place to minimize such incidents. The problem I have is that I can’t tell what their processes are beyond the generic wording on this page[1] [1] support.apple.com/guide/security/introduction-seccd5016d31/web
Even if there was clear evidence that this system underwent a proper security audit, with a failure this basic you would have to ask why it didn't work. What is going on inside Apple that brought them to the point of releasing a lock that simply opens with any key, despite the efforts of their state of the art lock design process and qualified lock auditors?
Re: Zero-day in Sign in with Apple
#79How is this something that can happen? I mean, the only responsibility of an "authentication" endpoint is to release a JWT authenticating the current user. At least from the writeup, the bug seems so simple that it is unbelievable that it could have passes a code review and testing. I suspect things were maybe not as simple as explained here, otherwise this is at the same incompetence level as storing passwords in pl…
Apple has really lost their touch, software quality has declined dramatically
Re: Zero-day in Sign in with Apple
#80" Apple also did an investigation of their logs and determined there was no misuse or account compromise due to this vulnerability. " Given the simplicity of the exploit, I really doubt that claim. Seems more likely they just don't have a way of detecting whether it happened.
The one case (and about the only case) I can think of where they can claim above is:
If they have a log of all JWTs issued that records which user requested and which email in JWT, then they can retroactively check if they issued any (user, email) pair that they shouldn't have. Then they can assert that there was no misuse, if they only found this researcher's attempt.