Español - Ht
HackTricks Training Twitter Linkedin Sponsor

Cookies Hacking

Aprende a hackear AWS desde cero hasta convertirte en un experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Grupo de Seguridad Try Hard

Atributos de las Cookies

Las cookies vienen con varios atributos que controlan su comportamiento en el navegador del usuario. Aquí tienes una descripción de estos atributos en una voz más pasiva:

Caduca y Max-Age

La fecha de caducidad de una cookie está determinada por el atributo Expires. Por otro lado, el atributo Max-age define el tiempo en segundos hasta que una cookie se elimina. Opta por Max-age ya que refleja prácticas más modernas.

Dominio

Los hosts que reciben una cookie están especificados por el atributo Domain. Por defecto, esto se establece en el host que emitió la cookie, sin incluir sus subdominios. Sin embargo, cuando se establece explícitamente el atributo Domain, también abarca los subdominios. Esto hace que la especificación del atributo Domain sea una opción menos restrictiva, útil para escenarios donde es necesaria la compartición de cookies entre subdominios. Por ejemplo, establecer Domain=mozilla.org hace que las cookies sean accesibles en sus subdominios como developer.mozilla.org.

Ruta

Una ruta URL específica que debe estar presente en la URL solicitada para que se envíe el encabezado Cookie está indicada por el atributo Path. Este atributo considera el carácter / como un separador de directorios, permitiendo coincidencias en subdirectorios también.

Reglas de Orden

Cuando dos cookies tienen el mismo nombre, la elección de cuál enviar se basa en:

  • La cookie que coincide con la ruta más larga en la URL solicitada.

  • La cookie más recientemente establecida si las rutas son idénticas.

SameSite

  • El atributo SameSite dicta si las cookies se envían en solicitudes originadas desde dominios de terceros. Ofrece tres configuraciones:

  • Strict: Restringe que la cookie se envíe en solicitudes de terceros.

  • Lax: Permite que la cookie se envíe con solicitudes GET iniciadas por sitios web de terceros.

  • None: Permite que la cookie se envíe desde cualquier dominio de terceros.

Recuerda que al configurar cookies, comprender estos atributos puede ayudar a garantizar que se comporten como se espera en diferentes escenarios.

Tabla de Invicti y ligeramente modificada. Una cookie con el atributo SameSite ayudará a mitigar 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 será laxo (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 solicitudes POST entre sitios de nivel superior.

Banderas de las Cookies

HttpOnly

Esto evita que el cliente acceda a la cookie (por ejemplo, a través de Javascript con 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 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 de Cookie Jar:

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 las Cookies

Las cookies con prefijo __Secure- deben ser establecidas junto con la bandera secure en páginas que están aseguradas por HTTPS.

Para las cookies con prefijo __Host-, se deben cumplir varias condiciones:

  • Deben ser establecidas con la bandera secure.

  • Deben originarse desde una página asegurada por HTTPS.

  • Se prohíbe especificar un dominio para estas cookies, evitando su transmisión a subdominios.

  • La ruta para estas cookies debe establecerse en /.

Es importante tener en cuenta que las cookies con prefijo __Host- no están permitidas para ser enviadas a superdominios o subdominios. Esta restricción ayuda a aislar las cookies de la aplicación. Por lo tanto, utilizar el prefijo __Host- para todas las cookies de la aplicación puede considerarse una buena práctica para mejorar la seguridad y el aislamiento.

Sobrescribiendo cookies

Entonces, una de las protecciones de las cookies con prefijo __Host- es evitar que sean sobrescritas desde subdominios. Previniendo, por ejemplo, ataques de Cookie Tossing. En la charla Cookie Crumbles: Revelando Vulnerabilidades de Integridad de Sesión Web (documento) se presenta que era posible establecer cookies con prefijo __HOST- desde subdominios, engañando al analizador, por ejemplo, agregando "=" al principio o al principio y al final...:

O en PHP era posible agregar otros caracteres al principio del nombre de la cookie que iban a ser reemplazados por caracteres de guion bajo, permitiendo sobrescribir cookies __HOST-:

Ataques a Cookies

Si una cookie personalizada contiene datos sensibles, revísela (especialmente si está participando en un CTF), ya que podría ser vulnerable.

Decodificación y Manipulación de Cookies

Los datos sensibles incrustados en las cookies siempre deben ser examinados. Las cookies codificadas en Base64 u otros formatos similares a menudo pueden ser decodificadas. Esta vulnerabilidad permite a los atacantes alterar el contenido de la cookie e impersonar a otros usuarios codificando sus datos modificados de vuelta en la cookie.

Secuestro de Sesión

Este ataque implica robar la cookie de un usuario para obtener acceso no autorizado a su cuenta dentro de una aplicación. Al utilizar la cookie robada, un atacante puede hacerse pasar por el usuario legítimo.

Fijación de Sesión

En este escenario, un atacante engaña a una víctima para que use una cookie específica para iniciar sesión. Si la aplicación no asigna una nueva cookie al iniciar sesión, el atacante, que posee la cookie original, puede hacerse pasar por la víctima. Esta técnica depende de que la víctima inicie sesión con una cookie proporcionada por el atacante.

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

Donación de Sesión

Aquí, el atacante convence a la víctima de usar la cookie de sesión del atacante. La víctima, creyendo que ha iniciado sesión en su propia cuenta, realizará acciones inadvertidamente en el contexto de la cuenta del atacante.

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

Cookies JWT

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

Los Tokens Web JSON (JWT) utilizados en cookies también pueden presentar vulnerabilidades. Para obtener información detallada sobre posibles fallas y cómo explotarlas, se recomienda acceder al documento vinculado sobre el hacking de JWT.

Falsificación de Petición entre Sitios (CSRF)

Este ataque obliga a un usuario con sesión iniciada a ejecutar acciones no deseadas en una aplicación web en la que actualmente está autenticado. Los atacantes pueden explotar cookies que se envían automáticamente con cada solicitud al sitio vulnerable.

Cookies Vacías

(Consulta más detalles en la investigación original) Los navegadores permiten la creación de cookies sin un nombre, lo cual se puede demostrar a través de JavaScript de la siguiente manera:

document.cookie = "a=v1"
document.cookie = "=test value;" // Setting an empty named cookie
document.cookie = "b=v2"

El resultado en la cabecera de la cookie enviada es a=v1; valor de prueba; b=v2;. Curiosamente, esto permite la manipulación de cookies si se establece una cookie con nombre vacío, potencialmente controlando otras cookies al establecer la cookie vacía en un valor específico:

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

setCookie("", "a=b"); // Setting the empty cookie modifies another cookie's value

Problema de Chrome: Problema de Punto de Código de Sustitución Unicode

En Chrome, si un punto de código de sustitución Unicode es parte de una cookie establecida, document.cookie se corrompe, devolviendo posteriormente una cadena vacía:

document.cookie = "\ud800=meep";

Esto resulta en que document.cookie produzca una cadena vacía, lo que indica corrupción permanente.

Contrabando de Cookies Debido a Problemas de Análisis

(Consulte más detalles en la investigación original) Varios servidores web, incluidos los de Java (Jetty, TomCat, Undertow) y Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), manejan incorrectamente las cadenas de cookies debido al soporte desactualizado de RFC2965. Leen un valor de cookie entre comillas dobles como un único valor incluso si incluye puntos y comas, que normalmente deberían separar pares clave-valor:

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

Vulnerabilidades de Inyección de Cookies

(Consulte más detalles en la investigación original) El análisis incorrecto de cookies por parte de servidores, notablemente Undertow, Zope y aquellos que utilizan http.cookie.SimpleCookie y http.cookie.BaseCookie de Python, crea oportunidades para ataques de inyección de cookies. Estos servidores no delimitan correctamente el inicio de nuevas cookies, lo que permite a los atacantes falsificar cookies:

  • Undertow espera una nueva cookie inmediatamente después de un valor entre comillas sin punto y coma.

  • Zope busca una coma para comenzar a analizar la siguiente cookie.

  • Las clases de cookies de Python comienzan el análisis en un carácter de espacio.

Esta vulnerabilidad es particularmente peligrosa en aplicaciones web que dependen de la protección CSRF basada en cookies, ya que permite a los atacantes inyectar cookies de tokens CSRF falsificados, potencialmente eludiendo medidas de seguridad. El problema se agrava por el manejo de nombres de cookies duplicados en Python, donde la última ocurrencia anula las anteriores. También plantea preocupaciones para las cookies __Secure- y __Host- en contextos inseguros y podría llevar a elusiones de autorización cuando las cookies se envían a servidores backend susceptibles a falsificaciones.

Comprobaciones Extra de Cookies Vulnerables

Comprobaciones básicas

  • La cookie es la misma cada vez que te conectas.

  • Cierra la 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 "recordarme" si existe para ver cómo funciona. Si existe y podría ser vulnerable, siempre utiliza la cookie de recordarme sin ninguna otra cookie.

  • Comprueba si la cookie anterior sigue funcionando incluso después de cambiar la contraseña.

Ataques avanzados a cookies

Si la cookie permanece igual (o casi igual) 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:

  • Intenta crear muchas cuentas con nombres de usuario muy similares e intenta adivinar cómo funciona el algoritmo.

  • Intenta bruteforce al 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 bruteforce cada bit de tu cookie porque una de las cookies que intentarás será la que pertenece a "admin".

  • Prueba el 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 encriptada y codificada con la cadena user=administrator en su interior.

CBC-MAC

Tal vez una cookie podría tener algún valor y estar firmada usando CBC. Entonces, la integridad del valor es la firma creada usando CBC con el mismo valor. Como se recomienda usar un vector IV 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 siempre tiene que ser la misma.

Cómo detectar y atacar:

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

Crear un usuario llamado, por ejemplo, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" y verificar 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 están encriptadas 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

Try Hard Security Group

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

Otras formas de apoyar a HackTricks:

AnteriorCSP bypass: self + 'unsafe-inline' with IframesSiguienteCookie Tossing

Última actualización