Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zero-day in Sign in with Apple

bhavukjain.com

Post reply on HN
Print view View original

201–210 of 280 posts

Re: Zero-day in Sign in with Apple

#201

Post by m_herrlich »

Ronnie76er wrote: post #158

Just want to mention something about the id_token provided. I'm on my phone, so I don't have apples implementation handy, but in OIDC, the relying party (Spotify for example) is supposed to use the id_token to verify the user that is authenticated, specifically the sub claim in the jwt id_token. https://openid.net/specs/openid-connect-core-1_0-final.html#... It's likely (although like others have noted, this is scant…

The apple endpoint returned an apple-signed jwt with an email of the attacker's choice in the sub field. It didn't even have to be an email associated with an apple id. Relying parties verify the id_token against Apple's cert and that is Apple's guarantee that the email is correct.

Re: Zero-day in Sign in with Apple

#202

Post by soonoutoftime »

ani-ani wrote: post #43

" 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.

Seems the only way to trust the companies in such situations is to exploit the vulnerabilities from multiple, unconnectable devices and locations, over as long a period as possible. If the company cannot list all of the attacks, you know they're bullshitting.

Re: Zero-day in Sign in with Apple

#203

Post by m_herrlich »

mazeltovvv wrote: post #144

This is an amazing bug, I am indeed surprised this happened in such a critical protocol. My guess is that nobody must have clearly specified the protocol, and anyone would have been able to catch that in an abstracted english spec. If this is not the issue, then the implementation might be too complex for people to compare it with the spec (gap between the theory and the practice). I would be extremely interested in…

It's exploitable through apple's web-based login flow used by web sites and Android devices. There are multiple round trips between the user and apple, and state is passed over the wire. The state could be modified at a certain point in the flow to cause the final result (the JWT) to be compromised. The flow is still the same, they seem to have fixed it entirely by adding checks server-side.

Re: Zero-day in Sign in with Apple

#204

Post by m_herrlich »

m_herrlich wrote: post #203
mazeltovvv wrote: post #144

This is an amazing bug, I am indeed surprised this happened in such a critical protocol. My guess is that nobody must have clearly specified the protocol, and anyone would have been able to catch that in an abstracted english spec. If this is not the issue, then the implementation might be too complex for people to compare it with the spec (gap between the theory and the practice). I would be extremely interested in…

It's exploitable through apple's web-based login flow used by web sites and Android devices. There are multiple round trips between the user and apple, and state is passed over the wire. The state could be modified at a certain point in the flow to cause the final result (the JWT) to be compromised. The flow is still the same, they seem to have fixed it entirely by adding checks server-side.

(sorry, WAS exploitable)

Re: Zero-day in Sign in with Apple

#205

Post by SV_BubbleTime »

phamilton wrote: post #186
SV_BubbleTime wrote: post #137

Earlier quoted context omitted.

Wait... I don’t get it. Why was Apple signing a response JWT when the user only supplied an email? I’m not a web guy so I just don’t see what they were going for here.

The gap is that Apple fully verified identity via the normal OAuth flow, and then once identiy was verified they give the use control over what email to include in the token. The idea is that the user can include their email or an apple relay email (that forwards to their email). The bug seems to be in that step, and an attacker can provide an email that is neither their own nor an apple relay email. Your apple accou…

That makes sense.

Seems little too obvious to exist, but people make mistakes.

It’s just that with JWT/JSE/JOSE already questionable security options that you would be extra super careful if you are using it. (Biggest flaw off the top of my head is it literally says what encryption is used with a NONE option meaning you can just switch to “none” and forge jwts to anyone that didn’t know not to accept those, second would be that they mix symmetric and asymmetric encryption options)

Re: Zero-day in Sign in with Apple

#206

Post by SV_BubbleTime »

mazeltovvv wrote: post #146
SV_BubbleTime wrote: post #138

Earlier quoted context omitted.

Oh. Ok, so you did have to have an existing logged in session for any account, then could leverage that to get the token for another account by changing out the email?

Ah. So this creates a valid JWT for any email you want, but it is now associated with your own apple account?

> but it is now associated with your own apple account?

On the backend, maybe they can look up who requested a token at a time.

But otherwise, no it doesn’t seem to be

Re: Zero-day in Sign in with Apple

#207

Post by nine_k »

soonoutoftime wrote: post #202
ani-ani wrote: post #43

" 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.

Seems the only way to trust the companies in such situations is to exploit the vulnerabilities from multiple, unconnectable devices and locations, over as long a period as possible. If the company cannot list all of the attacks, you know they're bullshitting.

I wonder if compromising your own account can be seen as unlawful. It's much like teenagers being found to break the law by making nude photos of themselves: they are found in possession of prohibited materials, even though they obtained them in a lawful way. Cracking your own account in a lawful way could possibly be done by a court order, but otherwise your actions are prohibited by law, even.though there cannot be a malicious intention.

Re: Zero-day in Sign in with Apple

#208

Post by [deleted] »

ani-ani wrote: post #43

" 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.

[deleted]

Re: Zero-day in Sign in with Apple

#209

Post by dwaite »

phamilton wrote: post #186
SV_BubbleTime wrote: post #137

Earlier quoted context omitted.

Wait... I don’t get it. Why was Apple signing a response JWT when the user only supplied an email? I’m not a web guy so I just don’t see what they were going for here.

The gap is that Apple fully verified identity via the normal OAuth flow, and then once identiy was verified they give the use control over what email to include in the token. The idea is that the user can include their email or an apple relay email (that forwards to their email). The bug seems to be in that step, and an attacker can provide an email that is neither their own nor an apple relay email. Your apple accou…

Apple deviated from OpenID Connect, but...

The third party is not supposed to link the information from an OpenID Connect client system by email address, which could change or go away at any time, and is also not guaranteed to be unique.

Rather, they should use the 'sub' claim which is meant to be the same over the lifetime of the user account with the issuer.

Re: Zero-day in Sign in with Apple

#210

Post by dwaite »

noctune wrote: post #93
zemnmez wrote: post #32

Earlier quoted context omitted.

> 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…

I think it's actually the OIDC access token and not the ID token. The OIDC spec does not mandate any structure for the access token, but letting it be a JWT isn't out-of-spec.

I do not believe that Apple yet uses the access token bit.

OAuth tokens also are not meant to be used for authentication, and require either a separate token (as OpenID Connect did) with appropriate security, or to wedge additional security on top of access tokens as Facebook did with Connect.

This is basically because access tokens are meant to be messages about allowed access to the API resources, not messages to the client software about the user.

Post reply on HN