Live data from Hacker News

Zero-day in Sign in with Apple

bhavukjain.com

181–190 of 280 posts

Re: Zero-day in Sign in with Apple

#181

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…

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 data…

The thing that made this bug possible was because, while your Apple ID has to be an email address, Apple has a mechanism to avoid exposing it to third parties - unlike Google, Apple, or Facebook's single sign-on implementation; the bug seems to be in the step between verifying your identity and telling Apple whether you would or would not like your email address to be exposed.

If anything, the issue is that third parties treat the email address as a unique, unchangeable identity, and then agree to rely on Apple's assertion of what your email address is. But given how hard identity is - and the challenges in dealing with passwords, account recovery, and name changes at scale - it's a pretty reasonable tradeoff to make.

Re: Zero-day in Sign in with Apple

#182
post #167

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

honestly I'm not surprised people didn't run into it during testing... you make a test email account and get a signin token for it. And then realize wait... how does apple know I own that email??

Re: Zero-day in Sign in with Apple

#183
post #43

" Apple also did an investigation of their logs and determined there was no misuse or account compromise due to this vulnerability. " Given the simplicity of the exploit, I really doubt that claim. Seems more likely they just don't have a way of detecting whether it happened.

I'd also like the exact wording of their claim. "There is no evidence of misuse or account compromise" is what I would expect them to say, as "There was no misuse or account compromise" likely opens them up to legal repercussions if that isn't 100% accurate.

Re: Zero-day in Sign in with Apple

#184
post #170

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.

frankly that's true of any silicon valley giant at this point.

Re: Zero-day in Sign in with Apple

#185

> The Sign in with Apple works similarly to OAuth 2.0. > similarly I understand why they wanted to modify OAuth 2.0, but departing from a spec is a very risky move. > $100,000 That was a good bounty. Appropriate given scope and impact. But it would have been a lot cheaper to offer a pre-release bounty program. We (Remind) occasionally add unreleased features to our bounty program with some extra incentive to explore…

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.

This might be what you're referring to:

From https://developer.apple.com/security-bounty/payouts/

"Issues that are unique to designated developer or public betas, including regressions, can result in a 50% additional bonus if the issues were previously unknown to Apple."

Re: Zero-day in Sign in with Apple

#186

Earlier quoted context omitted.

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.

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.

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.

Re: Zero-day in Sign in with Apple

#187
post #185

Earlier quoted context omitted.

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.

This might be what you're referring to: From https://developer.apple.com/security-bounty/payouts/ "Issues that are unique to designated developer or public betas, including regressions, can result in a 50% additional bonus if the issues were previously unknown to Apple."

Yes, that's it.

Re: Zero-day in Sign in with Apple

#188
(Unrelated to the Apple bug)

Is there any bug bounty program for small businesses/apps? I only found hackerone but it seems to be only for enterprise. Is there any recommended platform for small businesses to create their own public bounty program?

Re: Zero-day in Sign in with Apple

#189

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…

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 a…

Exactly, a case of broken security by overdoing privacy.

Re: Zero-day in Sign in with Apple

#190
post #181

Earlier quoted context omitted.

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 data…

The thing that made this bug possible was because, while your Apple ID has to be an email address, Apple has a mechanism to avoid exposing it to third parties - unlike Google, Apple, or Facebook's single sign-on implementation; the bug seems to be in the step between verifying your identity and telling Apple whether you would or would not like your email address to be exposed. If anything, the issue is that third par…

Sign in with facebook also lets the user choose whether or not to share their email address.
Post reply on HN