coelner/hacktricks
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
63bd9641c0
hacktricks/pentesting-web/hacking-with-cookies
History
carlospolop 63bd9641c0 f
2023-06-05 20:33:24 +02: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 f 2023-06-05 20:33:24 +02:00

README.md

Hacking de Cookies

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

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 (utiliza esto, ya no estamos en 2009).

Dominio

El atributo Domain especifica qué hosts pueden recibir una cookie. Si no se especifica, el atributo se establece por defecto en 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 el atributo domain de .example.com, se enviará en solicitudes al dominio principal.

Ruta

El atributo Path indica una ruta URL que debe existir en la URL solicitada para enviar la cabecera Cookie. El carácter %x2F ("/") se considera un separador de directorios, y también se corresponden con subdirectorios.

Orden

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

  • La que tiene la ruta más larga que coincide con la ruta de la URL.
  • La más reciente si ambas tienen la misma ruta.

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 de 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
Enlace <a href="..."></a> No establecido*, Lax, None
Prerender <link rel="prerender" href=".."/> No establecido*, Lax, None
Formulario GET <form method="GET" action="..."> No establecido*, Lax, None
Formulario POST <form method="POST" action="..."> No establecido*, None
iframe <iframe src="..."></iframe> No establecido*, None
AJAX $.get("...") No establecido*, None
Imagen <img src="..."> NetSet*, None

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

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

Flags de Cookies

HttpOnly

Esto evita que el cliente acceda a la cookie (por ejemplo, a través de Javascript: document.cookie)

Bypasses

  • Si la página está enviando las cookies como respuesta de una solicitud (por ejemplo, en una página de PHPinfo), es posible abusar del XSS para enviar una solicitud a esta página y robar las cookies de la respuesta (comprueba un ejemplo en https://hackcommander.github.io/pentesting-article-1/)
  • Esto podría ser evadido 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 se evita por los navegadores modernos al no permitir el envío de una solicitud TRACE desde JS. Sin embargo, se han encontrado algunas formas de evadir 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
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 con nombre vacío, resultará en el encabezado de cookie enviado:

a=b;

Significa que cada servidor web lo interpretará como si la cookie a estuviera establecida con el valor b.

Bug de Chrome - corrupción de document.cookie

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

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

Contrabando de Cookies

Se ha descubierto que varios servidores web, incluyendo los servidores Java Jetty, TomCat, Undertow y el framework web de Python Zope, así como los servidores/frameworks web de Python como cherrypy, web.py, aiohttp server, bottle y webob, analizan incorrectamente las cadenas de cookies debido al soporte restante para RFC2965, un mecanismo de citas de cookies obsoleto que utiliza RFC2616 para una definición de 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 comas deben separar los 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 interpretan las cookies como parte de un único valor de cookie en lugar de tres cookies separadas.

Esto conduce a un riesgo de seguridad: si un atacante obtiene acceso de scripting entre sitios (XSS), puede utilizar este error para filtrar cookies sensibles como las cookies HttpOnly.

Inyección de Cookies

Se ha descubierto que muchos servidores web, incluyendo Undertow de Java, 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 de nombre/valor de cookie. Esto permite a un atacante falsificar múltiples cookies mientras controla solo un valor de 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 SimpleCookie y BaseCookie de Python inmediatamente comienzan 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, servidor aiohttp, bottle y webob (Pyramid, TurboGears) son vulnerables a este tipo de ataque.

Este problema presenta importantes 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 evitar esta protección. Además, el último nombre de cookie duplicado en los paquetes de cookies http de Python anula cualquier nombre anterior, lo que hace que este tipo de ataque sea especialmente fácil.

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

Comprobaciones adicionales de vulnerabilidad de cookies

Comprobaciones básicas

  • La cookie es la misma cada vez que inicia sesión.
  • Cierre la sesión e intente usar la misma cookie.
  • Intente iniciar sesión con 2 dispositivos (o navegadores) en la misma cuenta usando la misma cookie.
  • Verifique si la cookie tiene alguna información y trate de modificarla.
  • Intente crear varias cuentas con nombres de usuario casi iguales y verifique si puede ver similitudes.
  • Verifique la opción "recordarme" si existe para ver cómo funciona. Si existe y podría ser vulnerable, siempre use la cookie de recordarme sin ninguna otra cookie.
  • Verifique si la cookie anterior funciona incluso después de cambiar la contraseña.

Ataques avanzados de cookies

Si la cookie sigue siendo la misma (o casi la misma) cuando inicia sesión, esto probablemente significa que la cookie está relacionada con algún campo de su cuenta (probablemente el nombre de usuario). Entonces puedes:

  • Intente crear muchas cuentas con nombres de usuario muy similares e intente adivinar cómo funciona el algoritmo.
  • Intente atacar por fuerza bruta el nombre de usuario. Si la cookie se guarda solo como un método de autenticación para su nombre de usuario, entonces puede crear una cuenta con el nombre de usuario "Bmin" y atacar por fuerza bruta cada bit de su cookie porque una de las cookies que intentará será la que pertenece a "admin".
  • Intente Padding Oracle (puede descifrar el contenido de la cookie). Use 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 (esto puede tardar varios minutos).

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

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

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

CBC-MAC

Tal vez una cookie podría tener algún valor y podría ser firmada usando CBC. Entonces, la integridad del valor es la firma creada usando 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. Obtener la firma del nombre de usuario administ = t
  2. Obtener la firma del nombre de usuario rator\x00\x00\x00 XOR t = t'
  3. Establecer 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á encriptada usando ECB podría ser vulnerable.
Cuando inicias sesión, la cookie que recibes tiene que ser siempre la misma.

Cómo detectar y atacar:

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

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

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

Referencias

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥