Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 22:52:06 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/cache-deception.md

224 lines
20 KiB
Markdown
Raw Blame History

# Cache-Vergiftung und Cache-Täuschung
<details>
<summary><strong>Erlernen Sie AWS-Hacking von Null auf Held mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Andere Möglichkeiten, HackTricks zu unterstützen:
* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen möchten** oder **HackTricks als PDF herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegramm-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) Github-Repositorys einreichen.
</details>
<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
\
Verwenden Sie [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), 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, und diese Inhalte werden vom Cache an andere Anwendungsbenutzer weitergegeben.
> * 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 weitergegeben wird, die die Seite während 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 einen zwischengespeicherten Request 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 verändern, 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**](../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
### Entdeckung: Caching von Statuscode 400
Wenn Sie vermuten, dass die Antwort im Cache gespeichert wird, könnten Sie versuchen, **Anfragen mit einem schlechten 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-Angriff durchführen).\
Ein schlecht konfigurierter Header könnte einfach `\:` als Header sein.\
_Beachten Sie, dass solche Statuscodes manchmal nicht zwischengespeichert werden, sodass dieser Test nutzlos sein wird._
### Entdeckung: Identifizieren und Auswerten von nicht gekeyten Eingaben
Sie könnten [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) verwenden, um Parameter und Header zu **brute-forcen**, die die **Antwort der Seite verä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:
```markup
<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** oder die Antwort vom Header beeinflusst wird. 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 kann sein, dass Sie es mehrere Sekunden lang versuchen müssen.\
Der Header **`X-Cache`** in der Antwort kann 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 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 vergiften, die diesen spezifischen `User-Agent` verwenden.\
Ein weiterer mit dem Cache zusammenhängender Header ist **`Age`**. Er definiert die Zeit in Sekunden, die das Objekt im Proxy-Cache war.
Beim Zwischenspeichern einer Anfrage sollten Sie **vorsichtig mit den verwendeten Headern** sein, 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 eine grundlegende XSS-Payload senden und den Cache vergiften, sodass jeder, der auf die Seite zugreift, XSS erhält:
```markup
GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"
```
### Verwendung von Web-Cache-Vergiftung 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.
```markup
GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
```
### Cache-Vergiftung mit Pfadtraversierung zum Stehlen des API-Schlüssels <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
[**Dieser Bericht erklärt**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html), 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 zum Ausnutzen von Schwachstellen bei der Web-Cache-Vergiftung <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
Manchmal müssen Sie **mehrere nicht geprüfte Eingaben** ausnutzen, um einen Cache zu missbrauchen. Zum Beispiel könnten Sie eine **Offene Weiterleitung** 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 **zu 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.
```markup
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:
```markup
GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com
```
### Ausnutzen von HTTP-Cache-Vergiftung durch Missbrauch von HTTP-Request-Smuggling
Erfahren Sie hier, wie Sie [Cache-Vergiftungsangriffe durch Missbrauch von HTTP-Request-Smuggling](http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-poisoning) durchführen können.
### Automatisiertes Testen auf Web-Cache-Vergiftung
Der [Web-Cache-Vulnerability-Scanner](https://github.com/Hackmanit/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.
Beispielhafte Verwendung: `wcvs -u example.com`
<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
\
Verwenden Sie [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), um mühelos **Workflows zu erstellen** und zu **automatisieren**, unterstützt von den weltweit **fortschrittlichsten** Community-Tools.\
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](https://cve.mitre.org/cgi-bin/cvename.cgi?name=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 (unter Vernachlässigung des Fragments). Daher 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, sondern nur Host, Pfad und Abfrage.
### GitHub CP-DoS
Das Senden eines falschen Werts im Content-Type-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, würde zu einer 403-Antwort führen, 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 Schlüsselparametern
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](https://datatracker.ietf.mrg/doc/html/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](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](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.
Beachten Sie, 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 von HTTP-Request-Smuggling](http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-deception) durchführen können.
## Automatisierte Tools
* [**toxicache**](https://github.com/xhzeem/toxicache): Golang-Scanner zum Auffinden von Web-Cache-Vergiftungsschwachstellen in einer Liste von URLs und zum Testen mehrerer Injektionstechniken.
## Referenzen
* [https://portswigger.net/web-security/web-cache-poisoning](https://portswigger.net/web-security/web-cache-poisoning)
* [https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities](https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities)
* [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712)
* [https://youst.in/posts/cache-poisoning-at-scale/](https://youst.in/posts/cache-poisoning-at-scale/)
* [https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9](https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9)
* [https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/](https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/)
<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
\
Verwenden Sie [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), um mühelos **Workflows zu erstellen** und zu **automatisieren**, unterstützt von den weltweit **fortschrittlichsten** Community-Tools.\
Heute noch Zugriff erhalten:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
<details>
<summary><strong>Lernen Sie AWS-Hacking von Null auf Held mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Andere Möglichkeiten, HackTricks zu unterstützen:
* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen möchten** oder **HackTricks im PDF-Format herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merch**](https://peass.creator-spring.com)
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) Github-Repositories einreichen.
</details>
Reference in a new issue View git blame Copy permalink