Mitigación de la suplantación de identidad en OAuth 2.0 (Parte I de II)

OAuth2 es uno de los protocolos de autorización/single sign-on (SSO) más extendidos en Internet sobre el que además se basa el estándar de autenticación OpenID Connect. Es su gran difusión y aceptación lo que provocaría que el descubrimiento de un nuevo vector de ataque contra dicho protocolo tuviera un gran impacto. Hasta la fecha, los análisis realizados sobre OAuth2 basan sus vectores de ataque en las consideraciones de seguridad ya descritas en la propia especificación del protocolo, como por ejemplo, los parámetros que deberían ser saneados por el servidor de autorización como la URL de redirección o la suplantación del usuario.

Figura 1: Mitigación de la suplantación de identidad en OAuth 2.0

Con vistas a mitigar los vectores de ataque conocidos sobre OAuth2, en este trabajo se desarrollará una posible solución basada en mecanismos de identificación de cliente y tokens autocontenidos. Por un lado, los mecanismos de identificación permitirían a un servidor de OAuth2 ser capaz de proteger las credenciales del usuario mediante una autenticación basada en riesgos, y por otro lado, los tokens autocontenidos permitirían que, aunque se hubiesen visto comprometidos en su transmisión o almacenamiento, sólo serían válidos para los clientes para los que fueron emitidos gracias a la información que contienen sobre el cliente identificado.

1.- Introducción

OAuth2  es un protocolo que permite independizar, en entornos distribuidos, la capa de autorización y la separación de roles de clientes y usuarios, de los propios recursos HTTP protegidos. Para gestionar dicha autorización, en vez de utilizar los credenciales del usuario propietario del recurso al que se quiere acceder, un cliente o aplicación de tercero utilizará un token de acceso, es decir, una cadena de caracteres que denota un ámbito de uso, un tiempo de vida y otros atributos de acceso a los recursos protegidos. Estos tokens de acceso son emitidos a dichas aplicaciones de terceros previa autorización del propietario del recurso protegido para que puedan acceder a dicho recurso en su nombre. Esto es lo que se denominaría como autorización delegada.

Figura 2: RFC para discutir OAuth  2.0

Esta autorización delegada obtenida por la aplicación de terceros, al ser concedida bajo previa autorización del usuario propietario del recurso, permite a dicho usuario definir un ámbito de acceso tan reducido como el propio servidor de autorización le permita. Por este motivo, si la aplicación de terceros intenta acceder a otro recurso protegido del usuario fuera del ámbito del token de acceso inicial que se le proporcionó, dicha aplicación necesitará volver a solicitar permiso al usuario final. Esto desmitifica por completo la errónea creencia de que OAuth2 es un protocolo de SSO para autenticación, ya que es necesario reiteradas autenticaciones del usuario final para autorizar el acceso a aplicaciones de terceros a nuevos recursos protegidos fuera del ámbito del token de acceso inicial del que disponían.

Por otro lado, sobre el propio protocolo OAuth2 y fundamentado en las dos premisas que define su RFC 6749:

"los servidores de autorización deberían ignorar cualquier parámetro de las peticiones que no estén reconocidos en la RFC", y "los clientes deberían ignorar cualquier parámetro de las respuestas que no estén reconocidos en la RFC"

se ha construido el protocolo OpenID Connect. Este protocolo si es un protocolo SSO para autenticación y está muy extendido en IdPs (Identity Providers) de Internet como Google, GitHub,  Facebook o Microsoft Office 365 - como se pudo ver en los ataques Sappo "Spear Apps to  Steal OAuth-tokens" -  entre otros. Es importante tener en cuenta el protocolo OpenID Connect a la hora de realizar este estudio, ya que al estar construido sobre el protocolo OAuth2, cualquier nuevo vector de ataque podría repercutir directamente en OpenID Connect. En la Figura 3 se muestra de manera gráfica los módulos que componen el protocolo OpenID Connect incluyendo entre sus pilares, los componentes de la especificación de OAuth2.

Figura 3: Protocolo OpenID Connect

2.- Motivación

El protocolo OAuth2, tanto en su propia RFC 6749 como en la RFC 6819 que define el modelo de riesgos de OAuth2, describe las consideraciones de seguridad a tener en cuenta a la hora de utilizar o implementar un servidor de OAuth2. Entre dichas consideraciones de seguridad podemos encontrar, la recomendación de registrar las URIs de redirección asociadas a cada cliente para evitar redirecciones no controladas gestionadas por ellos mismos o por terceros, la recomendación de que el cliente debería utilizar el parámetro "state" en sus peticiones al servidor de autorización como un token anti-CSRF [A. Barth, C. Jackson, J. C. Mitchell, "Robust defenses for cross-site request forgery", CCS, pp. 75–88, 2008.], y la recomendación de mantener de manera confidencial, tanto durante la comunicación como durante el almacenamiento, los credenciales del usuario así como los tokens emitidos por el servidor de autorización, es decir, los tokens de acceso, los tokens de refresco y los códigos de autorización.

Figura 4: Modelo de riesgos en OAuth 2.0

A lo largo de esta sección se describirán algunos de los vectores de ataque basados en las implementaciones que cada IdP de Internet ha llevado a cabo para cubrir la especificación del protocolo OAuth2. También se describirán los vectores de ataque basados en la propia especificación del protocolo, los cuales son agnósticos de la implementación posterior que se realice.

3.- Vectores de ataque basados en la implementación

Aunque el protocolo defina a priori las consideraciones de seguridad a tener en cuenta, no siempre los servidores que implementan la especificación del protocolo OAuth2 cumplen estas recomendaciones. Un ejemplo lo podemos encontrar en los fallos de seguridad reportados por Egor Homakov y documentados en su blog a los programas de Bug Bounty de Facebook y Github, los cuales son programas que recompensan económicamente a los investigadores que reporten de manera responsable los fallos de seguridad en vez de realizar un uso malicioso de los mismos.

Figura 5: Fallos en OAuth2 utilizados para hackear Facebook

El caso reportado a Facebook se aprovechaba de que la versión de Google Chrome XSS Auditor fugaba la información de "document.referer", es decir, se mostraba la información referida a la URL desde la que se propició la carga de la página actual. A lo anterior se sumaba que Facebook introducía la cabecera HTTP "X-XSS-Protection: '1;mode=block'" para bloquear los ataques de  XSS.

Teniendo en cuenta ambas premisas, si el cliente introducía un XSS en el parámetro "state" de su petición, cuando llegaba la respuesta con el token de acceso al navegador, éste la bloqueaba al tener el "mode=block" y dicha respuesta se redirigía a la página "about:blank" de Google Chrome, mostrando, como se ha comentado, la información de la URL que en este caso contenía el token de acceso. En la Figura 6 se muestra un ejemplo de fuga del token de acceso a través de la cabecera HTTP referer la cual indica la URL desde la que se propició la carga de la página actual.

Figura 6: Fuga de información en la cabecera HTTP

Por otro lado, en el caso reportado a Github, la URL de redirección enviada por el usuario al servidor de autorización no se filtraba de manera adecuada, lo que posibilitaba el vector de ataque de path transversal. Este hecho, sumado a un par más de vulnerabilidades descritas en el caso reportado, permitía a un usuario atacante ganar acceso a recursos de otros usuarios con los mismos permisos que el usuario atacante tenía sobre sus propios recursos protegidos.

Figura 7: Punto 10.4 RFC 6749

Estos fallos de seguridad encontrados en IdPs tan importantes como pueden ser Facebook y Github, podrían haber sido evitados siguiendo las recomendaciones de seguridad descritas en el punto 10.14 de la propia RFC 6749 del protocolo OAuth2, en la cual se define que tanto el servidor de autorización como el cliente deben sanear cualquier valor recibido siempre que sea posible, en particular, el valor de los parámetros "state" y "redirect_uri".

4.- Vectores de ataque basados en la especificación

Aunque los detalles de implementación que provocan las vulnerabilidades son vectores de ataque completamente válidos y reales de las implementaciones del protocolo OAuth2 que actualmente existen en los grandes IdPs de Internet, no se debe pasar por alto los vectores de ataque basados en la especificación del propio protocolo, ya que éstos podrían ser agnósticos de la implementación posterior realizada y conllevar un mayor impacto.

Figura 8: Estudio de la Universidad Trier de Alemania sobre OAuth 2.0

El estudio formal sobre el protocolo OAuth2 llevado a cabo por la Universidad de Trier de Alemania, cuya última versión data de 2016, pone de manifiesto cuatro vectores de ataque no descritos hasta la fecha, los cuales se basan principalmente, en la RFC 6749 del protocolo OAuth2. Dichos vectores de ataque serían los siguientes:

• Redirecciones HTTP 307 

• Fuga de información 

• Gestión "inocente" de la integridad de la sesión por parte del recurso protegido 

• Confusión de IdP

El primer vector de ataque basado en redirecciones HTTP 307 se fundamenta en que ni la RFC 6749 del protocolo OAuth2, ni la RFC 6819 que define el modelo de riesgos de OAuth2 especifican el método exacto de redirección HTTP. El problema de la redirección HTTP 307 radica, como bien se indica en el punto 6.4.7 de la RFC 7231, en que dicha redirección no permite cambiar el método de la petición de POST a GET. Esto quiere decir que si la redirección se produce inmediatamente después de introducir los credenciales del usuario, éstos viajarán en el cuerpo del POST de la redirección hacia donde el navegador sea redirigido.

Figura 9: Redirecciones HTTP Temporales

Por otro lado, la fuga de información, como por ejemplo, el valor del parámetro anti-CSRF "state" o el de los tokens codificados en la URL se basa, del mismo modo que el fallo de seguridad reportado a Facebook detallado en la sección de vectores de ataque basados en la implementación, en una mala configuración de las políticas de la cabecera HTTP referer. Esta mala configuración propicia que si el IdP tuviera enlaces a recursos externos, si el usuario siguiera dichos enlaces, los recursos externos tendrían a su alcance en la cabecera HTTP el valor de los parámetros ya citados, permitiéndoles, por ejemplo, saltare la protección anti-CSRF o robar la sesión o los tokens emitidos por el servidor de autorización.

En cuanto a lo que se denomina gestión "inocente" de la integridad de la sesión por parte del recurso protegido, se refiere a que dicho recurso lleva a cabo un seguimiento del usuario entre una petición y otra, es decir, es un recurso con estado (stateful), pero sin embargo, no realiza comprobaciones de la integridad de la sesión con la que está identificando a dicho usuario. Del mismo modo que pasaba con las redirecciones HTTP 307, ninguna RFC de OAuth2  ya citada, define más allá de la obligación del recurso protegido de validar el token de acceso y comprobar que no está expirado.

Por este motivo, el ataque descrito en el estudio se basa en la suplantación de la sesión de seguimiento emitida por el recurso protegido. Para ello, un atacante comienza una sesión legítima con un IdP con el fin de obtener su token de acceso, haciendo además creer al recurso protegido, que él es su IdP legítimo. Cuando un tercer usuario intente acceder al recurso protegido, éste le redireccionará al IdP del atacante que le devolverá su propia sesión de seguimiento y su token obtenido de manera legítima con el IdP. Esta suplantación provocará que el recurso protegido crea que es propiedad del usuario atacante y no del nuevo usuario.

Por último, el ataque de confusión de IdP es el más complejo y requiere de múltiples asunciones para que se pudiera llevar a cabo. Dicho ataque consistiría en lo que podríamos denominar un servidor OAuth2-in-the-middle, permitiendo al atacante la obtención de la información de los credenciales del usuario, tokens y demás información sensible. En la Figura 10 se muestra el diagrama de flujo del ataque de confusión de IdP extraído del estudio formal sobre OAuth2 llevado a cabo por la Universidad de Trier de Alemania.

Figura 10: Diagrama de flujo del ataque de confusión de IdP

En 2016, Wanpeng Li y Chris J. Mitchell de la Universidad de Londres, realizaron una presentación  en la que demostraban que ciertas de las asunciones del modelo formal descrito para llevar a cabo este ataque no aplican en la práctica y se reafirmaban en que el modelo de seguridad de OAuth2 se construye sobre la confianza del IdP, por lo que si el IdP es malicioso, el sistema al completo de OAuth2 está corrupto. Esta última premisa de que el modelo de seguridad se construye sobre la confianza en el IdP, aplicaría tanto a este ataque de confusión de IdP como al de gestión "inocente" de la integridad de la sesión por parte del recurso protegido descrito en el párrafo anterior.

Figura 11: Does the IdP Mix-Up attack really work?

Los tipos de vectores de ataque descritos en esta sección, basados en la especificación y basados en la implementación, cuya finalidad es romper la autorización, la autenticación o la integridad de sesión, aplican a los flujos de authorization code e implicit descritos en la RFC 6749 del protocolo OAuth2. Como ya se ha mencionado con anterioridad, estos flujos están incluidos en el protocolo OpenID Connect al estar éste construido sobre OAuth2, por lo que dichos vectores de ataque descritos son igualmente válidos sobre el protocolo OpenID Connect.

[Continúa en la Parte II]

Autor: Elias Grande (@3grander) autor del Proyecto ODIN
Graduado en por el Master de Seguridad de la UEM