Why haven't they just implemented OAuth 2.0, like everyone else has done? They've tried to reinvent the wheel with their own implementation of a three-legged user authentication that doesn't add anything to what OAuth does and, surprise, they've exposed themselves to a critical vulnerability that could have been completely avoided.
Zero-day in Sign in with Apple
241–250 of 280 posts
Re: Zero-day in Sign in with Apple
#242> 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.
That was my first thought too. No wonder he's a full-time bug bounty hunter.
Re: Zero-day in Sign in with Apple
#243How 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…
> code review and testing.
Sometime code review is just "Please change the name of this function" and testing is just testing the positive cases not the negative ones. Yes, even in companies like apple and google.
Re: Zero-day in Sign in with Apple
#244After observing its endless flow of security and reliability bugs, I begin to think that the recent decline of Apple's overall software quality over the several years is probably a more of systematic problem.
https://www.bloomberg.com/news/articles/2019-11-21/apple-ios...
Looks like Federighi agrees with this diagnosis and tries to improve the overall development process but not sure if it can be really improved without changing the famous secretive corporate culture. At the level of Apple's software complexity, you cannot really design and write a quality software without involving many experts' eyes. And I have been complained by my friends at Apple about how hard to get high level contexts of their works and do a cross-team collaboration.
And IMO, this systematic degradation of the software quality coincides with Bertrand's leaving, who had allowed relatively open culture at least within Apple's software division. I'm not an insider, so this is just a pure guess though.
Re: Zero-day in Sign in with Apple
#245Earlier quoted context omitted.
That makes sense. Seems little too obvious to exist, but people make mistakes. It’s just that with JWT/JSE/JOSE already questionable security options that you would be extra super careful if you are using it. (Biggest flaw off the top of my head is it literally says what encryption is used with a NONE option meaning you can just switch to “none” and forge jwts to anyone that didn’t know not to accept those, second wo…
I noticed after reading your comment that HS256 is marked as “required” for compliant implantations. In practice, I have only ever seen signers implement RS256 though...
In OIDC you can actually specificy supported key types in the discovery process and the IdP always decides the key type anyway.
HS256 relies in shared secrets, so anyone who can verify a token can also change it. RS256 allows you to download the IdP keychain every once in a while and verify tokens offline.
Re: Zero-day in Sign in with Apple
#246Earlier quoted context omitted.
I think it's actually the OIDC access token and not the ID token. The OIDC spec does not mandate any structure for the access token, but letting it be a JWT isn't out-of-spec.
I do not believe that Apple yet uses the access token bit. OAuth tokens also are not meant to be used for authentication, and require either a separate token (as OpenID Connect did) with appropriate security, or to wedge additional security on top of access tokens as Facebook did with Connect. This is basically because access tokens are meant to be messages about allowed access to the API resources, not messages to t…
A few popular IdPs (e.g. keycloak) have no but semantic difference in access and ID tokens, they're both signed JWTs (EC/RSA or shudder HMAC shared secrets) with different typ fields.
Re: Zero-day in Sign in with Apple
#247Earlier quoted context omitted.
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.
This, thousand times. Don't just fix the bug, fix the process that led to the bug. Developers are (usually) not malicious, but we are often working with tooling which makes mistakes easy to do, difficult to detect and grave in consequences. Fix the tooling, not just the bug.
Re: Zero-day in Sign in with Apple
#248Earlier quoted context omitted.
In general I agree with you that it's good to run fuzzers against any endpoints, public or internal (as you never know if someone can wrangle data to go from public -> internal somehow), but in this particular case, you'd only find a issue if the fuzzer somehow randomly used the ID of another user that was already created, and verified that it couldn't access it. In that case, you'd catch it way before even implement…
There's no reason that a fuzzer couldn't draw sample email addresses from a large pool of test valid email addresses to add as input. That would just require a fuzzer that allowed you to provide the sample population for a particular data type.
My point still stands. If the one setting up the fuzzer is thinking about the condition that A) you're using a valid email that B) already existing in the system and C) cannot be used to authenticate with another system, you can easily check the code for this directly. The fuzzer won't add anything over a simple integration/E2E test here.
Re: Zero-day in Sign in with Apple
#249Earlier quoted context omitted.
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.
Well, depending on how hard you look and what the false negative rate is like, bayesian reasoning would like to differ.
You know what I love about the internet? You think something like this, and you just know somebody's looked into it in some details :D - https://cocosci.princeton.edu/papers/absentData.pdf
Re: Zero-day in Sign in with Apple
#250Earlier quoted context omitted.
Seems the only way to trust the companies in such situations is to exploit the vulnerabilities from multiple, unconnectable devices and locations, over as long a period as possible. If the company cannot list all of the attacks, you know they're bullshitting.
I wonder if compromising your own account can be seen as unlawful. It's much like teenagers being found to break the law by making nude photos of themselves: they are found in possession of prohibited materials, even though they obtained them in a lawful way. Cracking your own account in a lawful way could possibly be done by a court order, but otherwise your actions are prohibited by law, even.though there cannot be…
Luckily we don't all live under US law.