Vulnerabilidad en la nueva función TouchID pone en riesgo las cuentas de iCloud de ser vulneradas

Iniciar sesión mediante TouchID/FaceID en Safari - ¿sin 2FA?

En iOS 13 y macOS 10.15, Apple añadió la posibilidad de iniciar sesión en los sitios propios de Apple usando TouchID/FaceID en Safari en dispositivos que incluyen el hardware biométrico requerido.

Cuando visitas cualquier página con un formulario de inicio de sesión para una cuenta Apple, se muestra un aviso para autenticar usando TouchID en su lugar. Si te autenticas, inicias sesión inmediatamente. Esto omite el paso de autenticación de dos factores que normalmente tendrías que realizar al iniciar sesión con tu contraseña. Esto tiene sentido porque el proceso puede considerarse que ya requiere dos factores: tus datos biométricos y el dispositivo. Puedes cancelar el aviso para iniciar sesión normalmente, por ejemplo, si quieres usar un AppleID diferente al que está registrado en el teléfono.

Esperamos que el caso de uso principal de esta función no sea para iniciar sesión en iCloud (ya que es bastante raro usar icloud.com en Safari en un teléfono), pero esperamos que el principal motivador fuera para “Iniciar sesión con Apple” en la web, para lo cual esta función también funciona. Para esos sitios se muestran opciones adicionales al crear una nueva cuenta, por ejemplo, si deseas ocultar tu dirección de correo electrónico.

Inicio de sesión en dominios de Apple usando OAuth2

El inicio de sesión en dominios de Apple se realiza usando OAuth2. En https://icloud.com, esto utiliza el modo “web_message”. Esto funciona de la siguiente manera al hacer un inicio de sesión normal:

1. https://icloud.com incrusta un iframe que apunta a https://idmsa.apple.com/appleauth/auth/authorize/signin?client_id=d39ba9916b7251055b22c7f910e2ea796ee65e98b2ddecea8f5dde8d9d1a815d
   &redirect_uri=https%3A%2F%2Fwww.icloud.com
   &response_mode=web_message
   &response_type=code.
2. El usuario inicia sesión (incluyendo pasos como ingresar un token 2FA) dentro del iframe.
3. Si la autenticación tiene éxito, el iframe envía un mensaje de vuelta a la ventana principal con un grant_code para el usuario usando window.parent.postMessage(, "https://icloud.com") en JavaScript.
4. El grant_code es usado por la página icloud.com para continuar el proceso de inicio de sesión.

Validación correcta del URI de redirección esencial para proteger el código de concesión del usuario

Dos de los parámetros son muy importantes en la URL del iframe: el client_id y redirect_uri. El servidor idmsa.apple.com mantiene un registro de una lista de clientes OAuth2 registrados y los URIs de redirección permitidos para cada cliente. En el caso del flujo web_message, el URI de redirección no se usa como una redirección real, sino que se usa como el origen de página requerido del mensaje enviado con el código de concesión (el segundo argumento para postMessage).

Para todos los modos de OAuth2, es muy importante que el servidor de autenticación valide correctamente el URI de redirección. Si no lo hace, el grant_code del usuario podría enviarse a una página web maliciosa en su lugar. Al iniciar sesión en el sitio web, idmsa.apple.com realiza esa verificación correctamente: cambiar el redirect_uri a cualquier otro valor resulta en una página de error.

Uso de respuesta falsa por Safari

Cuando el usuario se autentica usando TouchID, el iframe se maneja de manera diferente, pero la página externa permanece igual. Cuando Safari detecta una nueva página con una URL que coincide con la URL de ejemplo mencionada arriba, no descarga la página, sino que invoca el proceso AKAppSSOExtension. Este proceso se comunica con el demonio AuthKit (akd) para manejar la autenticación biométrica y para recuperar un grant_code. Si el usuario se autentica con éxito, Safari inyecta una respuesta falsa a la solicitud pendiente del iframe que envía el mensaje de vuelta, de la misma manera que lo haría la página normal si la autenticación hubiera tenido éxito. akd se comunica con una API en gsa.apple.com, a la cual envía los detalles de la solicitud y de la cual recibe un grant_code.

Impacto de la vulnerabilidad: actores maliciosos pueden iniciar sesión en la cuenta de iCloud de otros usuarios

Lo que encontramos fue que la API de gsa.apple.com tenía un error: aunque el client_id y redirect_uri estaban incluidos en los datos enviados por akd, no verificaba que la URI de redirección coincidiera con el ID del cliente. En cambio, solo se aplicaba una lista blanca por AKAppSSOExtension en los dominios. Se permitían todos los dominios que terminan en apple.com, icloud.com y icloud.com.cn. Eso puede parecer suficientemente seguro, pero hay que tener en cuenta que apple.com tiene cientos (si no miles) de subdominios. Si alguno de estos subdominios puede ser engañado para ejecutar JavaScript malicioso, entonces podrían usarse para activar el aviso de inicio de sesión con el client_id de iCloud, permitiendo que ese script recupere el código de concesión del usuario si se autentica. Luego la página puede enviarlo de vuelta a un atacante que puede usarlo para obtener una sesión en icloud.com.

¿Cómo podrían los actores maliciosos obtener acceso?

Algunos ejemplos de cómo podría suceder:

• Una vulnerabilidad de cross-site scripting en cualquier subdominio. Estas se encuentran con bastante regularidad, https://support.apple.com/en-us/HT201536 lista al menos 30 candidatos desde 2019, y eso solo cubre los dominios lo suficientemente importantes para investigar.

• Un subdominio colgante que puede ser tomado por un atacante. Aunque no tengo conocimiento de casos de esto en Apple, recientemente alguien encontró 670 subdominios de microsoft.com disponibles para toma de control: https://nakedsecurity.sophos.com/2020/03/06/researcher-finds-670-microsoft-subdomains-vulnerable-to-takeover/

• Un usuario visitando una página en cualquier subdominio a través de HTTP. Los subdominios importantes tendrán un encabezado HSTS, pero muchos no. El dominio apple.com no está precargado con HSTS con includeSubdomains.

Uso del portal cautivo de Apple

Los dos primeros requieren que el atacante engañe a los usuarios para que visiten la página maliciosa. El tercero requiere que el atacante tenga acceso a la red local del usuario. Aunque tal ataque es en general más difícil, permite un ejemplo muy interesante: captive.apple.com. Cuando un dispositivo Apple se conecta a una red Wi-Fi, intentará acceder a http://captive.apple.com/hotspot-detect.html. Si la respuesta no coincide con la respuesta habitual, entonces el sistema asume que hay un portal cautivo donde el usuario necesitará hacer algo primero. Para permitir que el usuario haga eso, se abre y muestra la página de respuesta. Usualmente, esto redirige al usuario a otra página donde debe iniciar sesión, aceptar términos y condiciones, pagar, etc. Sin embargo, no es necesario que haga eso. En cambio, la página podría incluir JavaScript que active el inicio de sesión con TouchID, lo cual será permitido ya que está en un subdominio de apple.com. Si el usuario se autentica, entonces el JavaScript malicioso recibe el grant_code del usuario.

'Iniciar sesión con Apple'

La página podría incluir todo tipo de contenido para hacer que el usuario sea más propenso a autenticarse, por ejemplo haciendo que la página parezca parte del propio iOS o un botón de “Iniciar sesión con Apple”. “Iniciar sesión con Apple” todavía es bastante nuevo, por lo que los usuarios podrían no notar que el aviso es ligeramente diferente al habitual. Además, muchos usuarios probablemente se autenticarán automáticamente cuando vean un aviso de TouchID, ya que casi siempre se trata de autenticarse en el teléfono; el hecho de que los usuarios también deban determinar si quieren autenticarse en la página que abrió el aviso no se hace evidente.

Respuesta de Apple a nuestra divulgación responsable

Reportamos esta vulnerabilidad a Apple a través de su programa de divulgación responsable, y la corrigieron el mismo día que la evaluaron. La API gsa.apple.com ahora verifica correctamente que el redirect_uri coincida con el client_id. Por lo tanto, esto podría solucionarse completamente del lado del servidor.

Nos parece muy lógico cómo esta vulnerabilidad pudo haber pasado desapercibida: las personas que la prueban probablemente se enfocaron en usar dominios no confiables para el redirect_uri. Por ejemplo, a veces funciona usar https://www.icloud.com.attacker.com o https://attacker.com/https://www.icloud.com. En este caso, ambos fallan, sin embargo, al probar solo esos, se perdería la capacidad de usar un subdominio malicioso.