5 ms·

> 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

> 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#IDToken https://openid.net/specs/openid-connect-core-1_0.html#IDToke...

thephyber 6y ago
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.
- SV_BubbleTime 6y ago
  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?
  - mazeltovvv 6y ago
    Ah. So this creates a valid JWT for any email you want, but it is now associated with your own apple account?
    - SV_BubbleTime 6y ago
      > 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
      - dodobirdlord 6y ago
        This is certainly logged.
  - thephyber 6y ago
    I don't have any way to confirm, but yes, this is what I interpreted from the article.
- dtech 6y ago
  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.
- fouc 6y ago
  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.
  - mehrdadn 6y ago
    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?
  - rags2riches 6y ago
    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.
    - amenod 6y ago
      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.
phamilton 6y ago
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.
- donmcronald 6y ago
  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.
- SV_BubbleTime 6y ago
  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.
  - phamilton 6y ago
    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.
    - SV_BubbleTime 6y ago
      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)
noctune 6y ago
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.
- dwaite 6y ago
  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.
  - sascha_sl 6y ago
    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.
derangedHorse 6y ago
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

thephyber 6y ago

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.

SV_BubbleTime 6y ago
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?
- mazeltovvv 6y ago
  Ah. So this creates a valid JWT for any email you want, but it is now associated with your own apple account?
  - SV_BubbleTime 6y ago
    > 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
    - dodobirdlord 6y ago
      This is certainly logged.
- thephyber 6y ago
  I don't have any way to confirm, but yes, this is what I interpreted from the article.
dtech 6y ago
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.
fouc 6y ago
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.
- mehrdadn 6y ago
  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?
- rags2riches 6y ago
  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.
  - amenod 6y ago
    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.

phamilton 6y ago

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.

donmcronald 6y ago
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.
SV_BubbleTime 6y ago
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.
- phamilton 6y ago
  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.
  - SV_BubbleTime 6y ago
    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)

noctune 6y ago

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.

dwaite 6y ago
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.
- sascha_sl 6y ago
  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.

derangedHorse 6y ago

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