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

211–220 of 280 posts

Re: Zero-day in Sign in with Apple

#211

Post by dwaite »

TheSpiceIsLife wrote: post #150
lowdose wrote: post #120

Earlier quoted context omitted.

I went to Mojave and that went without trouble except I lost the ability to use my external GPU, but I knew that.

Mojave removed Facebook, Twitter, Vimeo, and Flickr, integrations, none of which I use, so that would be good. But I’m not aware of any new feature in Mojave I want or need, so the 2013 MacBook Pro Retina I’m using will stay on High Sierra for today :)

FWIW, they added the ability for these companies to control their own integrations by publishing iOS and Mac apps.

It's just that so far, only Twitter has bothered to do so on Mac. Even software like Slack which does so for iOS just hasn't bothered to port that code to their Mac app - most likely because of the Mac app using a different Electron-based codebase.

Re: Zero-day in Sign in with Apple

#212

Post by DethNinja »

tyrion wrote: post #74

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

This is basically bad coding, I never used OAuth system but you are supposed to just validate token, not any additional incoming data as number one rule of distributed systems is “never trust the client”.

They basically made a huge fundamental design mistake.

Re: Zero-day in Sign in with Apple

#213

Post by dwaite »

donmcronald wrote: post #129
tyrion wrote: post #74

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

My guess is that it has to do with that private relay because OAuth isn't too complex by itself. During the OAuth flow they probably collect the user preference, (if needed) go out to the relay service and get a generated email, and POST back to their own service with the preferred email to use in the token. If that's it, it's about as bad as doing password authentication in JavaScript and passing authenticated=true…

> Edit 2: I still don't understand why the token wouldn't mainly be linked to a subject that's a user id. Isn't 'sub' the main identifier in a JWT? Maybe it's just been too long and I don't remember right.

The details are very sparse in the post, but I believe the "sub" claim is a unique and stable value for the user against a particular relying party (based on that being a requirement in OpenID Connect.)

You _should_ be relying on sub rather than email address, which is not guaranteed to be sent every time, to stay stable, or be unique across accounts.

So while this was a zero day in terms of providing arbitrary email addresses as verified addresses, it may have not led to any account compromises.

Re: Zero-day in Sign in with Apple

#214

Post by dwaite »

gruez wrote: post #38

Is it me or is this writeup low on details? There are a couple of commenters saying that this is a great writeup, but all it amounts to is: 1. what sign in with apple is 2. sign in with apple is like oauth2 3. there's some bug (not explained) that allows JWTs to be generated for arbitrary emails 4. this bug is bad because you can impersonate anyone with it 5. I got paid $100k for it

Based on the information given, I don't know if you can really impersonate people. Rather, you can give an arbitrary email address and have it represented as valid, _against your account_.

You need an additional bug on the relying party for this to allow someone to gain access - that they associate the apple account based on the unstable email address claim rather than the stable "sub" claim.

Re: Zero-day in Sign in with Apple

#215

Post by dwaite »

m_herrlich wrote: post #201
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.

the sub field does not contain an email address in SiwA.

Re: Zero-day in Sign in with Apple

#216

Post by dwaite »

cfors wrote: post #193
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…

So the way I believe that it works is that the vulnerability was that a valid email is used to generate an Apple signed JWT. The server side validation would be unable to tell that the token wasn’t issued in behalf of the user since Apple actually signed it.

the SiwA identification is based on "sub", email address is an important address but you aren't supposed to link accounts based on it since the user can change the email address or revoke email proxy at any time.

Re: Zero-day in Sign in with Apple

#217

Post by dwaite »

pquerna wrote: post #14
jagged-chisel wrote: post #7

Earlier quoted context omitted.

Really? > ...affected third-party applications which were using it and didn’t implement their own additional security measures.

This allowed you to forge an attestation of user identity from Apple for any App that was setup to consume it. Apple is acting as an IdP for its consumer ecosystem. It's definitely their problem. Third-party applications really have no recourse but to trust the signed JWT. That is just how OAuth2/OIDC works. User impersonation against an IdP is a serious security issue. 100k is cheap. The bug was basically on the IdP…

> This allowed you to forge an attestation of user identity from Apple for any App that was setup to consume it. Apple is acting as an IdP for its consumer ecosystem. It's definitely their problem.

The relying party would have to incorrectly rely on the 'email' claim, which is not guaranteed to be sent, stable, or unique, rather than the "sub" claim as documented.

This shouldn't be an account takeover problem unless your site did that or one of a few other things wrong. However, I'd be reluctant to blame the site in those cases - a lot of security issues (including this one on Apple's side) come from two components not fully understanding the contract between them.

Re: Zero-day in Sign in with Apple

#218

Post by dwaite »

Kikawala wrote: post #11
jagged-chisel wrote: post #7

Earlier quoted context omitted.

Really? > ...affected third-party applications which were using it and didn’t implement their own additional security measures.

Is everyone in this thread only going to read the first two paragraphs of the article and skip the rest of it? > 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.

To be honest, I think the author is misrepresenting this, just as they falsely said that this was a "zero-day".

Re: Zero-day in Sign in with Apple

#219

Post by catlifeonmars »

It’s unclear to me exactly where the vulnerability is given the authors description in “technical details”. Does this occur in the implicit flow as well as the code flow? Is the token request unauthenticated? This seems highly unlikely. Or does Sign In With Apple deviate from the Open ID specification in a way that I’m unfamiliar with?

Re: Zero-day in Sign in with Apple

#220

Post by gouggoug »

catlifeonmars wrote: post #219

It’s unclear to me exactly where the vulnerability is given the authors description in “technical details”. Does this occur in the implicit flow as well as the code flow? Is the token request unauthenticated? This seems highly unlikely. Or does Sign In With Apple deviate from the Open ID specification in a way that I’m unfamiliar with?

The author found out that the HTTP endpoint used to generate a JWT token would accept any email and respond with a valid JWT token for that email address.

He could literally send a POST request to that endpoint with arbitrary email addresses and get a valid JWT.

This is clearly explained under the "BUG" section.

Post reply on HN