- Salt Labs descubrió que, a través de vulnerabilidades en implementaciones de OAuth, era posible secuestrar cuentas en servicios masivos usados por cientos de millones de personas, como Booking.com, Grammarly, Vidio y Bukalapak, así como en el framework móvil Expo.
- OAuth es en esencia un protocolo seguro, pero según cómo se implemente pueden aparecer vulnerabilidades críticas.
- Booking.com
- En la implementación de Facebook OAuth había un problema que permitía cambiar
redirect_uri a otra ruta dentro del mismo host.
- Dentro de booking.com existe un endpoint que redirige a la dirección indicada si se le proporciona una dirección en formato base64.
- Al combinar ambos, era posible manipular el flujo para que el token de OAuth terminara enlazado a otra dirección.
- En la versión web no existía la vulnerabilidad porque durante el inicio de sesión se validaba
redirect_uri, pero en la versión móvil también se podía manipular redirect_uri, lo que hacía posible el secuestro de cuentas.
- Es decir, era una vulnerabilidad en la que un usuario hacía clic en un enlace que parecía completamente legítimo y, al completar OAuth normalmente, su cuenta era secuestrada.
- Expo
- Vulnerabilidad encontrada en la implementación integrada de OAuth del framework móvil Expo.
- En esa implementación,
returnUrl debía contener un enlace exclusivo de la app Expo como exp://~~, pero existía un problema que permitía poner una dirección web como hTTps://~~.
- Aunque
https:// estaba bloqueado, bastaba cambiar mayúsculas y minúsculas para evadir la restricción.
- Entonces la información de
returnUrl se guardaba en una cookie llamada RU, y cuando OAuth terminaba, el servidor OAuth de Expo leía esa cookie y redirigía a esa ubicación.
- Sin embargo, antes de pasar de Expo a Facebook aparecía una advertencia del tipo
si confías en https://~~..., que el usuario debía aceptar.
- Para evadirlo, se usó un método que abría automáticamente 2 enlaces.
- Se abría y cerraba de inmediato el primer enlace para configurar solo la cookie
RU.
- El segundo enlace proporcionaba directamente el enlace de Facebook OAuth para ignorar el mensaje de advertencia de
RU.
- Con este método lograron secuestrar una cuenta de Codecademy.com.
- La vulnerabilidad recibió el identificador CVE-2023-28131, y el equipo de Expo corrigió el problema pocas horas después del primer reporte.
- Grammarly, Vidio, Bukalapak
- En los tres sitios era posible secuestrar cuentas mediante el mismo método.
- Primero se creaba un sitio web legítimo para recolectar tokens de inicio de sesión de Facebook.
- Después, en Vidio y Bukalapak, si se entregaba un token emitido por Facebook (generado para otro sitio web), el inicio de sesión se completaba sin problemas.
- La vulnerabilidad ocurría porque no verificaban el App ID del token de Facebook. (ataque de reutilización de token)
- Grammarly era un poco distinto y usaba un código en lugar de un token, así que no tenía esa vulnerabilidad.
- Pero confirmaron que, si en la API que enviaba el código se proporcionaba un token con el nombre
"access_token" en lugar de "code", el inicio de sesión también funcionaba.
- Por lo tanto, en los tres sitios bastaba con vincular Facebook en otro sitio legítimo para que la cuenta pudiera ser secuestrada de inmediato.
- Al implementar OAuth, es necesario revisar cuidadosamente los puntos donde pueden surgir vulnerabilidades de seguridad y validar con detalle cada paso del proceso para prevenirlas.
3 comentarios
Da para estar alerta. De verdad hay que tener muchísimo cuidado.
Parece que, más de lo que uno imagina, muchos sitios enormes tenían bastantes vulnerabilidades.
Definitivamente parece una función que hay que manejar con mucho cuidado.
También me hace pensar que habría que usar una librería de autenticación...,
pero viendo el caso de Expo, también creo que incluso eso necesita validación por cuenta propia.