Some people commenting this to be overpriced, but I don't think so even if they are considering the INR value. The bug is quite critical considering how large the mac and iOS ecosystem is.
Zero-day in Sign in with Apple
111–120 of 280 posts
Re: Zero-day in Sign in with Apple
#112With all those high-profile third parties using Apple ID, what would happen if somebody stole/deleted/damaged my data/assets on Dropbox/Spotify/Airbnb/...? Would I sue the provider who would sue Apple? But does Apple provide any guarantees to the relying parties? And if not and the only way is to depend on the reputation when choosing the ID providers you want to support, how would anyone want to support Apple ID aft…
The ToS of every service has a liability waiver.
Re: Zero-day in Sign in with Apple
#113How 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.
Re: Zero-day in Sign in with Apple
#114Wow, I'm so glad that apple forced me to implement this broken garbage into my apps! For those not aware, some time ago apple decided it would be a good idea to develop their own sing in system, and then force all apps on their store (that already support e.g. Google Account login) to implement it. So they brought a huge amount of additional complexity in a large amount of apps, and then they fucked up security. Than…
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.
Re: Zero-day in Sign in with Apple
#115Earlier quoted context omitted.
Last year (or maybe 2018?) my employer hired an external consultant to give engineers security trainings (all are optional, they provide a few sessions on different topics, and engineers can sign up for interested ones). In one of the sessions I signed up, during the pre-session chat (while waiting for everyone signed up show up in the conference room), the external trainer "casually" chatted about "if you have an An…
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.
Re: Zero-day in Sign in with Apple
#116" 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.
The one case (and about the only case) I can think of where they can claim above is: If they have a log of all JWTs issued that records which user requested and which email in JWT, then they can retroactively check if they issued any (user, email) pair that they shouldn't have. Then they can assert that there was no misuse, if they only found this researcher's attempt.
How could you prove the user was the correct user in any given case?
Re: Zero-day in Sign in with Apple
#117Earlier quoted context omitted.
Last year (or maybe 2018?) my employer hired an external consultant to give engineers security trainings (all are optional, they provide a few sessions on different topics, and engineers can sign up for interested ones). In one of the sessions I signed up, during the pre-session chat (while waiting for everyone signed up show up in the conference room), the external trainer "casually" chatted about "if you have an An…
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...
Re: Zero-day in Sign in with Apple
#118How 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 had more simple "unbelievable" bugs, e.g https://news.ycombinator.com/item?id=15800676 (Anyone can login as root without any technical effort required) And to top it off ( https://news.ycombinator.com/item?id=15828767 ) Apple keeps having all sorts of very simple "unbelievable" bugs.
You can't forget the infamous "goto fail": https://www.imperialviolet.org/2014/02/22/applebug.html
There seems to be kind of a common theme to these:
- SSL certificates not validated at all
- root authentication not validated at all
- JWT token creation for arbitrary Apple ID users not validated at all
I think these are all very likely due to error and not malice, but it's pretty crazy how these gaping holes keep being found.
Re: Zero-day in Sign in with Apple
#119“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.”
What are they teaching them in computer school these days. How can you write a security function and not test it for these kind of bugs. Unless all there accidental backdoors have a more nefarious purpose
Re: Zero-day in Sign in with Apple
#120Earlier 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.
I went to Mojave and that went without trouble except I lost the ability to use my external GPU, but I knew that.