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.

I agree, especially given how many developer “eyes” were on this from having to integrate the log in with Apple flow into their apps.

Just as a first-hand anecdote to back this up, a dev at my former company which did a mix of software dev and security consulting found a much more complex security issue with Apple Pay within the first hour of starting to implement the feature for a client and engaging with the relevant docs.

How did no one else notice this? The only thing I can think of is the “hidden in plain sight” thing? Or maybe the redacted URL endpoint here was not obvious?

It depends what the fix was. If the fix was just to add a validation check to the POST endpoint to validate that the logged in user session matched the payload (and session data was comprehensively logged/stored), this may be verifiable.

There are obviously lots hypotheticals for which this might not be verifiable.

Yeah, doesn't this just mean they didn't detect misuse?

The bug is not in the protocol. The bug is about the extra value addition that apple was doing by letting the user choose any other email address. 1. The account take over happens on the third party sites that use the apple login. 2. This seems like a product request to add value to user by providing a relay email address of a user's choice. From the report- `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.`

It's not a bug with protocol or security algorithm. A lock by itself does not provides any security if its not put in the right place.

For #3 it's part of the JWT ID Token. Take a look at https://openid.net/specs/openid-connect-core-1_0.html#Hybrid...

All your questions can be answered by reading “Sign in with Apple REST API” [1][2]:

1. User clicks or touches the “Sign in with Apple” button

2. App or website redirects the user to Apple’s authentication service with some information in the URL including the application ID (aka. OAuth Client ID), Redirect URL, scopes (aka. permissions) and an optional state parameter

3. User types their username and password and if correct Apple redirects them back to the “Redirect URL” with an identity token, authorization code, and user identifier to your app

4. The identity token is a JSON Web Token (JWT) and contains the following claims:

• iss: The issuer-registered claim key, which has the value https://appleid.apple.com.

• sub: The unique identifier for the user.

• aud: Your client_id in your Apple Developer account.

• exp: The expiry time for the token. This value is typically set to five minutes.

• iat: The time the token was issued.

• nonce: A String value used to associate a client session and an ID token. This value is used to mitigate replay attacks and is present only if passed during the authorization request.

• nonce_supported: A Boolean value that indicates whether the transaction is on a nonce-supported platform. If you sent a nonce in the authorization request but do not see the nonce claim in the ID token, check this claim to determine how to proceed. If this claim returns true you should treat nonce as mandatory and fail the transaction; otherwise, you can proceed treating the nonce as optional.

• email: The user's email address.

• email_verified: A Boolean value that indicates whether the service has verified the email. The value of this claim is always true because the servers only return verified email addresses.

• c_hash: Required when using the Hybrid Flow. Code hash value is the base64url encoding of the left-most half of the hash of the octets of the ASCII representation of the code value, where the hash algorithm used is the hash algorithm used in the alg Header Parameter of the ID Token's JOSE Header. For instance, if the alg is HS512, hash the code value with SHA-512, then take the left-most 256 bits and base64url encode them. The c_hash value is a case sensitive string

[1] https://developer.apple.com/documentation/sign_in_with_apple...

[2] https://developer.apple.com/documentation/sign_in_with_apple...

Let's start with the fact that Apple is forcing people to use an E-mail address as a user ID. That's just straight-up stupid.

How many members of the public think that they have to use their E-mail account password as their password for Apple ID and every other amateur-hour site that enforces this dumb rule?

MILLIONS. I would bet a decent amount of money on it. So if any one of these sites is hacked and the user database is compromised, all of the user's Web log-ins that have this policy are wide open.

Then there's the simple fact that everyone's E-mail address is on thousands of spammers' lists. A simple brute-force attack using the top 100 passwords is also going to yield quite a trove, I'd imagine.

Apple IDs didn't originally have to be E-mail addresses. They're going backward.

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

Apple supposedly marks certain beta builds with a bounty multiplier. I say supposedly because like their "research iPhones" they mentioned it in a presentation once and I never heard about it again.

Apple has had more simple "unbelievable" bugs, e.g

https://news.ycombinator.com/item?id=15800676 (Anyone can login as root without any technical effort required)

And to top it off (https://news.ycombinator.com/item?id=15828767)

Apple keeps having all sorts of very simple "unbelievable" bugs.

Apple has really lost their touch, software quality has declined dramatically

My guess is that it has to do with that private relay because OAuth isn't too complex by itself. During the OAuth flow they probably collect the user preference, (if needed) go out to the relay service and get a generated email, and POST back to their own service with the preferred email to use in the token.

If that's it, it's about as bad as doing password authentication in JavaScript and passing authenticated=true as a request parameter.

Edit: Looking at the OAuth picture in the article, my guess would be like adding a step in between 1 and 2 where the server says "what email address do you want here" and the (client on the) user side is responsible for interacting with the email relay service and posting back with a preferred email address. Or the server does it but POSTS back to the same endpoint which means the user could just include whatever they want right from the start.

The only thing that makes me think I might not be right is that doing it like that is just way too dumb.

AND I'm guessing a bunch of Apple services probably use OAuth amongst themselves, so this might be the worst authentication bug of the decade. The $100k is a nice payday for the researcher, but I bet the scope of the damage that could have been done was MASSIVE.

Edit 2: I still don't understand why the token wouldn't mainly be linked to a subject that's a user id. Isn't 'sub' the main identifier in a JWT? Maybe it's just been too long and I don't remember right.

The only thing I can think of is some 'test mode' override which inadvertently got enabled in production.

1. Don't add these.

2. If you must add something, structure it so it can only exist in test-only binaries.

3. If you really really need to add a 'must not enable in prod' flag then you must also continuously monitor prod to ensure that it is not enabled.

Really hoping they follow up with a root-cause explanation.

I’m of the mind that just about any security bug is “excusable” if it passed a good faith effort by a qualified security audit team and the development process is in place to minimize such incidents.

The problem I have is that I can’t tell what their processes are beyond the generic wording on this page[1]

[1] support.apple.com/guide/security/introduction-seccd5016d31/web

> That's almost inexcusable

No, it's completely inexcusable. There should never be such a simple, major security vulnerability like this. Overlooking something this basic is incompetence.

I believe the deadline is June 30. [0]

[0] - https://developer.apple.com/news/?id=03262020b

I think the write up is so short because the bug is so simple. Send a POST to appleid.apple.com with an email address of your choice, and get back an auth token for that user. Use the auth token to log-in as that user. It's that simple.

It seems low on details because the exploit was incredibly simple. AFAICT you didn't have to do anything special to get the signed token, they just gave it out.

> Here on passing any email, Apple generated a valid JWT (id_token) for that particular Email ID.

it's literally that simple.

So the way I believe that it works is that the vulnerability was that a valid email is used to generate an Apple signed JWT. The server side validation would be unable to tell that the token wasn’t issued in behalf of the user since Apple actually signed it.