Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/hacking-with-cookies
History
Translator 89a1b82bec Translated ['pentesting-web/deserialization/nodejs-proto-prototype-pollu
2024-01-01 18:33:30 +00:00
..
cookie-bomb.md f 2023-06-05 20:33:24 +02:00
cookie-jar-overflow.md f 2023-06-05 20:33:24 +02:00
cookie-tossing.md f 2023-06-05 20:33:24 +02:00
README.md Translated ['pentesting-web/deserialization/nodejs-proto-prototype-pollu 2024-01-01 18:33:30 +00:00

README.md

Hacking de Cookies

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Encuentra vulnerabilidades que importan más para que puedas arreglarlas más rápido. Intruder rastrea tu superficie de ataque, realiza escaneos proactivos de amenazas, encuentra problemas en todo tu stack tecnológico, desde APIs hasta aplicaciones web y sistemas en la nube. Pruébalo gratis hoy.

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}

Atributos de Cookies

Expires & Max-Age

  • Expires establece una fecha de caducidad para cuando se elimina una cookie
  • Max-age establece el tiempo en segundos para cuando se eliminará una cookie (usa esto, ya no estamos en 2009)

Domain

El atributo Domain especifica qué hosts pueden recibir una cookie. Si no se especifica, el atributo por defecto es el mismo host que estableció la cookie, excluyendo subdominios. Si se especifica Domain, entonces los subdominios siempre están incluidos. Por lo tanto, especificar Domain es menos restrictivo que omitirlo. Sin embargo, puede ser útil cuando los subdominios necesitan compartir información sobre un usuario.

Por ejemplo, si estableces Domain=mozilla.org, las cookies están disponibles en subdominios como developer.mozilla.org. Pero si no lo haces, la cookie no se enviará a subdominios.

Si un subdominio sub.example.com establece una cookie con atributo domain de .example.com, se enviará en solicitudes al dominio principal.

Path

El atributo Path indica un camino URL que debe existir en la URL solicitada para enviar el encabezado Cookie. El carácter %x2F ("/") se considera un separador de directorios, y los subdirectorios también coinciden.

Orden

Cuando 2 cookies tienen el mismo nombre, la que se envía es:

  • La que tiene el camino más largo que coincide con el camino URL
  • La más nueva si ambas tienen el mismo camino

SameSite

Esto indicará al navegador si la cookie puede ser enviada desde otros dominios. Tiene 3 valores posibles:

  • Strict: La cookie no se enviará junto con una solicitud por sitios web de terceros.
  • Lax: La cookie se enviará junto con la solicitud GET iniciada por sitios web de terceros.
  • None: La cookie se envía desde cualquier dominio de terceros
Tipo de Solicitud Código de Ejemplo Cookies Enviadas Cuando
Link <a href="..."></a> NotSet*, Lax, None
Prerender <link rel="prerender" href=".."/> NotSet*, Lax, None
Form GET <form method="GET" action="..."> NotSet*, Lax, None
Form POST <form method="POST" action="..."> NotSet*, None
iframe <iframe src="..."></iframe> NotSet*, None
AJAX $.get("...") NotSet*, None
Imagen <img src="..."> NetSet*, None

Tabla de Invicti y ligeramente modificada.
Una cookie con atributo SameSite mitigará ataques CSRF donde se necesita una sesión iniciada.

*Nota que desde Chrome80 (feb/2019) el comportamiento por defecto de una cookie sin un atributo samesite será lax (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/).
Nota que temporalmente, después de aplicar este cambio, las cookies sin una política SameSite en Chrome serán tratadas como None durante los primeros 2 minutos y luego como Lax para solicitudes POST de nivel superior entre sitios.

Banderas de Cookies

HttpOnly

Esto evita que el cliente acceda a la cookie (Por ejemplo, mediante Javascript: document.cookie)

Bypasses

  • Si la página está enviando las cookies como respuesta de una solicitud (por ejemplo, en una página PHPinfo), es posible abusar del XSS para enviar una solicitud a esta página y robar las cookies de la respuesta (consulta un ejemplo en https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/).
  • Esto podría ser evitado con solicitudes HTTP TRACE ya que la respuesta del servidor (si este método HTTP está disponible) reflejará las cookies enviadas. Esta técnica se llama Cross-Site Tracking.
  • Esta técnica es evitada por navegadores modernos al no permitir enviar una solicitud TRACE desde JS. Sin embargo, se han encontrado algunos bypasses a esto en software específico como enviar \r\nTRACE en lugar de TRACE a IE6.0 SP2.
  • Otra forma es la explotación de vulnerabilidades zero/day de los navegadores.
  • Es posible sobrescribir cookies HttpOnly realizando un ataque de desbordamiento de Cookie Jar:

{% content-ref url="cookie-jar-overflow.md" %} cookie-jar-overflow.md {% endcontent-ref %}

Secure

La solicitud solo enviará la cookie en una solicitud HTTP si la solicitud se transmite a través de un canal seguro (típicamente HTTPS).

Prefijos de Cookies

__Secure- prefijo: debe establecerse con la bandera secure desde una página segura (HTTPS).

__Host- prefijo: debe establecerse con la bandera secure, debe ser de una página segura (HTTPS), no debe tener un dominio especificado (y por lo tanto, no se envían a subdominios), y el camino debe ser /.

Las cookies con prefijo __Host- no pueden enviarse a superdominios (cookies de subdominios a dominios) o subdominios (cookies de dominios a subdominios), por lo tanto, si quieres aislar las cookies de tu aplicación, prefijar todo con __Host- no es una mala idea.

Ataques con Cookies

Si encuentras algún tipo de cookie personalizada que contenga datos sensibles (sessionID, nombre de usuario, correos electrónicos, etc.) definitivamente deberías intentar explotarla

Decodificación de la cookie

Si la cookie está utilizando algún cifrado Base (como Base64) o similar, podrías ser capaz de decodificarla, cambiar el contenido e impersonar usuarios arbitrarios.

Secuestro de Sesión

Robar una cookie y usarla para impersonar al usuario dentro de una aplicación

Fijación de Sesión

El atacante obtiene una cookie de una página web y envía un enlace a la víctima para iniciar sesión usando la misma cookie. Si la cookie no cambia cuando un usuario inicia sesión, esto podría ser útil porque el atacante podría ser capaz de impersonar al usuario a través de una cookie.

Si encontraste un XSS en un subdominio o controlas un subdominio, lee:

{% content-ref url="cookie-tossing.md" %} cookie-tossing.md {% endcontent-ref %}

Donación de Sesión

El atacante envía su propia sesión a la víctima. La víctima verá que ya ha iniciado sesión y supondrá que está dentro de su cuenta, pero las acciones se realizarán dentro de la cuenta del atacante.

Si encontraste un XSS en un subdominio o controlas un subdominio, lee:

{% content-ref url="cookie-tossing.md" %} cookie-tossing.md {% endcontent-ref %}

JWT Cookie

Haz clic en el enlace anterior para acceder a una página que explica posibles fallos en JWT.

Cookie Vacía

Los navegadores permiten una cookie con un nombre vacío

document.cookie = "a=v1"
document.cookie = "=test value;" // empty name
document.cookie = "b=v2"

Esto resulta en la cabecera de cookie enviada:

a=v1; test value; b=v2;

Más interesante aún, si tienes un vector que de alguna manera te permite establecer la cookie vacía, puedes controlar cualquier otra cookie:

function setCookie(name, value) {
document.cookie = `${name}=${value}`;
}

setCookie("", "a=b"); // this sets the empty cookie to a=b

Aunque internamente en el navegador, esto se establece como la cookie nombrada vacía, resultará en el encabezado de cookie enviado:

a=b;

Bug de Chrome - corrupción de document.cookie

Si un punto de código sustituto unicode está en una cookie establecida, document.cookie se corromperá permanentemente y devolverá una cadena vacía.

document.cookie
// "a=b;"
document.cookie = "\ud800=meep";
document.cookie
// ""

Contrabando de Cookies

Varios servidores web, incluyendo servidores Java como Jetty, TomCat, Undertow, y el framework web de Python Zope, así como servidores/frameworks web de Python como cherrypy, web.py, aiohttp server, bottle y webob, se han encontrado con que interpretan incorrectamente las cadenas de cookies debido al soporte obsoleto para RFC2965, un mecanismo de citación de cookies anticuado que utiliza RFC2616 para la definición de una cadena entre comillas.

Específicamente, estos servidores continúan leyendo una cadena de cookies cuando encuentran un valor de cookie entre comillas dobles (dquoted), incluso si se encuentra un punto y coma. Esto es problemático porque los puntos y coma se supone que separan pares clave-valor en la cadena de cookies.

Por ejemplo, si un navegador envía tres cookies, RENDER_TEXT, JSESSIONID, y ASDF:

RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";

estos servidores los interpretan como parte de un valor de cookie único en lugar de tres cookies separadas.

Esto conlleva un riesgo de seguridad: si un atacante obtiene acceso a scripting entre sitios (XSS), pueden usar este error para exfiltrar cookies sensibles como las cookies HttpOnly.

Inyección de Cookies

Se ha descubierto que muchos servidores web, incluyendo el Undertow de Java, el Zope de Python y aquellos que utilizan http.cookie.SimpleCookie y http.cookie.BaseCookie de la biblioteca estándar de Python, analizan incorrectamente las cookies, utilizando delimitadores incorrectos para iniciar el siguiente par nombre/valor de cookie. Esto permite a un atacante falsificar múltiples cookies mientras solo controla el valor de una cookie.

En el caso de Undertow, comienza a analizar la siguiente cookie inmediatamente después del final de un valor de cookie entre comillas, sin esperar un punto y coma:

LANGUAGE="en-us" CSRF_TOKEN="SPOOFED_VALUE"

Zope comienza a analizar la siguiente cookie en una coma:

LANGUAGE=en-us,CSRF_TOKEN=SPOOFED_VALUE

Y Python's SimpleCookie y BaseCookie comienzan inmediatamente a analizar la siguiente cookie en un carácter de espacio:

LANGUAGE=en-us CSRF_TOKEN=SPOOFED_VALUE

Como resultado, servidores como cherrypy, web.py, aiohttp server, bottle y webob (Pyramid, TurboGears) son todos vulnerables a este tipo de ataque.

Este problema presenta significativas implicaciones de seguridad. Por ejemplo, si una aplicación web utiliza protección CSRF basada en cookies, un atacante puede inyectar una cookie de token CSRF falsificada para eludir esta protección. Además, el último nombre de cookie duplicado en los paquetes http.cookie de Python anula cualquier otro anterior, lo que facilita especialmente este tipo de ataque.

Además, el spoofing de cookies __Secure- y __Host- puede ser abusado en un contexto inseguro. También, en una configuración donde las cookies se pasan a un servidor backend, la inyección de cookies podría llevar a elusiones de autorización si el servidor backend es susceptible al spoofing pero el servidor frontend no lo es.

Verificaciones de Cookies Extra Vulnerables

Verificaciones básicas

  • La cookie es igual cada vez que haces login.
  • Cierra sesión e intenta usar la misma cookie.
  • Intenta iniciar sesión con 2 dispositivos (o navegadores) en la misma cuenta usando la misma cookie.
  • Verifica si la cookie tiene alguna información y trata de modificarla.
  • Intenta crear varias cuentas con nombres de usuario casi iguales y verifica si puedes ver similitudes.
  • Verifica la opción de "recuérdame" si existe para ver cómo funciona. Si existe y podría ser vulnerable, siempre usa la cookie de recuérdame sin ninguna otra cookie.
  • Verifica si la cookie anterior funciona incluso después de cambiar la contraseña.

Ataques avanzados con cookies

Si la cookie permanece igual (o casi) cuando inicias sesión, esto probablemente significa que la cookie está relacionada con algún campo de tu cuenta (probablemente el nombre de usuario). Entonces puedes:

  • Intentar crear muchas cuentas con nombres de usuario muy similares e intentar adivinar cómo funciona el algoritmo.
  • Intentar fuerza bruta en el nombre de usuario. Si la cookie se guarda solo como un método de autenticación para tu nombre de usuario, entonces puedes crear una cuenta con el nombre de usuario "Bmin" y fuerza bruta cada bit de tu cookie porque una de las cookies que intentarás será la que pertenece a "admin".
  • Intentar Padding Oracle (puedes descifrar el contenido de la cookie). Usa padbuster.

Padding Oracle - Ejemplos de Padbuster

padbuster <URL/path/when/successfully/login/with/cookie> <COOKIE> <PAD[8-16]>
# When cookies and regular Base64
padbuster http://web.com/index.php u7bvLewln6PJPSAbMb5pFfnCHSEd6olf 8 -cookies auth=u7bvLewln6PJPSAbMb5pFfnCHSEd6olf

# If Base64 urlsafe or hex-lowercase or hex-uppercase --encoding parameter is needed, for example:
padBuster http://web.com/home.jsp?UID=7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6
7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 8 -encoding 2

Padbuster realizará varios intentos y te preguntará cuál es la condición de error (la que no es válida).

Luego comenzará a descifrar la cookie (puede tardar varios minutos)

Si el ataque se ha realizado con éxito, entonces podrías intentar cifrar una cadena de tu elección. Por ejemplo, si quisieras cifrar user=administrator

padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator

Esta ejecución te dará la cookie correctamente cifrada y codificada con la cadena user=administrator dentro.

CBC-MAC

Quizás una cookie podría tener algún valor y podría estar firmada usando CBC. Entonces, la integridad del valor es la firma creada al usar CBC con el mismo valor. Como se recomienda usar como IV un vector nulo, este tipo de verificación de integridad podría ser vulnerable.

El ataque

  1. Obtén la firma del nombre de usuario administ = t
  2. Obtén la firma del nombre de usuario rator\x00\x00\x00 XOR t = t'
  3. Establece en la cookie el valor administrator+t' (t' será una firma válida de (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00

ECB

Si la cookie está cifrada usando ECB, podría ser vulnerable.
Cuando inicias sesión, la cookie que recibes siempre debe ser la misma.

Cómo detectar y atacar:

Crea 2 usuarios con datos casi idénticos (nombre de usuario, contraseña, correo electrónico, etc.) e intenta descubrir algún patrón dentro de la cookie dada.

Crea un usuario llamado, por ejemplo, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" y verifica si hay algún patrón en la cookie (como ECB cifra con la misma clave cada bloque, los mismos bytes cifrados podrían aparecer si el nombre de usuario está cifrado).

Debería haber un patrón (con el tamaño de un bloque utilizado). Entonces, sabiendo cómo se cifra un montón de "a", puedes crear un nombre de usuario: "a"*(tamaño del bloque)+"admin". Luego, podrías eliminar el patrón cifrado de un bloque de "a" de la cookie. Y tendrás la cookie del nombre de usuario "admin".

Referencias

Encuentra vulnerabilidades que importan más para que puedas solucionarlas más rápido. Intruder rastrea tu superficie de ataque, realiza escaneos proactivos de amenazas, encuentra problemas en todo tu stack tecnológico, desde APIs hasta aplicaciones web y sistemas en la nube. Pruébalo gratis hoy.

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks: