Día cero con Apple

Un programador indio detectó una vulnerabilidad de día cero al Inicio de sesion en IOS, esta afectaba las aplicaciones de terceros que lo usaban y no implementaba sus propias medidas de seguridad adicionales.

¿Qué sucede si digo que su ID de correo electrónico es todo lo que necesito para controlar su cuenta en su sitio web favorito o una aplicación? Suena aterrador, ¿verdad? Esto es lo que un error Sign in with Appleme permitió hacer.

En el mes de abril, encontré un día cero en Sign in with Applelas aplicaciones de terceros afectadas que lo usaban y no implementaron sus propias medidas de seguridad adicionales. Este error podría haber resultado en una toma de control total de la cuenta de usuario en esa aplicación de terceros, independientemente de que una víctima tenga una ID de Apple válida o no.

Por esta vulnerabilidad, Apple me pagó $ 100,000 bajo su programa Apple Security Bounty.

Detalles técnicos

El Sign in with Applefuncionamiento es similar al de OAuth 2.0. Hay dos formas posibles de autenticar a un usuario mediante el uso de JWT (JSON Web Token)o codegenerado por el servidor de Apple. El código se usa para generar un JWT. El siguiente diagrama representa cómo funciona la creación y validación de JWT.

En el segundo paso, mientras autoriza, Apple le da a un usuario la opción de compartir la ID de correo electrónico de Apple con la aplicación de terceros o no. Si el usuario decide ocultar la ID de correo electrónico, Apple genera su propia ID de correo electrónico de retransmisión de Apple específica del usuario. Dependiendo de la selección del usuario, después de una autorización exitosa, Apple crea un JWT que contiene esta ID de correo electrónico que luego es utilizada por la aplicación de terceros para iniciar sesión en un usuario.

La carga útil de un JWT decodificado se ve así:

{
  "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
}

** ERROR **

Descubrí que podía solicitar JWTs para cualquier ID de correo electrónico de Apple y cuando se verificó la firma de estos tokens utilizando la clave pública de Apple, se mostraron como válidos. Esto significa que un atacante podría falsificar un JWT al vincular cualquier ID de correo electrónico y obtener acceso a la cuenta de la víctima.

Solicitud de muestra (segundo paso)

POST /XXXX/XXXX HTTP/1.1
Host: appleid.apple.com
{"email":"contact@bhavukjain.com"}

Aquí al pasar cualquiera email, Apple generó un JWT válido (id_token) para esa ID de correo electrónico en particular.

Respuesta de muestra

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

El impacto de esta vulnerabilidad fue bastante crítico, ya que podría haber permitido la adquisición total de la cuenta. Muchos desarrolladores se han integrado, Sign in with Appleya que es obligatorio para las aplicaciones que admiten otros inicios de sesión sociales. Por nombrar algunos que usan Sign in with Apple: Dropbox, Spotify, Airbnb, Giphy (ahora adquirido por Facebook). Estas aplicaciones no se probaron, pero podrían haber sido vulnerables a una toma de control total de la cuenta si no se hubieran implementado otras medidas de seguridad al verificar a un usuario.

Apple también investigó sus registros y determinó que no había mal uso o compromiso de la cuenta debido a esta vulnerabilidad.