4 ms·

> This bug could have resulted in a full account takeover of user accounts on that third party application irrespective of a victim having a valid Apple ID or n

> This bug could have resulted in a full account takeover of user accounts on that third party application irrespective of a victim having a valid Apple ID or not. The headline makes me think the entire problem lies with Apple, when that’s not the case.

saagarjha 6y ago
This seems very much like Apple’s bug, to the extent that they paid out a $100k bug bounty?
- jagged-chisel 6y ago
  Really? > ...affected third-party applications which were using it and didn’t implement their own additional security measures.
  - detaro 6y ago
    That there were ways of mitigating it (I'd assume verifying email addresses out of band?) doesn't mean it's not Apple's problem when their authentication system can be tricked to confirm false identities, when its entire purpose is confirming identities.
  - Kikawala 6y ago
    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.
    - dwaite 6y ago
      To be honest, I think the author is misrepresenting this, just as they falsely said that this was a "zero-day".
  - pquerna 6y ago
    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's "consent screen". Instead of using the email from the active logged in account, it allowed the attack to POST in any email they wanted. Obviously not having the bug would be great. Apple could do "more", and layer on more things on top of OAuth, like a proof of key extension (DPoP) on the flow: https://tools.ietf.org/html/draft-fett-oauth-dpop-04 https://tools.ietf.org/html/draft-fett-oauth-dpop-04 But if you have a bug like this, where you can edit your claims arbitrarily inside the IdP, extra security layers kinda don't matter.
    - dwaite 6y ago
      > 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.
  - aPoCoMiLogin 6y ago
    Apple is an email authority in this case, and as third party you have to rely on their security. Same as with ssl certificate authority.
lostmyoldone 6y ago
This one rests squarely on Apple, as it was their auth service that contained the bug. While an application could potentially (not that I know exactly how in this case) further verify the received token, that verification is exactly what an authentication service is supposed to provide, hence the responsibility absolutely rests on Apple who provides the service.

saagarjha 6y ago

This seems very much like Apple’s bug, to the extent that they paid out a $100k bug bounty?

jagged-chisel 6y ago
Really? > ...affected third-party applications which were using it and didn’t implement their own additional security measures.
- detaro 6y ago
  That there were ways of mitigating it (I'd assume verifying email addresses out of band?) doesn't mean it's not Apple's problem when their authentication system can be tricked to confirm false identities, when its entire purpose is confirming identities.
- Kikawala 6y ago
  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.
  - dwaite 6y ago
    To be honest, I think the author is misrepresenting this, just as they falsely said that this was a "zero-day".
- pquerna 6y ago
  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's "consent screen". Instead of using the email from the active logged in account, it allowed the attack to POST in any email they wanted. Obviously not having the bug would be great. Apple could do "more", and layer on more things on top of OAuth, like a proof of key extension (DPoP) on the flow: https://tools.ietf.org/html/draft-fett-oauth-dpop-04 https://tools.ietf.org/html/draft-fett-oauth-dpop-04 But if you have a bug like this, where you can edit your claims arbitrarily inside the IdP, extra security layers kinda don't matter.
  - dwaite 6y ago
    > 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.
- aPoCoMiLogin 6y ago
  Apple is an email authority in this case, and as third party you have to rely on their security. Same as with ssl certificate authority.

lostmyoldone 6y ago

This one rests squarely on Apple, as it was their auth service that contained the bug. While an application could potentially (not that I know exactly how in this case) further verify the received token, that verification is exactly what an authentication service is supposed to provide, hence the responsibility absolutely rests on Apple who provides the service.