"Sign in with Apple" Vulnerability

Researcher Bhavuk Jain discovered a vulnerability in the "Sign in with Apple" feature, and received a $100,000 bug bounty from Apple. Basically, forged tokens could gain access to pretty much any account.

It is fixed.

EDITED TO ADD (6/2): Another story.

Posted on June 2, 2020 at 6:27 AM • 15 Comments

Comments

Clive RobinsonJune 2, 2020 8:25 AM

Yet another blow to Apples "oh so secure" image...

Makes you wonder why the FBI and DoJ are so so pushy at getting a built in backdoor in Apple Phones etc.

Just goes to show that some peoples mental outlook should kind of get them barred from high office...

MrCJune 2, 2020 10:07 PM

I guess the lesson here is that "single sign-on" is just a fundamentally bad idea. The added complexity is just asking for trouble. Thoughts?

QJune 3, 2020 12:16 AM

Single sign-on == single point of failure == bad idea.

One for-profit company controls all of the accesses ... that is a big bag of nope for me.

Clive RobinsonJune 3, 2020 12:33 AM

@ MrC,

I guess the lesson here is that "single sign-on" is just a fundamentally bad idea.

The way many "Single Sign On" (SSO) systems are implemented I would have to agree.

Also what many forget is that with the way SSO works the "spider at the center of the web" gathers a large amount of information about the individual using the service.

Thus anyone at an "upstream router" of thr SSO host gets to see the traffic to and from it (meta-data thus traffic analysis).

Thus the closer the SSO service is to the user potentially the more secure it is with regards the user-SSOserviceHost traffic. Logically this collapses down to a user creating their own equivalent of an SSO when they use it on the same host or behind the user level application in the form of a secure token or piece of paper in their wallet.

From a network centered view a piece of paper in your wallet is more secure because a network based attacker can not get beyond the User Interface of the host the user is using. However as the piece of paper in reality forces a "plaintext password" at the UI the password is not secure.

Thus if implemented correctly a "challange response system" on a Secure Token in the users possession and an adequately provisioned Hardware Security Modual (HSM) at the service the user is attempting to authenticate to is at the authentication level more secure.

But a Secure Token and HSM authentication solution is very expensive per user to implement, thus is unlikely to become available to a service unless either the service owner has sufficient reason or the authentication service owner has another way to finance the service. Which these days almost always means some form of PPI Data gathering.

For what is fundamentally a simple idea authentication has a great many wrinkles, each of which can easly be seen as a gaping security chasam from a an attacker/defender security perspective.

Arguably we don't have any "secure" authentication systems as the complexity issue you mention is always present and different in each and every implementation. And nobody has sufficient depth and breadth of knowledge, or time to verify the system secure against all currently known attacks. As for as yet unknown attacks to the system, well designers and implementers of authentication systems should remember that often misquoted line from a very early 1970's film,

    "You've got to ask yourself one question. Do I feel lucky?"

WaelJune 3, 2020 1:13 AM

@Clive Robinson, @MrC,

SSO is needed. It's implementation could be weak sometimes, but it's an essential concept nonetheless!

often misquoted line from a very early 1970's film,

You ain't lyin'!.

Clive RobinsonJune 3, 2020 4:18 AM

@ Wael,

SSO is needed

That is debatable under any given set of conditions that give rise to a system. Thus whilst the concept is valid under certain limited conditions, any wider requirment is at best an assumption.

As I've indicated SSO has issues, one of which is how you do what is assumed to be a basic "two party function" of authentication through or via a "third party". It's not just the issues to do with communications security and meta-data giving rise to traffic analysis by an assumed hostile "Eve" or "Mallory", it's also a trust issue.

In a secure two party transaction, if something goes wrong you can establish which party is at fault only by examining your own actions. The same is not true of a three party transaction. Worse the other two parties can conspire against you in various ways.

In real life we see this game played out, with the harmed first party getting passed backwards and forwards between the other two parties ad infinitum. The only way to stop this is to make it clear that you only have one relationship with say the second party, and that as they engage the third party they are responisble for any actions or failings of the third party to you. One of the failings of SSO is that trying to establish a chain of responsability / liability is not possible. Thus to misquote and old saying "Whilst their is blaim there can be no claim". In essence nearly all SSO systems fall into this category. That is you are forced to use SSO as a user but neither the SSO provider or SSO using service have liability towards you. Thus there is a very definate disincentive for either the SSO provider or SSO using service who have "externalised their liability" to fix any security issues, unless they think their reputation might be harmed.

WaelJune 3, 2020 5:11 AM

@Clive Robinson,

I wouldn't want to login to each application I use in a work environment! That would be unproductive. Then again, are we making a distinction between something like SAML and OAuth?

Ergo SumJune 3, 2020 6:19 AM

@Clive Robinson...

One of the failings of SSO is that trying to establish a chain of responsibility / liability is not possible.

This applies to any software/hardware in general.

Software/hardware based SSO, why should it be singled out?

politically correct sarcasm
You owe SSO a deep, heartfelt apology... :-)
end of politically correct sarcasm

Ergo SumJune 3, 2020 6:48 AM

Convenience always trumps security, that'll never change...

Question about this vulnerability, since the media overhypes the Apple angle, at least that's my understanding...

Wouldn't this vulnerability require that the Apple ID owner establish an account at the site/application in question prior to being exploited?

I don't use Apple, or any other third-party SSO services, never trusted them and never will. Am I wrong in believing, that the current vulnerability does effect me in any ways?

Note: None of the financial institutions that I use online rely on third-party authentication. That tells me all I need to know about the security / privacy of these services...

SwashbucklingCowboyJune 3, 2020 9:12 AM

It is a single point of failure, but I'll take a one really good authentication mechanism that's a single point of failure over a bunch of mediocre authentication mechanisms that taken together pretty much guarantee failure.

Stop focusing on the security of each part and focus more on the security of the whole.

Clive RobinsonJune 3, 2020 9:35 AM

@ Wael,

I wouldn't want to login to each application I use in a work environment!

In theory provided it's not BYOD the work network and all connected hosts do not belong to you but your employer, "so what they say goes" more or less.

Provided there is some form of reliable "choke-point gateway" between the "assumed secure" internal private network and the "assumed insecure" public external network, then the employer can set up an internal SSO service without having it access to or be accessed from the external public network.

As I noted earlier,

    Thus the closer the SSO service is to the user potentially the more secure it is...

So if the work network is sufficiently issolated from any public network then an external attacker can not get at the users computer, the SSO service, or any server reliant on it. However this does not prevent "insider attacks" from succeeding.

myliitJune 3, 2020 9:54 AM

OT, Apple brought out a bunch of secuity updates 1 June.

IIRC, they effect essentially all Current devices, to fix one (1) bug

https://support.apple.com/en-us/HT201222 For example:

“ macOS Catalina 10.15.5 Supplemental Update, Security Update 2020-003 High Sierra
Released June 1, 2020
Kernel
Available for: macOS High Sierra 10.13.6, macOS Catalina 10.15.5
Impact: An application may be able to execute arbitrary code with kernel privileges
Description: A memory consumption issue was addressed with improved memory handling.
CVE-2020-9859: unc0ver”
.

Clive RobinsonJune 3, 2020 10:58 AM

@ Ergo Sum,

This applies to any software/hardware in general.

It does and it does not as a general rule if you aquire software to run on your computer, it's the supplier that's on the hook to you, irrespective of the number of third party libraries they use.

SSO, is something that is "being forced onto people" by the usual suspects that grab PPI every which way they can. As indicated in the article Apple made it a condition of entry for their "walled Garden Market Place" for certain types of application.

Any SSO system outside of a restricted network is open to abuse not just actively (as in this case) but passively with the likes of traffic analysis. The bigger the SSO service, the more attractive it is to attackers especially those that are "Level Three" (state level) or equivalent private corp selling their services to nation states that don't have the technical chops in country to have a SigInt Agency of their own.

Clive RobinsonJune 3, 2020 11:47 AM

@ SwashbucklingCowboy,

Stop focusing on the security of each part and focus more on the security of the whole.

Security is assumed to rest on "The weakest link in the chain" unless you do focus on the security of each part, you will not understand if that part is a weak link or not and importantly in what context.

Security is multifaceted thus context is very important. Whilst you may have an authentication process that can not be fooled, it may not be appropriate to use it if it haemorrhages PPI to anyone who cares to passively listen to it. That is there are applications where strong authentication is not actually required but a high level of confidentiality in network communications is.

Not getting the confidentiality right can and has led to a loss of life in what are euphemisticaly called "sources" by intelligence entities.

Allegedly it was a lack of communications confidentiality in a CIA web app that led to both the Iranian and Chinese security services rounding up and executing or imprisoning twenty or so sources for the CIA in both countries in 2010-2012 (the joint FBI-CIA "mole hunt" investigation was code-named Honey Badger and apparently found nothing of note).

https://www.telegraph.co.uk/technology/2018/11/03/dozens-us-spies-killed-iran-china-uncovered-cia-messaging-service/

Jesse ThompsonJune 4, 2020 3:15 PM

@Clive Robinson

Yet another blow to Apples "oh so secure" image...

I think Bruce's philosophy is that preventing security vulnerability (and/or breach) with 100% fidelity is not realistic, and that how promptly and effectively one responds to correct a vulnerability once discovered is what matters.

Apple was advised of a potential exploit, one that we have no proof even got exploited yet. Apple cooperated with researcher to patch it in a timely fashion. Apple paid researcher a 6-figure bug bounty.

Which company within 2 orders of magnitude of this size would you point to as having a track record that puts this behavior to shame? Do you require large companies with hundreds of millions of end-users to maintain Bernstein/Nakamoto levels of flawlessness at that scale? Even they only approach what has yet to be distinguished from flawlessness by gutting their code bases so thoroughly that all responsibility for actual implementation lay elsewhere. While not a bad strategy in general, all it can do is create for you a polished security primitive. It by it's very definition cannot scale.

--------------
@MrC

I guess the lesson here is that "single sign-on" is just a fundamentally bad idea. The added complexity is just asking for trouble. Thoughts?

I think that virtually every password-based system is an SSO at the lowest layer. The fallback for users forgetting their password is always "send secret through email". So how is that any different from email provider being SSO provider?

Password systems at least allow a user to log in without a third party's direct involvement when user does remember their password, but let's analyze that potential a bit further:

  • If a typical end-user can remember a password, then it's almost by definition an insecure token: easily guessed, and/or repeated everywhere.
  • If they use a third party password manager, then that is also just a form of SSO with all the complexity that entails.. if not more for trying to pretend to be an ordinary password signin.
  • If they're using a first-party password manager, and expect to authenticate from disparate devices, then I guarantee the user is replicating all of SSO's complication on their own watch and the percentage of human beings who will choose to do this are low enough to ignore for all practical purposes anyway.

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Sidebar photo of Bruce Schneier by Joe MacInnis.