Hacker News Reader

Comment by zemnmez | Hacker News Reader

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

https://openid.net/specs/openid-connect-core-1_0.html#IDToke...

View on HN

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.

Don't just audit. Strengthen the critical APIs with types. A user provided string is not the same type as an authentic identity. Make the developer be explicit about the critical mistake about to be made. Perl had this down decades ago with the tainted checks.

This, thousand times. Don't just fix the bug, fix the process that led to the bug. Developers are (usually) not malicious, but we are often working with tooling which makes mistakes easy to do, difficult to detect and grave in consequences. Fix the tooling, not just the bug.

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?

That also explains why Apple could exclude abuse happening in the logs, which some commenters have refuted.

If they have all the JWTs, seeing if one had a different e-mail than the logged-in user should be fairly doable.

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

This is certainly logged.

I don't have any way to confirm, but yes, this is what I interpreted from the article.

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.

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 account is safe, but if a 3rd party trusts the signed apple payload without further verification of email, an attacker could sign in as you on the 3rd party app.

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.

Yup, this is it. It's a super common issue though, and we see it all the time. An app expected the email of a user to be static and keys off of it. User gets married and loses their code access.

At best it's a work stoppage when someone changes their email. At worst you make assumptions about reusability of emails and give data access to the wrong account.

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)

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

In OIDC you can actually specificy supported key types in the discovery process and the IdP always decides the key type anyway.

HS256 relies in shared secrets, so anyone who can verify a token can also change it. RS256 allows you to download the IdP keychain every once in a while and verify tokens offline.

Yes, that’s what I meant. I only see RS256 implemented by identity providers (and advertised via .well-known/openid-configuration). This makes sense, since most identity providers are decoupled from their clients and thus cannot feasibly share a symmetric key. I am confused what is meant in the JWA specification[1] by “HS256: required” under “implementation requirements” in the table of allowed values (the entry for RS256 reads “recommended” for that column).

[1]: https://tools.ietf.org/html/rfc7518#section-3.1

There is no endpoint in the OIDC spec that allows token creation aside from the redirect after login (implicit flow) and the token endpoint though. I don't imagine this vulnerability could've happened at either endpoint, but I could be wrong. I'll definitely be looking into how Apple implements things before I use their login for any of my own applications

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.

A few popular IdPs (e.g. keycloak) have no but semantic difference in access and ID tokens, they're both signed JWTs (EC/RSA or shudder HMAC shared secrets) with different typ fields.

Reply on news.ycombinator.com