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

141–150 of 280 posts

Re: Zero-day in Sign in with Apple

#141

Post by SV_BubbleTime »

fishywang wrote: post #106
enitihas wrote: post #77

Earlier quoted context omitted.

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.

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…

It’s none of my concern what camp people fall into... but...

I hired a very high level pen test company, they mandated iPhones for their company work. They were the best infosec company we’ve ever hired. Sample of one.

I wouldn’t suggest iPhones are more safe than Android, but i also wouldn’t suggest in any way they are less safe overall.

Re: Zero-day in Sign in with Apple

#144

Post by mazeltovvv »

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 a post mortem from Apple.

I have a few follow up questions.

1. seeing how simple the first JWT request is, how can Apple actually authenticate the user at this point?

2. If Apple does not authenticate the user for the first request, how can they check that this bug wasn’t exploited?

3. Anybody can explain what this payload is?

{ "iss": "https://appleid.apple.com", "aud": "com.XXXX.weblogin", "exp": 158XXXXXXX, "iat": 158XXXXXXX, "sub": "XXXX.XXXXX.XXXX", "c_hash": "FJXwx9EHQqXXXXXXXX", "email": "contact@bhavukjain.com", // or "XXXXX@privaterelay.appleid.com" "email_verified": "true", "auth_time": 158XXXXXXX, "nonce_supported": true }

My guess is that c_hash is the hash of the whole payload and it is kept server side.

Re: Zero-day in Sign in with Apple

#145

Post by fermienrico »

_23sd wrote: post #66
fermienrico wrote: post #8

Earlier quoted context omitted.

Literally every system in the world has flaws, no matter how secure. We just don't know about these bugs yet.

"Every system in the world has flaws" and "it's a serious problem that one of the world's most important software vendors, that markets itself as the most secure, keeps releasing products with flaws that would have been discovered in a very basic audit" are not incompatible statements..

Even then there will be more flaws. I don't think it is possible to build a 100% secure system in the modern age of 22 abstraction layers between the atom to the data center.

Perhaps you do not understand the staggering complexity that lies behind watching a cat video on your iPhone. There are almost uncountable ways to break into the system. This is why there is a bug bounty program from every company - from Stripe (you could argue as a major software company in payment systems) to Microsoft, from Apple to Gitlab, every company has a bug bounty program. Why do you think they give out $1m for a serious bug? If they were not serious about it, that sounds like a big waste of time.

This kind of entitlement attitude is usually from people who've never developed a complex piece of software such as an operating system.

Re: Zero-day in Sign in with Apple

#146

Post by mazeltovvv »

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?

Ah. So this creates a valid JWT for any email you want, but it is now associated with your own apple account?

Re: Zero-day in Sign in with Apple

#147

Post by cdubzzz »

paxys wrote: post #114
toomuchtodo wrote: post #21

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.

Eh. I’ll take a found and fixed security issue in a feature aimed at keeping my email address private over Google and Facebook’s invasive behaviors.

Re: Zero-day in Sign in with Apple

#148

Post by mlthoughts2018 »

rubyn00bie wrote: post #135
mlthoughts2018 wrote: post #116

Earlier quoted context omitted.

How could you prove the user was the correct user in any given case?

They very like have a complete log of the action performed; I'd guess, they'd perform some kind of replay/playback after the bug was fixed, and see what failed to pass. Assuming their changes immediately flag things like the researcher's initial attempts and discovery, it'd probably be pretty safe to say that no one was affected if no other instances are flagged.

How does that answer the question? So what if you can replay logs of all attempts? How can you prove for any specific log that it was the “real” user making the request, and not someone using their email maliciously to make an identical request?

Re: Zero-day in Sign in with Apple

#150

Post by TheSpiceIsLife »

lowdose wrote: post #120
TheSpiceIsLife wrote: post #104

Earlier quoted context omitted.

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.

Mojave removed Facebook, Twitter, Vimeo, and Flickr, integrations, none of which I use, so that would be good.

But I’m not aware of any new feature in Mojave I want or need, so the 2013 MacBook Pro Retina I’m using will stay on High Sierra for today :)

Post reply on HN