Live data from Hacker News

Zero-day in Sign in with Apple

bhavukjain.com

121–130 of 280 posts

Re: Zero-day in Sign in with Apple

#121

Earlier quoted context omitted.

This was pretty true not long ago. It's still a notoriously short window for OEM software patches on Android, whereas Apple's first 64-bit phone, the 5s from Fall 2013 is still getting patches (May 20th was the last one, iOS 12.4.7) Apple pioneered usable security with TouchID and the secure enclave; a lot of Android fingerprint readers were gimmicks for years, same with the face unlocks. https://manuals.info.apple.c…

Fortunately, it seems google has separated security updates from the OEM updates on some newer phones it seems. The phone I bought In November 2018, right now is receiving monthly security updates via Play Services updates, and is right now on the May version for some time.

> The phone I bought In November 2018

I think it’s too early to claim anything for that one.

Re: Zero-day in Sign in with Apple

#123
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…

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.

Apple? No way.

Re: Zero-day in Sign in with Apple

#124

Earlier quoted context omitted.

This was pretty true not long ago. It's still a notoriously short window for OEM software patches on Android, whereas Apple's first 64-bit phone, the 5s from Fall 2013 is still getting patches (May 20th was the last one, iOS 12.4.7) Apple pioneered usable security with TouchID and the secure enclave; a lot of Android fingerprint readers were gimmicks for years, same with the face unlocks. https://manuals.info.apple.c…

Yes I'm not gonna defend Google's privacy issues, but privacy is totally different from security. People tend to confuse them. I understand it if it's average Joe got confused. But if you are a "security consultant" and you still have no idea what's the difference between them, then that's a big problem. Regarding security, see examples like https://qz.com/1844937/hong-kongs-mass-arrests-give-police-a...

For privacy, I guess you can have full confident that Apple has the intention to keep your data private. But do you have full confident that Apple has the competence to fulfill that intention?

Google doesn't have the intention to keep all your data private, sure. They are an ads company after all. But for things they want to protect, in most cases they are competent enough to protect them.

(Disclaimer: I also worked for Google, but the "employer" I mentioned in my original comment was not Google)

Re: Zero-day in Sign in with Apple

#126
post #10

> 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. This means an attacker could forge a JWT by linking any Email ID to it and gaining access to the victim’s account. Great writeup there. Looks like a Apple JWT bug and the verification went through despite it being 'signed' and 'tamperproof'. Clearly its footgun…

Your earlier comment, and your comment today, are both baseless.

They demonstrate no issues with JWTs. There are issues with JWTs, but you have not hit on any of them.

Re: Zero-day in Sign in with Apple

#127
post #31
post #24

Earlier quoted context omitted.

Fortunately some rando site or SaaS app doesn't have the leverage to force me to implement additional garbage! Apple does, and did. 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.

I agree that the requirement from Apple here is kind of dumb, but I don’t see how it would not be in the best interest of a user of an app on an iOS device to have the option to sign in with an Apple ID. It also seems silly to consider it “garbage” when you already using a Google Account solution that is essentially the same thing.

It's garbage because it was forced into already functioning apps with the threat of removal, and because it evidently has gaping security holes.

Re: Zero-day in Sign in with Apple

#128
post #114

Earlier quoted context omitted.

I still trust Apple over a rando site or SaaS app. No system is flawless.

Yeah but I don't trust them over Google or Facebook when it comes to server side security, and this proves it.

I will still take an Apple security incident over the corporate surveillance apparatus that is Facebook and Google.

Re: Zero-day in Sign in with Apple

#129
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…

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.

Re: Zero-day in Sign in with Apple

#130
post #79
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…

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

I'm not sure if Apple ever had quality.

They are the Nintendo of Computing. They have some novelties, but in general they are average at their best. Notice that both Nintendo and Apple are big advertisers.

Post reply on HN