3 ms·

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 an

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.

mlthoughts2018 6y ago
How could you prove the user was the correct user in any given case?
- rubyn00bie 6y ago
  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.
  - mlthoughts2018 6y ago
    How does that answer the question? So what if you can replay logs of all attempts? How can you prove for any specific log that it was the “real” user making the request, and not someone using their email maliciously to make an identical request?
    - caseysoftware 6y ago
      It doesn't. That's also the downside of most login/identity providers that implement some form of "Impersonation." Without really smart and well-considered limitations and logging, it's impossible to tell the User from the User* without digging through audit trails, etc.. and if the developers/architects involved didn't consider the limitations and logging in the first place, odds are they didn't consider the audit trails either. And yes, I do this for a living.. and have seen bad things from major organizations. :(
- drivebycomment 6y ago
  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.
- tedunangst 6y ago
  Assume they have two log entries. request 678: request from user bananas request 678: issued token for bananas That looks good. request 987: request from user <blank> request 987: issues token for carrots That doesn't look good.
- jiveturkey 6y ago
  They are the issuer. it's trivial.

mlthoughts2018 6y ago

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

rubyn00bie 6y ago
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.
- mlthoughts2018 6y ago
  How does that answer the question? So what if you can replay logs of all attempts? How can you prove for any specific log that it was the “real” user making the request, and not someone using their email maliciously to make an identical request?
  - caseysoftware 6y ago
    It doesn't. That's also the downside of most login/identity providers that implement some form of "Impersonation." Without really smart and well-considered limitations and logging, it's impossible to tell the User from the User* without digging through audit trails, etc.. and if the developers/architects involved didn't consider the limitations and logging in the first place, odds are they didn't consider the audit trails either. And yes, I do this for a living.. and have seen bad things from major organizations. :(
drivebycomment 6y ago
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.
tedunangst 6y ago
Assume they have two log entries. request 678: request from user bananas request 678: issued token for bananas That looks good. request 987: request from user <blank> request 987: issues token for carrots That doesn't look good.
jiveturkey 6y ago
They are the issuer. it's trivial.