Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 13:13:41 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/cache-deception
History
Translator 79b6443022 Translated ['generic-methodologies-and-resources/external-recon-methodol
2024-04-10 13:39:51 +00:00
..
cache-poisoning-to-dos.md Translated ['generic-methodologies-and-resources/external-recon-methodol 2024-04-10 13:39:51 +00:00
README.md Translated ['generic-methodologies-and-resources/external-recon-methodol 2024-04-10 13:39:51 +00:00

README.md

Cache-Vergiftung und Cache-Täuschung

Erlernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:


Verwenden Sie Trickest, um mühelos Workflows zu erstellen und zu automatisieren, die von den weltweit fortschrittlichsten Community-Tools unterstützt werden.
Heute Zugriff erhalten:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Der Unterschied

Was ist der Unterschied zwischen Web-Cache-Vergiftung und Web-Cache-Täuschung?

  • Bei der Web-Cache-Vergiftung veranlasst der Angreifer die Anwendung, einige bösartige Inhalte im Cache zu speichern, die dann anderen Anwendern aus dem Cache bereitgestellt werden.
  • Bei der Web-Cache-Täuschung veranlasst der Angreifer die Anwendung, einige sensible Inhalte eines anderen Benutzers im Cache zu speichern, und der Angreifer ruft dann diese Inhalte aus dem Cache ab.

Cache-Vergiftung

Die Cache-Vergiftung zielt darauf ab, den Client-seitigen Cache zu manipulieren, um Clients dazu zu zwingen, Ressourcen zu laden, die unerwartet, teilweise oder unter der Kontrolle eines Angreifers stehen. Das Ausmaß der Auswirkungen hängt von der Beliebtheit der betroffenen Seite ab, da die verunreinigte Antwort ausschließlich an Benutzer serviert wird, die die Seite während der Zeit der Cache-Kontamination besuchen.

Die Durchführung eines Cache-Vergiftungsangriffs umfasst mehrere Schritte:

  1. Identifizierung von nicht gekeyten Eingaben: Dies sind Parameter, die zwar nicht für eine zwischengespeicherte Anfrage erforderlich sind, aber die Antwort beeinflussen können, die vom Server zurückgegeben wird. Die Identifizierung dieser Eingaben ist entscheidend, da sie ausgenutzt werden können, um den Cache zu manipulieren.
  2. Ausnutzung der nicht gekeyten Eingaben: Nach der Identifizierung der nicht gekeyten Eingaben besteht der nächste Schritt darin, herauszufinden, wie diese Parameter missbraucht werden können, um die Antwort des Servers auf eine Weise zu modifizieren, die dem Angreifer zugutekommt.
  3. Sicherstellen, dass die vergiftete Antwort zwischengespeichert wird: Der letzte Schritt besteht darin, sicherzustellen, dass die manipulierte Antwort im Cache gespeichert wird. Auf diese Weise erhält jeder Benutzer, der während der Cache-Vergiftung auf die betroffene Seite zugreift, die verunreinigte Antwort.

Entdeckung: Überprüfen von HTTP-Headern

Normalerweise gibt es einen Header, der anzeigt, dass eine Antwort im Cache gespeichert wurde, Sie können überprüfen, auf welche Header Sie in diesem Beitrag achten sollten: HTTP-Cache-Header.

Entdeckung: Caching-Fehlercodes

Wenn Sie vermuten, dass die Antwort im Cache gespeichert wird, könnten Sie versuchen, Anfragen mit einem fehlerhaften Header zu senden, auf die mit einem Statuscode 400 geantwortet werden sollte. Versuchen Sie dann, auf die Anfrage normal zuzugreifen, und wenn die Antwort ein Statuscode 400 ist, wissen Sie, dass sie verwundbar ist (und Sie könnten sogar einen DoS durchführen).

Weitere Optionen finden Sie unter:

{% content-ref url="cache-poisoning-to-dos.md" %} cache-poisoning-to-dos.md {% endcontent-ref %}

Beachten Sie jedoch, dass manchmal diese Arten von Statuscodes nicht zwischengespeichert werden, sodass dieser Test möglicherweise nicht zuverlässig ist.

Entdeckung: Identifizieren und Auswerten von nicht gekeyten Eingaben

Sie könnten Param Miner verwenden, um Parameter und Header zu brute-forcen, die die Antwort der Seite ändern könnten. Eine Seite könnte beispielsweise den Header X-Forwarded-For verwenden, um dem Client anzuzeigen, dass das Skript von dort geladen werden soll:

<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>

Elicit a harmful response from the back-end server

Mit dem identifizierten Parameter/ Header überprüfen, wie er gesäubert wird und wo er reflektiert wird oder die Antwort vom Header beeinflusst. Können Sie ihn trotzdem missbrauchen (XSS durchführen oder einen von Ihnen kontrollierten JS-Code laden? DoS durchführen?...)

Get the response cached

Sobald Sie die Seite identifiziert haben, die missbraucht werden kann, welchen Parameter/Header Sie verwenden und wie Sie ihn missbrauchen können, müssen Sie die Seite zwischenspeichern. Je nach Ressource, die Sie im Cache abrufen möchten, kann dies einige Zeit in Anspruch nehmen. Es könnte sein, dass Sie es mehrere Sekunden lang versuchen müssen.
Der Header X-Cache in der Antwort könnte sehr nützlich sein, da er den Wert miss haben kann, wenn die Anfrage nicht zwischengespeichert wurde, und den Wert hit, wenn sie zwischengespeichert ist.
Der Header Cache-Control ist auch interessant, um zu wissen, ob eine Ressource zwischengespeichert wird und wann die Ressource das nächste Mal wieder zwischengespeichert wird: Cache-Control: public, max-age=1800
Ein weiterer interessanter Header ist Vary. Dieser Header wird oft verwendet, um zusätzliche Header anzugeben, die als Teil des Cache-Schlüssels behandelt werden, auch wenn sie normalerweise nicht als Schlüssel verwendet werden. Daher kann der Benutzer, wenn er den User-Agent des Opfers kennt, den Cache für die Benutzer mit diesem spezifischen User-Agent vergiften.
Ein weiterer Header, der mit dem Cache zusammenhängt, ist Age. Er definiert die Zeit in Sekunden, die das Objekt im Proxy-Cache war.

Beim Zwischenspeichern einer Anfrage sollten Sie vorsichtig mit den Headern sein, die Sie verwenden, da einige von ihnen unerwartet als Schlüssel verwendet werden könnten und das Opfer denselben Header verwenden muss. Testen Sie immer eine Cache-Vergiftung mit verschiedenen Browsern, um zu überprüfen, ob sie funktioniert.

Exploiting Examples

Einfachstes Beispiel

Ein Header wie X-Forwarded-For wird unsauber in der Antwort reflektiert.
Sie können ein einfaches XSS-Payload senden und den Cache vergiften, sodass jeder, der auf die Seite zugreift, XSS erhält:

GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"

Note that this will poison a request to /en?region=uk not to /en

Cache-Poisoning zum DoS

{% content-ref url="cache-poisoning-to-dos.md" %} cache-poisoning-to-dos.md {% endcontent-ref %}

Verwendung von Web-Cache-Poisoning zur Ausnutzung von Cookie-Handling-Schwachstellen

Cookies könnten auch in der Antwort einer Seite reflektiert werden. Wenn Sie es missbrauchen können, um beispielsweise ein XSS zu verursachen, könnten Sie in der Lage sein, XSS in mehreren Clients auszunutzen, die die bösartige Cache-Antwort laden.

GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"

Hinweis: Wenn das anfällige Cookie sehr häufig von den Benutzern verwendet wird, werden regelmäßige Anfragen den Cache leeren.

Cache-Vergiftung mit Pfadtraversierung zum Diebstahl des API-Schlüssels

Dieser Bericht erklärt, wie es möglich war, einen OpenAI-API-Schlüssel mit einer URL wie https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 zu stehlen, weil alles, was zu /share/* passt, ohne Normalisierung der URL durch Cloudflare zwischengespeichert wird, was beim Erreichen des Webservers erfolgte.

Verwendung mehrerer Header, um Schwachstellen bei der Web-Cache-Vergiftung auszunutzen

Manchmal müssen Sie mehrere nicht geprüfte Eingaben ausnutzen, um einen Cache missbrauchen zu können. Wenn Sie beispielsweise einen Offenen Weiterleitungsfehler finden, wenn Sie X-Forwarded-Host auf eine von Ihnen kontrollierte Domain und X-Forwarded-Scheme auf http setzen. Wenn der Server alle HTTP-Anfragen an HTTPS weiterleitet und den Header X-Forwarded-Scheme als Domainnamen für die Weiterleitung verwendet. Sie können steuern, wohin die Seite durch die Weiterleitung zeigt.

GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
X-Forwarded-Scheme: http

Ausnutzung mit begrenztem Vary-Header

Wenn Sie feststellen, dass der X-Host-Header als Domainname zum Laden einer JS-Ressource verwendet wird, der Vary-Header in der Antwort jedoch auf User-Agent hinweist. Dann müssen Sie einen Weg finden, um den User-Agent des Opfers zu exfiltrieren und den Cache mit diesem User-Agent zu manipulieren:

GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com

Fat Get

Senden Sie eine GET-Anfrage mit dem Request in der URL und im Body. Wenn der Webserver den aus dem Body verwendet, der Cache-Server jedoch den aus der URL zwischenspeichert, wird jeder, der auf diese URL zugreift, tatsächlich den Parameter aus dem Body verwenden. Ähnlich der Schwachstelle, die James Kettle auf der Github-Website gefunden hat:

GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 22

report=innocent-victim

Parameter Cloaking

Zum Beispiel ist es möglich, Parameter in Ruby-Servern mit dem Zeichen ; anstelle von & zu trennen. Dies könnte verwendet werden, um nicht gekeyte Parameterwerte innerhalb gekeyter Parameter zu platzieren und sie zu missbrauchen.

Portswigger-Labor: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking

Ausnutzen der HTTP-Cache-Vergiftung durch Missbrauch des HTTP-Request-Smuggling

Erfahren Sie hier, wie Sie Cache-Vergiftungsangriffe durch Missbrauch des HTTP-Request-Smuggling durchführen können.

Automatisiertes Testen auf Web-Cache-Vergiftung

Der Web-Cache-Vulnerability-Scanner kann verwendet werden, um automatisch auf Web-Cache-Vergiftung zu testen. Er unterstützt viele verschiedene Techniken und ist hochgradig anpassbar.

Beispielverwendung: wcvs -u example.com


Verwenden Sie Trickest, um mühelos Workflows zu erstellen und zu automatisieren, die von den weltweit fortschrittlichsten Community-Tools unterstützt werden.
Heute noch Zugriff erhalten:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Anfällige Beispiele

Apache Traffic Server (CVE-2021-27577)

ATS leitete das Fragment innerhalb der URL weiter, ohne es zu entfernen, und generierte den Cache-Schlüssel nur unter Verwendung des Hosts, des Pfads und der Abfrage (wobei das Fragment ignoriert wurde). So wurde die Anfrage /#/../?r=javascript:alert(1) an das Backend als /#/../?r=javascript:alert(1) gesendet und der Cache-Schlüssel enthielt das Payload nicht, nur Host, Pfad und Abfrage.

GitHub CP-DoS

Das Senden eines falschen Werts im Inhaltstyp-Header löste eine 405-Cacheantwort aus. Der Cache-Schlüssel enthielt das Cookie, sodass nur nicht authentifizierte Benutzer angegriffen werden konnten.

GitLab + GCP CP-DoS

GitLab verwendet GCP-Buckets zur Speicherung statischer Inhalte. GCP Buckets unterstützen den Header x-http-method-override. Es war also möglich, den Header x-http-method-override: HEAD zu senden und den Cache dazu zu bringen, eine leere Antwort zurückzugeben. Es könnte auch die Methode PURGE unterstützen.

Rack Middleware (Ruby on Rails)

In Ruby on Rails-Anwendungen wird häufig Rack-Middleware verwendet. Der Zweck des Rack-Codes besteht darin, den Wert des Headers x-forwarded-scheme zu übernehmen und ihn als Schemas der Anfrage festzulegen. Wenn der Header x-forwarded-scheme: http gesendet wird, erfolgt eine 301-Weiterleitung zum selben Ort, was potenziell zu einem Denial-of-Service (DoS) für diese Ressource führen kann. Darüber hinaus könnte die Anwendung den X-forwarded-host-Header erkennen und Benutzer zur angegebenen Host-Adresse umleiten. Dieses Verhalten kann dazu führen, dass JavaScript-Dateien vom Server eines Angreifers geladen werden, was ein Sicherheitsrisiko darstellt.

403 und Speicher-Buckets

Cloudflare hat zuvor 403-Antworten zwischengespeichert. Der Versuch, auf S3- oder Azure-Speicherblobs mit falschen Autorisierungsheadern zuzugreifen, führte zu einer 403-Antwort, die zwischengespeichert wurde. Obwohl Cloudflare aufgehört hat, 403-Antworten zu zwischenspeichern, könnte dieses Verhalten noch bei anderen Proxy-Diensten vorhanden sein.

Einfügen von gekeyten Parametern

Caches enthalten oft spezifische GET-Parameter im Cache-Schlüssel. Zum Beispiel hat Fastlys Varnish den size-Parameter in Anfragen zwischengespeichert. Wenn jedoch eine URL-codierte Version des Parameters (z. B. siz%65) mit einem fehlerhaften Wert gesendet wurde, würde der Cache-Schlüssel unter Verwendung des korrekten size-Parameters konstruiert. Dennoch würde der Backend den Wert im URL-codierten Parameter verarbeiten. Das URL-Codieren des zweiten size-Parameters führte dazu, dass er vom Cache ausgelassen, aber vom Backend genutzt wurde. Das Zuweisen eines Werts von 0 zu diesem Parameter führte zu einem zwischenspeicherbaren 400 Bad Request-Fehler.

Benutzer-Agent-Regeln

Einige Entwickler blockieren Anfragen mit Benutzer-Agenten, die denen von Hochverkehrs-Tools wie FFUF oder Nuclei entsprechen, um die Serverlast zu verwalten. Ironischerweise kann dieser Ansatz Sicherheitslücken wie Cache-Vergiftung und DoS einführen.

Illegale Header-Felder

Die RFC7230 spezifiziert die akzeptablen Zeichen in Header-Namen. Header, die Zeichen außerhalb des spezifizierten tchar-Bereichs enthalten, sollten idealerweise eine 400 Bad Request-Antwort auslösen. In der Praxis halten sich Server nicht immer an diesen Standard. Ein bemerkenswertes Beispiel ist Akamai, das Header mit ungültigen Zeichen weiterleitet und jeden 400-Fehler zwischenspeichert, solange der cache-control-Header nicht vorhanden ist. Es wurde ein ausnutzbares Muster identifiziert, bei dem das Senden eines Headers mit einem ungültigen Zeichen, wie \, zu einem zwischenspeicherbaren 400 Bad Request-Fehler führte.

Neue Header finden

https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6

Cache-Täuschung

Das Ziel der Cache-Täuschung besteht darin, dass Clients Ressourcen laden, die mit ihren sensiblen Informationen im Cache gespeichert werden.

Zunächst ist zu beachten, dass Erweiterungen wie .css, .js, .png usw. normalerweise so konfiguriert sind, dass sie im Cache gespeichert werden. Wenn Sie also auf www.example.com/profile.php/nonexistent.js zugreifen, wird die Antwort wahrscheinlich im Cache gespeichert, da die Erweiterung .js erkannt wird. Wenn die Anwendung jedoch mit den sensiblen Benutzerinhalten, die in www.example.com/profile.php gespeichert sind, wiedergegeben wird, können Sie diese Inhalte von anderen Benutzern stehlen.

Andere Dinge, die getestet werden sollten:

  • www.example.com/profile.php/.js
  • www.example.com/profile.php/.css
  • www.example.com/profile.php/test.js
  • www.example.com/profile.php/../test.js
  • www.example.com/profile.php/%2e%2e/test.js
  • Verwenden Sie weniger bekannte Erweiterungen wie .avif

Ein weiteres sehr klares Beispiel finden Sie in diesem Bericht: https://hackerone.com/reports/593712.
Im Beispiel wird erklärt, dass wenn Sie eine nicht existierende Seite wie http://www.example.com/home.php/non-existent.css laden, der Inhalt von http://www.example.com/home.php (mit den sensiblen Informationen des Benutzers) zurückgegeben wird und der Cache-Server das Ergebnis speichert.
Dann kann der Angreifer auf http://www.example.com/home.php/non-existent.css in seinem eigenen Browser zugreifen und die vertraulichen Informationen der Benutzer einsehen, die zuvor darauf zugegriffen haben.

Es ist zu beachten, dass der Cache-Proxy so konfiguriert sein sollte, dass Dateien basierend auf der Erweiterung der Datei (.css) und nicht basierend auf dem Inhaltstyp zwischengespeichert werden. Im Beispiel wird http://www.example.com/home.php/non-existent.css einen text/html-Inhaltstyp anstelle eines text/css-MIME-Typs haben (was für eine .css-Datei erwartet wird).

Erfahren Sie hier, wie Sie Cache-Täuschungsangriffe durch Missbrauch des HTTP-Request-Smuggling durchführen können.

Automatische Tools

  • toxicache: Golang-Scanner zum Auffinden von Web-Cache-Vergiftbarkeitslücken in einer Liste von URLs und zum Testen mehrerer Injektionstechniken.

Referenzen


Verwenden Sie Trickest, um mühelos Workflows zu erstellen und zu automatisieren, die von den fortschrittlichsten Community-Tools der Welt unterstützt werden.
Heute Zugriff erhalten:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Erlernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen: