mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 22:52:06 +00:00

History

Translator 442779b61d Translated ['pentesting-web/hacking-with-cookies/cookie-tossing.md'] to		2024-04-04 08:57:22 +00:00
..
cookie-bomb.md	Translated to German	2024-02-10 15:36:32 +00:00
cookie-jar-overflow.md	Translated to German	2024-02-10 15:36:32 +00:00
cookie-tossing.md	Translated ['pentesting-web/hacking-with-cookies/cookie-tossing.md'] to	2024-04-04 08:57:22 +00:00
README.md	Translated ['README.md', 'backdoors/salseo.md', 'cryptography/certificat	2024-03-29 21:05:19 +00:00

README.md

Cookies Hacking

Lernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

Wenn Sie Ihr Unternehmen in HackTricks beworben sehen möchten oder HackTricks in PDF herunterladen möchten, überprüfen Sie die ABONNEMENTPLÄNE!
Holen Sie sich das offizielle PEASS & HackTricks-Merchandise
Entdecken Sie The PEASS Family, unsere Sammlung exklusiver NFTs
Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @carlospolopm.
Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repositories einreichen.

Try Hard Security Group

{% embed url="https://discord.gg/tryhardsecurity" %}

Cookies verfügen über mehrere Attribute, die ihr Verhalten im Browser des Benutzers steuern. Hier ist eine Übersicht über diese Attribute in einer eher passiven Sprache:

Ablaufdatum und Max-Age

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

Domain

Die Hosts, die ein Cookie erhalten sollen, werden durch das Attribut Domain angegeben. Standardmäßig ist dies auf den Host festgelegt, der das Cookie ausgestellt hat, ohne seine Subdomains einzubeziehen. Wenn jedoch das Attribut Domain explizit festgelegt ist, umfasst es auch Subdomains. Dies macht die Spezifikation des Domain-Attributs zu einer weniger restriktiven Option, die in Szenarien nützlich ist, in denen ein Cookieaustausch über Subdomains erforderlich ist. Wenn beispielsweise Domain=mozilla.org festgelegt ist, sind Cookies auf seinen Subdomains wie developer.mozilla.org zugänglich.

Pfad

Ein spezifischer URL-Pfad, der in der angeforderten URL vorhanden sein muss, damit der Cookie-Header gesendet wird, wird durch das Attribut Path angezeigt. Dieses Attribut betrachtet das /-Zeichen als Verzeichnistrennzeichen und ermöglicht Übereinstimmungen in Unterverzeichnissen.

Bestellregeln

Wenn zwei Cookies denselben Namen haben, wird das zum Senden ausgewählte Cookie basierend auf folgendem ausgewählt:

Das Cookie, das am längsten mit dem Pfad in der angeforderten URL übereinstimmt.
Das zuletzt gesetzte Cookie, wenn die Pfade identisch sind.

SameSite

Das Attribut SameSite bestimmt, ob Cookies bei Anfragen von Drittanbieterdomains gesendet werden. Es bietet drei Einstellungen:
Strict: Beschränkt das Senden des Cookies bei Anfragen von Drittanbietern.
Lax: Ermöglicht das Senden des Cookies bei GET-Anfragen, die von Websites von Drittanbietern initiiert wurden.
None: Erlaubt das Senden des Cookies von jeder Drittanbieterdomain.

Beachten Sie, dass beim Konfigurieren von Cookies das Verständnis dieser Attribute dazu beitragen kann, sicherzustellen, dass sie sich in verschiedenen Szenarien wie erwartet verhalten.

Anforderungstyp	Beispielcode	Cookies gesendet, wenn
Link	<a href="..."></a>	NotSet*, Lax, None
Prerender	<link rel="prerender" href=".."/>	NotSet*, Lax, None
Formular GET	<form method="GET" action="...">	NotSet*, Lax, None
Formular POST	<form method="POST" action="...">	NotSet*, None
iframe	<iframe src="..."></iframe>	NotSet*, None
AJAX	$.get("...")	NotSet*, None
Bild	<img src="...">	NetSet*, None

Tabelle von Invicti und leicht modifiziert.
Ein Cookie mit SameSite Attribut wird CSRF-Angriffe abmildern, bei denen eine angemeldete Sitzung erforderlich ist.

*Beachten Sie, dass ab Chrome80 (Feb/2019) das Standardverhalten eines Cookies ohne ein Cookie-Samesite-Attribut lax sein wird (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/).
Beachten Sie vorübergehend, nach Anwendung dieser Änderung werden die Cookies ohne eine SameSite-Richtlinie in Chrome während der ersten 2 Minuten als None behandelt und dann als Lax für Cross-Site-POST-Anfragen auf höchster Ebene.

HttpOnly

Dies verhindert, dass der Client auf das Cookie zugreift (zum Beispiel über Javascript wie document.cookie)

Umgehungen

Wenn die Seite die Cookies als Antwort auf eine Anfrage sendet (zum Beispiel auf einer PHPinfo-Seite), ist es möglich, XSS zu missbrauchen, um eine Anfrage an diese Seite zu senden und die Cookies aus der Antwort zu stehlen (siehe ein Beispiel unter https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/.
Dies könnte mit TRACE HTTP-Anfragen umgangen werden, da die Antwort des Servers (falls diese HTTP-Methode verfügbar ist) die gesendeten Cookies widerspiegelt. Diese Technik wird als Cross-Site-Tracking bezeichnet.
Moderne Browser verhindern diese Technik, indem sie das Senden einer TRACE-Anfrage von JS nicht zulassen. Es wurden jedoch einige Umgehungen für spezifische Software gefunden, wie z.B. das Senden von \r\nTRACE anstelle von TRACE an IE6.0 SP2.
Ein anderer Weg ist die Ausnutzung von Zero-Day-Schwachstellen der Browser.
Es ist möglich, HttpOnly-Cookies zu überschreiben, indem ein Cookie-Jar-Überlaufangriff durchgeführt wird:

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

Es ist möglich, den Cookie-Smuggling-Angriff zu verwenden, um diese Cookies zu exfiltrieren

Secure

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

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

Für Cookies, die mit __Host- beginnen, müssen mehrere Bedingungen erfüllt sein:

Sie müssen mit der secure-Flag gesetzt werden.
Sie müssen von einer Seite stammen, die durch HTTPS gesichert ist.
Es ist verboten, eine Domain anzugeben, um deren Übertragung an Subdomains zu verhindern.
Der Pfad für diese Cookies muss auf / festgelegt sein.

Es ist wichtig zu beachten, dass Cookies, die mit __Host- beginnen, nicht an Superdomains oder Subdomains gesendet werden dürfen. Diese Einschränkung trägt dazu bei, Anwendungscookies zu isolieren. Daher kann die Verwendung des Präfix __Host- für alle Anwendungscookies als bewährte Praxis zur Verbesserung der Sicherheit und Isolierung betrachtet werden.

Überschreiben von Cookies

Eine der Schutzmaßnahmen für mit __Host- vorangestellten Cookies besteht darin, zu verhindern, dass sie von Subdomains überschrieben werden. Dies verhindert beispielsweise Cookie-Tossing-Angriffe. In dem Vortrag Cookie Crumbles: Enthüllung von Schwachstellen bei der Web-Sitzungsintegrität (Paper) wurde dargestellt, dass es möglich war, __HOST- vorangestellte Cookies von Subdomains aus zu setzen, indem man den Parser austrickste, zum Beispiel indem man "=" am Anfang oder am Anfang und am Ende hinzufügte...:

Oder in PHP war es möglich, andere Zeichen am Anfang des Cookie-Namens hinzuzufügen, die durch Unterstrichzeichen ersetzt werden sollten, was es ermöglichte, __HOST- Cookies zu überschreiben:

Wenn ein benutzerdefinierter Cookie sensible Daten enthält, überprüfen Sie ihn (insbesondere wenn Sie an einem CTF teilnehmen), da er möglicherweise anfällig ist.

Dekodieren und Manipulieren von Cookies

In Cookies eingebettete sensible Daten sollten immer überprüft werden. Cookies, die in Base64 oder ähnlichen Formaten codiert sind, können oft dekodiert werden. Diese Schwachstelle ermöglicht es Angreifern, den Inhalt des Cookies zu ändern und sich als andere Benutzer auszugeben, indem sie ihre modifizierten Daten zurück in das Cookie codieren.

Sitzungsübernahme

Bei diesem Angriff wird ein Benutzercookie gestohlen, um unbefugten Zugriff auf sein Konto in einer Anwendung zu erlangen. Indem der gestohlene Cookie verwendet wird, kann ein Angreifer den legitimen Benutzer imitieren.

Sitzungsfestlegung

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

Wenn Sie ein XSS in einer Subdomain gefunden haben oder Sie eine Subdomain kontrollieren, lesen Sie:

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

Sitzungsspende

Hier überzeugt der Angreifer das Opfer, das Sitzungscookie des Angreifers zu verwenden. Das Opfer, das glaubt, in sein eigenes Konto eingeloggt zu sein, wird unbeabsichtigt Aktionen im Kontext des Kontos des Angreifers ausführen.

Wenn Sie ein XSS in einer Subdomain gefunden haben oder Sie eine Subdomain kontrollieren, lesen Sie:

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

JWT-Cookies

Klicken Sie auf den vorherigen Link, um auf eine Seite zuzugreifen, die mögliche Schwachstellen bei JWT erklärt.

JSON Web Tokens (JWT), die in Cookies verwendet werden, können ebenfalls Schwachstellen aufweisen. Für detaillierte Informationen zu potenziellen Schwachstellen und wie sie ausgenutzt werden können, wird empfohlen, das verlinkte Dokument zum Hacken von JWT zu lesen.

Cross-Site Request Forgery (CSRF)

Dieser Angriff zwingt einen eingeloggten Benutzer, unerwünschte Aktionen auf einer Webanwendung auszuführen, für die er derzeit authentifiziert ist. Angreifer können Cookies ausnutzen, die automatisch mit jeder Anfrage an die verwundbare Website gesendet werden.

Leere Cookies

(Weitere Details finden Sie in der Originalforschung) Browser erlauben die Erstellung von Cookies ohne Namen, was durch JavaScript wie folgt demonstriert werden kann:

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

Der Wert im gesendeten Cookie-Header lautet a=v1; Testwert; b=v2;. Interessanterweise ermöglicht dies die Manipulation von Cookies, wenn ein Cookie mit leerem Namen gesetzt wird, wodurch möglicherweise andere Cookies kontrolliert werden können, indem das leere Cookie auf einen bestimmten Wert gesetzt wird:

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

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

Chrome-Bug: Unicode-Ersatzcodepunkt-Problem

In Chrome wird, wenn ein Unicode-Ersatzcodepunkt Teil eines gesetzten Cookies ist, document.cookie beschädigt, und gibt anschließend einen leeren String zurück:

document.cookie = "\ud800=meep";

Dies führt dazu, dass document.cookie eine leere Zeichenfolge ausgibt, was auf eine dauerhafte Beschädigung hinweist.

(Weitere Details finden Sie in der Originalforschung) Mehrere Webserver, darunter solche von Java (Jetty, TomCat, Undertow) und Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), behandeln Cookie-Zeichenfolgen fehlerhaft aufgrund veralteter RFC2965-Unterstützung. Sie lesen einen in doppelte Anführungszeichen gesetzten Cookie-Wert als einzelnen Wert, auch wenn er Semikolons enthält, die normalerweise Schlüssel-Wert-Paare trennen sollten:

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

(Überprüfen Sie weitere Details in der ursprünglichen Forschung) Die fehlerhafte Analyse von Cookies durch Server, insbesondere Undertow, Zope und solche, die Python's http.cookie.SimpleCookie und http.cookie.BaseCookie verwenden, schafft Möglichkeiten für Cookie-Injection-Angriffe. Diese Server versäumen es, den Beginn neuer Cookies ordnungsgemäß zu begrenzen, was es Angreifern ermöglicht, Cookies zu fälschen:

Undertow erwartet ein neues Cookie unmittelbar nach einem in Anführungszeichen gesetzten Wert ohne Semikolon.
Zope sucht nach einem Komma, um mit der Analyse des nächsten Cookies zu beginnen.
Die Cookie-Klassen von Python beginnen mit der Analyse bei einem Leerzeichen.

Diese Schwachstelle ist besonders gefährlich in Webanwendungen, die auf cookiebasierten CSRF-Schutz angewiesen sind, da sie es Angreifern ermöglicht, gefälschte CSRF-Token-Cookies einzufügen und möglicherweise Sicherheitsmaßnahmen zu umgehen. Das Problem wird durch Pythons Umgang mit doppelten Cookienamen verschärft, bei dem das letzte Auftreten frühere überschreibt. Es wirft auch Bedenken hinsichtlich der __Secure- und __Host--Cookies in unsicheren Kontexten auf und könnte zu Autorisierungsumgehungen führen, wenn Cookies an anfällige Backend-Server weitergeleitet werden, die anfällig für Fälschungen sind.

Zusätzliche Überprüfungen für anfällige Cookies

Grundlegende Überprüfungen

Der Cookie ist jedes Mal gleich, wenn Sie sich anmelden.
Melden Sie sich ab und versuchen Sie denselben Cookie zu verwenden.
Versuchen Sie, sich mit 2 Geräten (oder Browsern) beim selben Konto mit demselben Cookie anzumelden.
Überprüfen Sie, ob der Cookie Informationen enthält und versuchen Sie, ihn zu ändern.
Versuchen Sie, mehrere Konten mit fast demselben Benutzernamen zu erstellen und prüfen Sie, ob Sie Ähnlichkeiten sehen können.
Überprüfen Sie die Option "Angemeldet bleiben", falls vorhanden, um zu sehen, wie sie funktioniert. Wenn sie vorhanden ist und anfällig sein könnte, verwenden Sie immer den Cookie von Angemeldet bleiben ohne jeden anderen Cookie.
Überprüfen Sie, ob der vorherige Cookie auch nach einer Passwortänderung funktioniert.

Wenn der Cookie beim Einloggen gleich bleibt (oder fast gleich), bedeutet dies wahrscheinlich, dass der Cookie mit einem Feld Ihres Kontos zusammenhängt (wahrscheinlich dem Benutzernamen). Dann können Sie:

Versuchen Sie, viele Konten mit sehr ähnlichen Benutzernamen zu erstellen und versuchen Sie zu erraten, wie der Algorithmus funktioniert.
Versuchen Sie, den Benutzernamen bruteforce. Wenn der Cookie nur als Authentifizierungsmethode für Ihren Benutzernamen gespeichert wird, können Sie ein Konto mit dem Benutzernamen "Bmin" erstellen und jeden einzelnen Bit Ihres Cookies bruteforcen, da einer der Cookies, den Sie ausprobieren werden, derjenige ist, der zu "admin" gehört.
Versuchen Sie Padding Oracle (Sie können den Inhalt des Cookies entschlüsseln). Verwenden Sie padbuster.

Padding Oracle - Padbuster-Beispiele

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 unternehmen und Sie nach der Fehlerbedingung fragen (die ungültige).

Dann wird es beginnen, das Cookie zu entschlüsseln (es kann mehrere Minuten dauern).

Wenn der Angriff erfolgreich war, könnten Sie versuchen, einen String Ihrer Wahl zu verschlüsseln. Zum Beispiel, wenn Sie user=administrator verschlüsseln möchten.

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

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

CBC-MAC

Möglicherweise hat ein Cookie einen Wert und könnte mit CBC signiert werden. Die Integrität des Werts ist dann die Signatur, die durch Verwendung von CBC mit dem gleichen Wert erstellt wird. Da empfohlen wird, als IV einen Nullvektor zu verwenden, könnte diese Art der Integritätsprüfung anfällig sein.

Der Angriff

Erhalten Sie die Signatur des Benutzernamens administ = t
Erhalten Sie die Signatur des Benutzernamens rator\x00\x00\x00 XOR t = t'
Setzen Sie 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, könnte es anfällig sein.
Wenn Sie sich einloggen, muss das Cookie, das Sie erhalten, immer dasselbe sein.

Wie man erkennt und angreift:

Erstellen Sie 2 Benutzer mit fast denselben Daten (Benutzername, Passwort, E-Mail usw.) und versuchen Sie, ein Muster im gegebenen Cookie zu entdecken

Erstellen Sie einen Benutzer mit dem Namen "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" und überprüfen Sie, ob im Cookie ein Muster vorhanden ist (da ECB mit dem gleichen Schlüssel jeden Block verschlüsselt, könnten dieselben verschlüsselten Bytes erscheinen, wenn der Benutzername verschlüsselt ist).

Es sollte ein Muster geben (mit der Größe eines verwendeten Blocks). Daher können Sie, wenn Sie wissen, wie eine Menge von "a" verschlüsselt ist, einen Benutzernamen erstellen: "a"*(Größe des Blocks)+"admin". Dann könnten Sie das verschlüsselte Muster eines Blocks von "a" aus dem Cookie löschen. Und Sie haben das Cookie des Benutzernamens "admin".

Referenzen