Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zero-day in Sign in with Apple

bhavukjain.com

Post reply on HN
Print view View original

231–240 of 280 posts

Re: Zero-day in Sign in with Apple

#231

Post by aptwebapps »

ceejayoz wrote: post #230
aptwebapps wrote: post #228

Earlier quoted context omitted.

Totally not a lawyer here, but my impression of laws like CFAA is that it revolves around unauthorized access of resources. If the only resources you access are those for which you have authorization, you might be all right. After edit: "you might be all right." was a poor choice of words. If you piss off the wrong people, you won't be all right.

Aaron Swartz would likely beg to differ.

Added an after edit. I don't mean to say "you'll be fine, go ahead." But Swartz's case was a bit different that the hypothetical described above.

Re: Zero-day in Sign in with Apple

#232

Post by IncRnd »

phamilton wrote: post #183
ani-ani wrote: 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.

Exactly. Lack of evidence is not evidence of lack.

Re: Zero-day in Sign in with Apple

#233

Post by harpratap »

alwillis wrote: post #191
harpratap wrote: post #88

Earlier quoted context omitted.

> Even in the United States, Apple isn’t a monopoly with about 40% market share. This is a non argument. A Duopoly is no reason to not being able to behave like a monopoly. If you don't play by Apple's or Google's rules you essentially lose 50% of the market.

Monopolies aren’t illegal; it’s the use of monopoly power in corrupt ways that’s illegal. I suspect if you don’t want to deal with Apple or Google directly, you can create web apps.

By the same logic, if you didn't want to use Internet Explorer you could use Fax or Mail?

> Monopolies aren’t illegal; it’s the use of monopoly power in corrupt ways that’s illegal.

That is exactly my point. You don't technically a monopoly to abuse your power in corrupt ways. A duopoly is good enough to abuse your dominant position towards the deteriment of users and the market.

Re: Zero-day in Sign in with Apple

#234

Post by rags2riches »

fouc wrote: post #221
thephyber wrote: post #72

Earlier quoted context omitted.

The important part is in the author’s article. The POST to the opened endpoint generates a valid JWT token for the email address in the payload, not for the one in the logged-in session. Everything else is extraneous.

Oh man, that is classic sloppy web development. It's often so easy to reach for the values in the params/payload first because you're already working with them, instead of remembering to use the session values instead. This would be a great audit to do for entire codebases.. Just check all places that are using params/payload values and see if there's actually already a session value that should be used instead.

Don't just audit. Strengthen the critical APIs with types. A user provided string is not the same type as an authentic identity. Make the developer be explicit about the critical mistake about to be made. Perl had this down decades ago with the tainted checks.

Re: Zero-day in Sign in with Apple

#236

Post by hirsin »

dwaite wrote: post #209
phamilton wrote: post #186

Earlier quoted context omitted.

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

Apple deviated from OpenID Connect, but... The third party is not supposed to link the information from an OpenID Connect client system by email address, which could change or go away at any time, and is also not guaranteed to be unique. Rather, they should use the 'sub' claim which is meant to be the same over the lifetime of the user account with the issuer.

Yup, this is it. It's a super common issue though, and we see it all the time. An app expected the email of a user to be static and keys off of it. User gets married and loses their code access.

At best it's a work stoppage when someone changes their email. At worst you make assumptions about reusability of emails and give data access to the wrong account.

Re: Zero-day in Sign in with Apple

#237

Post by PunksATawnyFill »

PunksATawnyFill wrote: post #179
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…

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…

Love how some cowardly Apple apologists modded this down with no excuse. Pathetic.

Re: Zero-day in Sign in with Apple

#238

Post by PunksATawnyFill »

ath0 wrote: post #181
PunksATawnyFill wrote: post #179

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…

The point wasn’t that the address is exposed by Apple; it’s that E-mail addresses are widely exposed by USERS, out of necessity.

Re: Zero-day in Sign in with Apple

#239

Post by zelphirkalt »

fulldecent2 wrote: post #227
tyrion wrote: post #74

How is this something that can happen? I mean, the only responsibility of an "authentication" endpoint is to release a JWT authenticating the current user. At least from the writeup, the bug seems so simple that it is unbelievable that it could have passes a code review and testing. I suspect things were maybe not as simple as explained here, otherwise this is at the same incompetence level as storing passwords in pl…

I found a customer data leak on their homepage. Took about two years to fix. Gave me credit. No money. I'm not surprised here.

They exploited you just like their customers, from whom they take money for overpriced lock-in products.
Post reply on HN