Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 22:52:06 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/oauth-to-account-takeover.md

19 KiB
Raw Blame History

OAuth para toma de control de cuenta

Aprende hacking en AWS desde cero hasta experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Información Básica

OAuth ofrece varias versiones, con información fundamental accesible en la documentación de OAuth 2.0. Esta discusión se centra principalmente en el ampliamente utilizado tipo de concesión de código de autorización OAuth 2.0, proporcionando un marco de autorización que permite que una aplicación acceda o realice acciones en la cuenta de un usuario en otra aplicación (el servidor de autorización).

Considera un sitio web hipotético https://ejemplo.com, diseñado para mostrar todas tus publicaciones en redes sociales, incluidas las privadas. Para lograr esto, se emplea OAuth 2.0. https://ejemplo.com solicitará tu permiso para acceder a tus publicaciones en redes sociales. En consecuencia, aparecerá una pantalla de consentimiento en https://redessociales.com, describiendo los permisos solicitados y el desarrollador que realiza la solicitud. Tras tu autorización, https://ejemplo.com obtiene la capacidad de acceder a tus publicaciones en tu nombre.

Es esencial comprender los siguientes componentes dentro del marco de OAuth 2.0:

  • propietario de recursos: Tú, como usuario/entidad, autorizas el acceso a tu recurso, como tus publicaciones en redes sociales.
  • servidor de recursos: El servidor que gestiona las solicitudes autenticadas después de que la aplicación ha asegurado un token de acceso en nombre del propietario de recursos, por ejemplo, https://redessociales.com.
  • aplicación cliente: La aplicación que busca autorización del propietario de recursos, como https://ejemplo.com.
  • servidor de autorización: El servidor que emite tokens de acceso a la aplicación cliente tras la autenticación exitosa del propietario de recursos y la obtención de autorización, por ejemplo, https://redessociales.com.
  • client_id: Un identificador público y único para la aplicación.
  • client_secret: Una clave confidencial, conocida únicamente por la aplicación y el servidor de autorización, utilizada para generar tokens de acceso.
  • response_type: Un valor que especifica el tipo de token solicitado, como código.
  • scope: El nivel de acceso que la aplicación cliente está solicitando al propietario de recursos.
  • redirect_uri: La URL a la que se redirige al usuario después de la autorización. Normalmente debe coincidir con la URL de redirección preregistrada.
  • state: Un parámetro para mantener datos a través de la redirección del usuario hacia y desde el servidor de autorización. Su singularidad es fundamental para servir como un mecanismo de protección CSRF.
  • grant_type: Un parámetro que indica el tipo de concesión y el tipo de token que se devolverá.
  • code: El código de autorización del servidor de autorización, utilizado junto con client_id y client_secret por la aplicación cliente para adquirir un token de acceso.
  • access_token: El token que la aplicación cliente utiliza para las solicitudes de API en nombre del propietario de recursos.
  • refresh_token: Permite a la aplicación obtener un nuevo token de acceso sin volver a solicitar al usuario.

Flujo

El flujo real de OAuth procede de la siguiente manera:

  1. Accedes a https://ejemplo.com y seleccionas el botón "Integrar con Redes Sociales".
  2. El sitio luego envía una solicitud a https://redessociales.com solicitando tu autorización para permitir que la aplicación de https://ejemplo.com acceda a tus publicaciones. La solicitud está estructurada de la siguiente manera:
https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123

  1. A continuación, se te presenta una página de consentimiento.

  2. Después de tu aprobación, la Red Social envía una respuesta al redirect_uri con los parámetros code y state:

https://example.com?code=uniqueCode123&state=randomString123
  1. https://example.com utiliza este código, junto con su client_id y client_secret, para realizar una solicitud del lado del servidor y obtener un access_token en tu nombre, lo que permite acceder a los permisos a los que has dado tu consentimiento:
POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
  1. Finalmente, el proceso concluye cuando https://example.com emplea tu access_token para realizar una llamada a la API de Social Media y acceder

Vulnerabilidades

Open redirect_uri

El redirect_uri es crucial para la seguridad en las implementaciones de OAuth y OpenID, ya que dirige hacia dónde se envían los datos sensibles, como códigos de autorización, después de la autorización. Si está mal configurado, podría permitir a los atacantes redirigir estas solicitudes a servidores maliciosos, lo que habilitaría la toma de control de cuentas.

Las técnicas de explotación varían según la lógica de validación del servidor de autorización. Pueden ir desde la coincidencia estricta de rutas hasta la aceptación de cualquier URL dentro del dominio o subdirectorio especificado. Los métodos comunes de explotación incluyen redirecciones abiertas, traversal de rutas, explotación de regex débiles e inyección de HTML para robo de tokens.

Además del redirect_uri, otros parámetros de OAuth y OpenID como client_uri, policy_uri, tos_uri y initiate_login_uri también son susceptibles a ataques de redirección. Estos parámetros son opcionales y su soporte varía entre servidores.

Para aquellos que apuntan a un servidor OpenID, el punto de descubrimiento (**.well-known/openid-configuration**) a menudo lista detalles de configuración valiosos como registration_endpoint, request_uri_parameter_supported y "require_request_uri_registration. Estos detalles pueden ayudar a identificar el punto de registro y otros detalles de configuración del servidor.

XSS en la implementación de redirección

Como se menciona en este informe de recompensa por errores https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html podría ser posible que la URL de redirección se refleje en la respuesta del servidor después de que el usuario se autentique, siendo vulnerable a XSS. Carga útil posible para probar:

https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>

CSRF - Manejo inadecuado del parámetro de estado

En las implementaciones de OAuth, el mal uso u omisión del parámetro state puede aumentar significativamente el riesgo de ataques de falsificación de solicitudes entre sitios (CSRF). Esta vulnerabilidad surge cuando el parámetro state no se utiliza, se utiliza como un valor estático o no se valida correctamente, lo que permite a los atacantes evadir las protecciones CSRF.

Los atacantes pueden explotar esto interceptando el proceso de autorización para vincular su cuenta con la cuenta de una víctima, lo que puede llevar a posibles tomas de control de cuentas. Esto es especialmente crítico en aplicaciones donde se utiliza OAuth con fines de autenticación.

Se han documentado ejemplos del mundo real de esta vulnerabilidad en varios desafíos de CTF y plataformas de hacking, resaltando sus implicaciones prácticas. El problema también se extiende a integraciones con servicios de terceros como Slack, Stripe y PayPal, donde los atacantes pueden redirigir notificaciones o pagos a sus cuentas.

El manejo adecuado y la validación del parámetro state son cruciales para protegerse contra CSRF y asegurar el flujo de OAuth.

Antes de la toma de control de cuentas

  1. Sin verificación de correo electrónico en la creación de cuentas: Los atacantes pueden crear anticipadamente una cuenta utilizando el correo electrónico de la víctima. Si la víctima luego utiliza un servicio de terceros para iniciar sesión, la aplicación podría vincular inadvertidamente esta cuenta de terceros a la cuenta precreada del atacante, lo que lleva a un acceso no autorizado.

  2. Explotando la laxa verificación de correo electrónico de OAuth: Los atacantes pueden explotar servicios de OAuth que no verifican correos electrónicos registrándose con su servicio y luego cambiando el correo electrónico de la cuenta al de la víctima. Este método también conlleva riesgos de acceso no autorizado a la cuenta, similar al primer escenario pero a través de un vector de ataque diferente.

Divulgación de secretos

Identificar y proteger los parámetros secretos de OAuth es crucial. Mientras que el client_id puede divulgarse de forma segura, revelar el client_secret plantea riesgos significativos. Si el client_secret se ve comprometido, los atacantes pueden explotar la identidad y confianza de la aplicación para robar los access_tokens e información privada.

Una vulnerabilidad común surge cuando las aplicaciones manejan erróneamente el intercambio del code de autorización por un access_token en el lado del cliente en lugar del lado del servidor. Este error conduce a la exposición del client_secret, lo que permite a los atacantes generar access_tokens bajo la apariencia de la aplicación. Además, a través de la ingeniería social, los atacantes podrían aumentar privilegios agregando alcances adicionales a la autorización de OAuth, explotando aún más el estado de confianza de la aplicación.

Fuerza bruta del secreto del cliente

Puedes intentar fuerza bruta del client_secret de un proveedor de servicios con el proveedor de identidad para intentar robar cuentas.
La solicitud para la fuerza bruta puede ser similar a:

POST /token HTTP/1.1
content-type: application/x-www-form-urlencoded
host: 10.10.10.10:3000
content-length: 135
Connection: close

code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce]

Referer Header filtrando Código + Estado

Una vez que el cliente tiene el código y el estado, si se refleja dentro del encabezado Referer cuando navega a una página diferente, entonces es vulnerable.

Token de Acceso Almacenado en el Historial del Navegador

Ve al historial del navegador y verifica si el token de acceso está guardado allí.

Código de Autorización Eterno

El código de autorización debería existir solo por un tiempo limitado para reducir la ventana de tiempo en la que un atacante puede robarlo y usarlo.

Token de Autorización/Actualización no vinculado al cliente

Si puedes obtener el código de autorización y usarlo con un cliente diferente, entonces puedes tomar el control de otras cuentas.

Rutas Felices, XSS, Iframes y Mensajes Post para filtrar códigos y valores de estado

Revisa esta publicación

AWS Cognito

En este informe de recompensa por errores: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ puedes ver que el token que AWS Cognito devuelve al usuario podría tener suficientes permisos para sobrescribir los datos del usuario. Por lo tanto, si puedes cambiar el correo electrónico del usuario por un correo electrónico de otro usuario, podrías apoderarte de otras cuentas.

# Read info of the user
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]

# Change email address
aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ[...] --user-attributes Name=email,Value=imaginary@flickr.com
{
"CodeDeliveryDetailsList": [
{
"Destination": "i***@f***.com",
"DeliveryMedium": "EMAIL",
"AttributeName": "email"
}
]
}

Abusando de tokens de otras aplicaciones

Como se menciona en este artículo, los flujos de OAuth que esperan recibir el token (y no un código) podrían ser vulnerables si no verifican que el token pertenezca a la aplicación.

Esto se debe a que un atacante podría crear una aplicación compatible con OAuth e iniciar sesión con Facebook (por ejemplo) en su propia aplicación. Luego, una vez que una víctima inicia sesión con Facebook en la aplicación del atacante, el atacante podría obtener el token de OAuth del usuario otorgado a su aplicación y usarlo para iniciar sesión en la aplicación de OAuth de la víctima utilizando el token de usuario de la víctima.

{% hint style="danger" %} Por lo tanto, si el atacante logra que el usuario acceda a su propia aplicación de OAuth, podrá tomar el control de la cuenta de la víctima en aplicaciones que esperan un token y no verifican si el token fue otorgado a su ID de aplicación. {% endhint %}

Dos enlaces y cookie

Según este artículo, era posible hacer que una víctima abriera una página con un returnUrl que apuntara al host del atacante. Esta información se almacenaría en una cookie (RU) y en un paso posterior, el prompt le preguntará al usuario si desea dar acceso a ese host del atacante.

Para evitar este prompt, era posible abrir una pestaña para iniciar el flujo de OAuth que establecería esta cookie RU utilizando el returnUrl, cerrar la pestaña antes de que se muestre el prompt y abrir una nueva pestaña sin ese valor. Entonces, el prompt no informará sobre el host del atacante, pero la cookie se establecerá en él, por lo que el token se enviará al host del atacante en la redirección.

Parámetros de SSRFs

Consulta esta investigación para más detalles sobre esta técnica.

El Registro Dinámico de Clientes en OAuth sirve como un vector menos obvio pero crítico para vulnerabilidades de seguridad, específicamente para ataques de Falsificación de Solicitudes del Lado del Servidor (SSRF). Este punto final permite a los servidores de OAuth recibir detalles sobre las aplicaciones cliente, incluidas URL sensibles que podrían ser explotadas.

Puntos Clave:

  • El Registro Dinámico de Clientes a menudo se mapea a /register y acepta detalles como client_name, client_secret, redirect_uris y URLs para logotipos o Conjuntos de Claves Web JSON (JWKs) a través de solicitudes POST.
  • Esta característica se adhiere a las especificaciones establecidas en RFC7591 y OpenID Connect Registration 1.0, que incluyen parámetros potencialmente vulnerables a SSRF.
  • El proceso de registro puede exponer inadvertidamente a los servidores a SSRF de varias maneras:
  • logo_uri: Una URL para el logotipo de la aplicación cliente que podría ser recuperado por el servidor, desencadenando SSRF o llevando a XSS si la URL se maneja incorrectamente.
  • jwks_uri: Una URL al documento JWK del cliente, que si se crea maliciosamente, puede hacer que el servidor realice solicitudes salientes a un servidor controlado por el atacante.
  • sector_identifier_uri: Hace referencia a una matriz JSON de redirect_uris, que el servidor podría recuperar, creando una oportunidad de SSRF.
  • request_uris: Enumera los URIs de solicitud permitidos para el cliente, que pueden ser explotados si el servidor recupera estos URIs al inicio del proceso de autorización.

Estrategia de Explotación:

  • Se puede desencadenar SSRF registrando un nuevo cliente con URLs maliciosas en parámetros como logo_uri, jwks_uri o sector_identifier_uri.
  • Mientras que la explotación directa a través de request_uris puede ser mitigada por controles de lista blanca, suministrar un request_uri preregistrado y controlado por el atacante puede facilitar SSRF durante la fase de autorización.

Condiciones de Carrera en proveedores de OAuth

Si la plataforma que estás probando es un proveedor de OAuth, lee esto para probar posibles Condiciones de Carrera.

Referencias

Aprende hacking en AWS desde cero hasta experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks: