Zero-day in Sign in with Apple

May 30, 2020 — 3 min read

What if I say, your Email ID is all I need to takeover your account on your favorite website or an app. Sounds scary, right? This is what a bug in Sign in with Apple allowed me to do.

In the month of April, I found a zero-day in Sign in with Apple that affected third-party applications which were using it and didn't implement their own additional security measures. This bug could have resulted in a full account takeover of user accounts on that third party application irrespective of a victim having a valid Apple ID or not.

For this vulnerability, I was paid $100,000 by Apple under their Apple Security Bounty program.

Technical Details

The Sign in with Apple works similarly to OAuth 2.0. There are two possible ways to authenticate a user by either using a JWT (JSON Web Token) or a code generated by the Apple server. The code is then used to generate a JWT. The below diagram represents how the JWT creation and validation works.

In the 2nd step, while authorizing, Apple gives an option to a user to either share the Apple Email ID with the 3rd party app or not. If the user decides to hide the Email ID, Apple generates its own user-specific Apple relay Email ID. Depending upon the user selection, after successful authorization, Apple creates a JWT which contains this Email ID which is then used by the 3rd party app to login a user.

A decoded JWT's payload looks like this:

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

BUG

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.

Sample Request (2nd step)

POST /XXXX/XXXX HTTP/1.1
Host: appleid.apple.com

{"email":"[email protected]"}

Here on passing any email, Apple generated a valid JWT (id_token) for that particular Email ID.

Sample Response

{
  "authorization" : {
    "id_token" : "eyJraWQiOiJlWGF1bm1MIiwiYWxnIjoiUlMyNTYifQ.XXXXX.XXXXX",
    "grant_code" : "XXX.0.nzr.XXXX",
    "scope" : [ "name", "email" ]
  },
  "authorizedData" : {
    "userId" : "XXX.XXXXX.XXXX"
  },
  "consentRequired" : false
}

The impact of this vulnerability was quite critical as it could have allowed full account takeover. A lot of developers have integrated Sign in with Apple since it is mandatory for applications that support other social logins. To name a few that use Sign in with Apple - Dropbox, Spotify, Airbnb, Giphy (Now acquired by Facebook). These applications were not tested but could have been vulnerable to a full account takeover if there weren't any other security measures in place while verifying a user.

Apple also did an investigation of their logs and determined there was no misuse or account compromise due to this vulnerability.

A huge thanks to the Apple Security Team.

Thanks for the read, see you in next article :)

Share this post: