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

131–140 of 280 posts

Re: Zero-day in Sign in with Apple

#131

Post by WhyNotHugo »

oauea wrote: post #17

Wow, I'm so glad that apple forced me to implement this broken garbage into my apps! For those not aware, some time ago apple decided it would be a good idea to develop their own sing in system, and then force all apps on their store (that already support e.g. Google Account login) to implement it. So they brought a huge amount of additional complexity in a large amount of apps, and then they fucked up security. Than…

Actually, developers are only forced to implement it _if_ they support logging in with other social auths.

A big problem of many apps is that they only had a "log in with google"/"log in with facebook" button, which is very problematic for people who have neither.

On Android this is more acceptable since you need a Google account for the OS itself anyway.

Re: Zero-day in Sign in with Apple

#132

Post by tly_alex »

The write-up is not very clear in my opinion. The graph seems to show that there're 3 API calls (maybe there're more API calls in reality?).

And if I understand this correctly, the issue is in the first API call, where the server does not validate whether the requester owns the Email address in the request.

What confuses me are where're the "decoded JWT’s payload" comes from. Is it coming from a different API call or it's somewhere in the response?

Re: Zero-day in Sign in with Apple

#133

Post by tly_alex »

tly_alex wrote: post #132

The write-up is not very clear in my opinion. The graph seems to show that there're 3 API calls (maybe there're more API calls in reality?). And if I understand this correctly, the issue is in the first API call, where the server does not validate whether the requester owns the Email address in the request. What confuses me are where're the "decoded JWT’s payload" comes from. Is it coming from a different API call or…

And the choice of black arrow on top of an almost black background... I am not a designer but that's just killing my eyes here.

Re: Zero-day in Sign in with Apple

#134

Post by tpush »

matchbok wrote: post #84
NicoJuicy wrote: post #30

Perhaps slightly related that finding Apple zero days was less bounty award than finding Android zero days. I think we can wrap up the security and anonymous part that Apple has been claiming for their overpriced devices.

Overpriced? The average android phones cost the same as iPhone. That argument is tried and not relevant anymore. Plus, iPhones actually work longer than a year.

> The average android phones cost the same as iPhone.

They don't.

Re: Zero-day in Sign in with Apple

#135

Post by rubyn00bie »

mlthoughts2018 wrote: post #116
drivebycomment wrote: post #80

Earlier quoted context omitted.

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.

How could you prove the user was the correct user in any given case?

They very like have a complete log of the action performed; I'd guess, they'd perform some kind of replay/playback after the bug was fixed, and see what failed to pass. Assuming their changes immediately flag things like the researcher's initial attempts and discovery, it'd probably be pretty safe to say that no one was affected if no other instances are flagged.

Re: Zero-day in Sign in with Apple

#136

Post by donmcronald »

phamilton wrote: post #82
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…

My understanding is that the token itself is fine and within spec. But they altered the flow to accept an email address in one of the request payloads which opened the door for spoofing the email address. I've never seen an OAuth or OpenID flow that relied on the payload for identity.

This is likely it IMO. They probably pass the preferred email around as a parameter and the user can jump into the flow and modify it.

Re: Zero-day in Sign in with Apple

#137

Post by SV_BubbleTime »

phamilton wrote: post #82
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…

My understanding is that the token itself is fine and within spec. But they altered the flow to accept an email address in one of the request payloads which opened the door for spoofing the email address. I've never seen an OAuth or OpenID flow that relied on the payload for identity.

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.

Re: Zero-day in Sign in with Apple

#138

Post by SV_BubbleTime »

thephyber wrote: post #72
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…

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.

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?

Re: Zero-day in Sign in with Apple

#140

Post by drivebycomment »

mlthoughts2018 wrote: post #116
drivebycomment wrote: post #80

Earlier quoted context omitted.

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.

How could you prove the user was the correct user in any given case?

I can think of two possible "root causes" with this vulnerability.

One is where the API ("2nd step" mentioned in the doc, POST with a desired email address to get a JWT) is an authenticated API, meaning it requires a valid credential, but Apple's implementation of this API made a mistake of not checking if the user-requested email belongs to the user or not. In this case, the log can give enough information for the forensic analysis to determine misuse. I presumed this was the case.

The other possibility is if they implemented that API as unauthenticated. I presumed this was not the case - as this is a more difficult mistake to make, and given that they claimed some knowledge of no misuse - but I have no way to know for sure this isn't the case here. The end result would be the same. If the root cause was this case, indeed it's difficult to know if no misuse has happened.

Post reply on HN