Zero-day in Sign in with Apple • Hacker News Board

Re: Zero-day in Sign in with Apple

#221

Post by fouc » Sun, May 31, 2020, 3:29 AM UTC

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 man, that is classic sloppy web development.

It's often so easy to reach for the values in the params/payload first because you're already working with them, instead of remembering to use the session values instead.

This would be a great audit to do for entire codebases.. Just check all places that are using params/payload values and see if there's actually already a session value that should be used instead.

Re: Zero-day in Sign in with Apple

#222

Post by catlifeonmars » Sun, May 31, 2020, 3:33 AM UTC

SV_BubbleTime wrote: post #205

phamilton wrote: post #186

Earlier quoted context omitted.

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

I noticed after reading your comment that HS256 is marked as “required” for compliant implantations. In practice, I have only ever seen signers implement RS256 though...

Re: Zero-day in Sign in with Apple

#223

Post by dodobirdlord » Sun, May 31, 2020, 3:36 AM UTC

SV_BubbleTime wrote: post #206

mazeltovvv wrote: post #146

Earlier quoted context omitted.

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

This is certainly logged.

Re: Zero-day in Sign in with Apple

#224

Post by catlifeonmars » Sun, May 31, 2020, 3:38 AM UTC

gouggoug wrote: post #220

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.

That part I understand. It’s unclear to me in which auth endpoint(s) and auth flow(s) are affected. Is it the token endpoint, or auth endpoint? Or is it somewhere in the login flow before the user agent is redirected to the token endpoint?

Re: Zero-day in Sign in with Apple

#225

Post by justapassenger » Sun, May 31, 2020, 3:52 AM UTC

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.

It’s no secret that Apple isn’t great at webservices and they have strong initiative not to keep user data. I could imagine a world where they just didn’t have enough logs to properly investigate and validate it.

Re: Zero-day in Sign in with Apple

#226

Post by mehrdadn » Sun, May 31, 2020, 4:04 AM UTC

fouc wrote: post #221

thephyber wrote: post #72

Earlier quoted context omitted.

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 man, that is classic sloppy web development. It's often so easy to reach for the values in the params/payload first because you're already working with them, instead of remembering to use the session values instead. This would be a great audit to do for entire codebases.. Just check all places that are using params/payload values and see if there's actually already a session value that should be used instead.

I wonder if encoding the query params with some dumb encoding (maybe a custom variant of base64?) and forcing decoding at every usage site would make it inconvenient enough to cause programmers to use the session values instead?

Re: Zero-day in Sign in with Apple

#227

Post by fulldecent2 » Sun, May 31, 2020, 4:05 AM UTC

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…

I found a customer data leak on their homepage.

Took about two years to fix. Gave me credit. No money.

I'm not surprised here.

Re: Zero-day in Sign in with Apple

#228

Post by aptwebapps » Sun, May 31, 2020, 4:15 AM UTC

nine_k wrote: post #207

soonoutoftime wrote: post #202

Earlier quoted context omitted.

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…

Totally not a lawyer here, but my impression of laws like CFAA is that it revolves around unauthorized access of resources. If the only resources you access are those for which you have authorization, you might be all right.

After edit: "you might be all right." was a poor choice of words. If you piss off the wrong people, you won't be all right.

Re: Zero-day in Sign in with Apple

#229

Post by dang » Sun, May 31, 2020, 4:59 AM UTC

Lammy wrote: post #20

lotsofpulp wrote: post #3

Earlier quoted context omitted.

But for some reason I have never had to remove malware from my parents’ iOS or macOS devices.

[flagged]

Please read and follow the site guidelines. You broke at least two of them there.

https://news.ycombinator.com/newsguidelines.html

Re: Zero-day in Sign in with Apple

#230

Post by ceejayoz » Sun, May 31, 2020, 5:05 AM UTC

aptwebapps wrote: post #228

nine_k wrote: post #207

Earlier quoted context omitted.

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…

Totally not a lawyer here, but my impression of laws like CFAA is that it revolves around unauthorized access of resources. If the only resources you access are those for which you have authorization, you might be all right. After edit: "you might be all right." was a poor choice of words. If you piss off the wrong people, you won't be all right.

Aaron Swartz would likely beg to differ.