Zero-day in Sign in with Apple • Hacker News Board

Re: Zero-day in Sign in with Apple

#161

Post by alphaomegacode » Sat, May 30, 2020, 8:44 PM UTC

TheSpiceIsLife wrote: post #104

ksec wrote: post #100

Earlier quoted context omitted.

I used to be on the latest and security camp as well. But after all these years I am starting to understand why people dont update. It is extremely frustrating. Especially when Catalina removes features that were working perfectly.

I’m still on High Sierra, most recent 10.13.6 security update was ~3 days ago. I’ll upgrade when some piece of software I need to use requires it.

As an Apple user for decades, have to say that High Sierra seemed to be one of their better recent releases.

I have an iMac that uses it and a Mac Mini that is on Mojave and for some reason, High Sierra just feels more stable with some software.

Firefox runs fine on High Sierra and has crashed multiple times in the past few weeks after using it on Mojave.

Maybe I'm just biased having used High Sierra for so long and dreading Catalina lol.

Re: Zero-day in Sign in with Apple

#162

Post by capableweb » Sat, May 30, 2020, 8:49 PM UTC

danans wrote: post #149

This is why it's good to run fuzzers against any public API (especially an auth API), to verify its behavior on novel inputs. https://en.m.wikipedia.org/wiki/Fuzzing

In general I agree with you that it's good to run fuzzers against any endpoints, public or internal (as you never know if someone can wrangle data to go from public -> internal somehow), but in this particular case, you'd only find a issue if the fuzzer somehow randomly used the ID of another user that was already created, and verified that it couldn't access it.

In that case, you'd catch it way before even implementing the fuzzer.

So in this case, I don't think a fuzzer would have helped. Some E2E tests written by humans should have caught this though.

Re: Zero-day in Sign in with Apple

#163

Post by caseysoftware » Sat, May 30, 2020, 8:55 PM UTC

mlthoughts2018 wrote: post #148

rubyn00bie wrote: post #135

Earlier quoted context omitted.

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.

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?

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

Re: Zero-day in Sign in with Apple

#164

Post by driverdan » Sat, May 30, 2020, 8:56 PM UTC

cfors wrote: post #49

Wow. That's almost inexcusable, especially due to the requirement of forcing iOS apps to implement this. If they didn't extend the window (from originally April 2020 -> July 2020) so many more apps would have been totally exploitable from this. After this, they should remove the requirement of Apple Sign in. How do you require an app to implement this with such a ridiculous zero day?

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

Re: Zero-day in Sign in with Apple

#165

Post by alexashka » Sat, May 30, 2020, 9:12 PM UTC

What level of incompetence will it take for the government to step in and create some laws surrounding companies exposing user's private data because 'oops, we don't want to pay security experts what they're actually worth, even though we have billons sitting in bank accounts doing nothing'.

Re: Zero-day in Sign in with Apple

#166

Post by danans » Sat, May 30, 2020, 9:14 PM UTC

capableweb wrote: post #162

danans wrote: post #149

This is why it's good to run fuzzers against any public API (especially an auth API), to verify its behavior on novel inputs. https://en.m.wikipedia.org/wiki/Fuzzing

In general I agree with you that it's good to run fuzzers against any endpoints, public or internal (as you never know if someone can wrangle data to go from public -> internal somehow), but in this particular case, you'd only find a issue if the fuzzer somehow randomly used the ID of another user that was already created, and verified that it couldn't access it. In that case, you'd catch it way before even implement…

There's no reason that a fuzzer couldn't draw sample email addresses from a large pool of test valid email addresses to add as input. That would just require a fuzzer that allowed you to provide the sample population for a particular data type.

Re: Zero-day in Sign in with Apple

#167

Post by hank_z » Sat, May 30, 2020, 9:17 PM UTC

Wow, this bug is incredibly simple but severe. I’m wondering how did Bhavuk Jain find it

Re: Zero-day in Sign in with Apple

#168

Post by afrcnc » Sat, May 30, 2020, 9:19 PM UTC

Replace "zero-day" with "privately reported security bug for which I got $100k"

That's not how zero-day works

Re: Zero-day in Sign in with Apple

#169

Post by guessmyname » Sat, May 30, 2020, 9:20 PM UTC

mazeltovvv wrote: post #144

This is an amazing bug, I am indeed surprised this happened in such a critical protocol. My guess is that nobody must have clearly specified the protocol, and anyone would have been able to catch that in an abstracted english spec. If this is not the issue, then the implementation might be too complex for people to compare it with the spec (gap between the theory and the practice). I would be extremely interested in…

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

Re: Zero-day in Sign in with Apple

#170

Post by tpmx » Sat, May 30, 2020, 9:26 PM UTC

planetjones wrote: post #154

Absolutely astonishing. The internal controls at Apple seem to be borderline non existent.

The average IQ and experience of their software developers has dropped remarkably over the past decade, as they have expanded.

I've had multiple occasions of "Seriously, Apple hired person X? lol" over the past five years or so.