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

Re: Zero-day in Sign in with Apple

#191

Post by alwillis » Sat, May 30, 2020, 10:51 PM UTC

harpratap wrote: post #88

alwillis wrote: post #36

Earlier quoted context omitted.

I'm still surprised that this didn't trigger an antitrust investigation like when Microsoft abused their monopoly to push internet explorer. This is exactly the same thing, if not worse. Um… no. Microsoft gave Internet Explorer away for free when Netscape was selling their browser to businesses, an obvious attempt to undermine Netscape. They also threatened to cancel the Windows 95 licenses for companies like HP that…

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

Re: Zero-day in Sign in with Apple

#192

Post by thephyber » Sat, May 30, 2020, 11:05 PM UTC

SV_BubbleTime wrote: post #138

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. Ok, so you did have to have an existing logged in session for any account, then could leverage that to get the token for another account by changing out the email?

I don't have any way to confirm, but yes, this is what I interpreted from the article.

Re: Zero-day in Sign in with Apple

#193

Post by cfors » Sat, May 30, 2020, 11:35 PM UTC

Ronnie76er wrote: post #158

Just want to mention something about the id_token provided. I'm on my phone, so I don't have apples implementation handy, but in OIDC, the relying party (Spotify for example) is supposed to use the id_token to verify the user that is authenticated, specifically the sub claim in the jwt id_token. https://openid.net/specs/openid-connect-core-1_0-final.html#... It's likely (although like others have noted, this is scant…

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.

Re: Zero-day in Sign in with Apple

#194

Post by jedberg » Sat, May 30, 2020, 11:39 PM UTC

What a click-bait title. 0-day implies it was found already being exploited in the wild.

The author even says that Apple found no evidence of it being exploited.

By definition when this blog post was published it was not the 0th day.

Re: Zero-day in Sign in with Apple

#195

Post by jedberg » Sat, May 30, 2020, 11:40 PM UTC

saagarjha wrote: post #175

afrcnc wrote: post #168

Replace "zero-day" with "privately reported security bug for which I got $100k" That's not how zero-day works

It was a zero day up until the first report was made.

That's always true though. 0-day implies it was discovered being actively exploited or that it was released on the 0th day it was discovered.

Re: Zero-day in Sign in with Apple

#196

Post by saagarjha » Sat, May 30, 2020, 11:47 PM UTC

jedberg wrote: post #195

saagarjha wrote: post #175

Earlier quoted context omitted.

It was a zero day up until the first report was made.

That's always true though. 0-day implies it was discovered being actively exploited or that it was released on the 0th day it was discovered.

I believe “0 day” actually refers to the number of days that the vendor has had to fix the issue, not how many days it’s been since it’s discovered. For example, there might be a substantial delay between bug discovery and actual disclosure to the vendor–I usually take a couple days to write up a nice explanation and PoC. If I had found something and then published it publicly the next day without disclosing it, it’d still be a zero day.

Re: Zero-day in Sign in with Apple

#197

Post by jedberg » Sat, May 30, 2020, 11:52 PM UTC

saagarjha wrote: post #196

jedberg wrote: post #195

Earlier quoted context omitted.

That's always true though. 0-day implies it was discovered being actively exploited or that it was released on the 0th day it was discovered.

I believe “0 day” actually refers to the number of days that the vendor has had to fix the issue, not how many days it’s been since it’s discovered. For example, there might be a substantial delay between bug discovery and actual disclosure to the vendor–I usually take a couple days to write up a nice explanation and PoC. If I had found something and then published it publicly the next day without disclosing it, it’d…

You're right I should have said 0 days since it was disclosed to the vendor. That would be more accurate.

Regardless, this bug is definitely not 0 day given that it was disclosed to the vendor last month.

Re: Zero-day in Sign in with Apple

#198

Post by ljm » Sat, May 30, 2020, 11:54 PM UTC

> For this vulnerability, I was paid $100,000 by Apple under their Apple Security Bounty program.

Fucking hell. Even after tax, that's a substantial pay-out.

Re: Zero-day in Sign in with Apple

#199

Post by kag0 » Sun, May 31, 2020, 12:16 AM UTC

To me this seems like a poor protocol design that created an opportunity for an implementation error, and that opportunity was seized.

In the initial authorization request rather than passing a string with an email address, the caller could pass a boolean `usePrivateRelay`. If true generate a custom address for the third party, if false use the email address on file.

With that one change the implementer no longer has the opportunity to forget to validate the provided email address, and the vuln is impossible.

Re: Zero-day in Sign in with Apple

#200

Post by m_herrlich » Sun, May 31, 2020, 12:22 AM UTC

kag0 wrote: post #199

To me this seems like a poor protocol design that created an opportunity for an implementation error, and that opportunity was seized. In the initial authorization request rather than passing a string with an email address, the caller could pass a boolean `usePrivateRelay`. If true generate a custom address for the third party, if false use the email address on file. With that one change the implementer no longer has…

You misunderstand the bug, the exploit allows an attacker to generate an apple-signed JWT with an email address of the attacker's choice.