Cache Poisoning via URL discrepancies
Last updated
Last updated
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Dies ist eine Zusammenfassung der Techniken, die in dem Beitrag https://portswigger.net/research/gotta-cache-em-all vorgeschlagen werden, um Cache-Poisoning-Angriffe unter Ausnutzung von Diskrepanzen zwischen Cache-Proxys und Webservern durchzuführen.
Das Ziel dieses Angriffs ist es, den Cache-Server glauben zu lassen, dass eine statische Ressource geladen wird, sodass er sie cached, während der Cache-Server als Cache-Schlüssel einen Teil des Pfades speichert, aber der Webserver auf einen anderen Pfad antwortet. Der Webserver wird den echten Pfad auflösen, der eine dynamische Seite lädt (die möglicherweise sensible Informationen über den Benutzer, eine bösartige Payload wie XSS oder eine Umleitung zum Laden einer JS-Datei von der Website des Angreifers enthält).
URL-Delimiter variieren je nach Framework und Server, was sich darauf auswirkt, wie Anfragen geroutet und Antworten behandelt werden. Einige gängige Ursprung-Delimiter sind:
Semikolon: Wird in Spring für Matrixvariablen verwendet (z.B. /hello;var=a/world;var1=b;var2=c → /hello/world).
Punkt: Gibt das Antwortformat in Ruby on Rails an (z.B. /MyAccount.css → /MyAccount).
Null-Byte: Kürzt Pfade in OpenLiteSpeed (z.B. /MyAccount%00aaa → /MyAccount).
Newline-Byte: Trennt URL-Komponenten in Nginx (z.B. /users/MyAccount%0aaaa → /account/MyAccount).
Andere spezifische Delimiter könnten in diesem Prozess gefunden werden:
Schritt 1: Identifiziere nicht-cachebare Anfragen und verwende sie, um zu überwachen, wie URLs mit potenziellen Delimitern behandelt werden.
Schritt 2: Füge zufällige Suffixe zu Pfaden hinzu und vergleiche die Antwort des Servers, um festzustellen, ob ein Zeichen als Delimiter fungiert.
Schritt 3: Führe potenzielle Delimiter vor dem zufälligen Suffix ein, um zu sehen, ob sich die Antwort ändert, was auf die Verwendung des Delimiters hinweist.
Zweck: URL-Parser in sowohl Cache- als auch Ursprungsservern normalisieren URLs, um Pfade für die Endpunktzuordnung und Cache-Schlüssel zu extrahieren.
Prozess: Identifiziert Pfad-Delimiter, extrahiert und normalisiert den Pfad, indem Zeichen dekodiert und Punktsegmente entfernt werden.
Verschiedene HTTP-Server und Proxys wie Nginx, Node und CloudFront dekodieren Delimiter unterschiedlich, was zu Inkonsistenzen zwischen CDNs und Ursprungsservern führen kann, die ausgenutzt werden könnten. Zum Beispiel, wenn der Webserver diese Transformation durchführt /myAccount%3Fparam → /myAccount?param, aber der Cache-Server den Pfad /myAccount%3Fparam als Schlüssel behält, gibt es eine Inkonsistenz.
Eine Möglichkeit, diese Inkonsistenzen zu überprüfen, besteht darin, Anfragen mit URL-Kodierung verschiedener Zeichen zu senden, nachdem der Pfad ohne Kodierung geladen wurde, und zu überprüfen, ob die kodierte Pfadantwort von der zwischengespeicherten Antwort stammt.
Die Pfadnormalisierung, bei der Punkte beteiligt sind, ist auch sehr interessant für Cache-Poisoning-Angriffe. Zum Beispiel, /static/../home/index oder /aaa..\home/index, einige Cache-Server werden diese Pfade mit sich selbst als Schlüssel cachen, während andere den Pfad auflösen und /home/index als Cache-Schlüssel verwenden.
Wie zuvor hilft das Senden dieser Art von Anfragen und das Überprüfen, ob die Antwort aus dem Cache gesammelt wurde, zu identifizieren, ob die Antwort auf /home/index die Antwort ist, die gesendet wurde, wenn diese Pfade angefordert werden.
Einige Cache-Server werden immer eine Antwort cachen, wenn sie als statisch identifiziert wird. Dies könnte daran liegen:
Die Erweiterung: Cloudflare wird immer Dateien mit den folgenden Erweiterungen cachen: 7z, csv, gif, midi, png, tif, zip, avi, doc, gz, mkv, ppt, tiff, zst, avif, docx, ico, mp3, pptx, ttf, apk, dmg, iso, mp4, ps, webm, bin, ejs, jar, ogg, rar, webp, bmp, eot, jpg, otf, svg, woff, bz2, eps, jpeg, pdf, svgz, woff2, class, exe, js, pict, swf, xls, css, flac, mid, pls, tar, xlsx
Es ist möglich, einen Cache zu zwingen, eine dynamische Antwort zu speichern, indem man einen Delimiter und eine statische Erweiterung verwendet, wie eine Anfrage an /home$image.png, die /home$image.png cachen wird und der Ursprungsserver mit /home antwortet.
Bekannte statische Verzeichnisse: Die folgenden Verzeichnisse enthalten statische Dateien und daher sollte ihre Antwort zwischengespeichert werden: /static, /assets, /wp-content, /media, /templates, /public, /shared
Es ist möglich, einen Cache zu zwingen, eine dynamische Antwort zu speichern, indem man einen Delimiter, ein statisches Verzeichnis und Punkte verwendet, wie: /home/..%2fstatic/something, das /static/something cachen wird und die Antwort wird /home sein.
Statische Verzeichnisse + Punkte: Eine Anfrage an /static/..%2Fhome oder an /static/..%5Chome könnte so zwischengespeichert werden, wie sie ist, aber die Antwort könnte /home sein.
Statische Dateien: Einige spezifische Dateien werden immer zwischengespeichert, wie /robots.txt, /favicon.ico und /index.html. Diese können missbraucht werden, wie /home/..%2Frobots.txt, wo der Cache möglicherweise /robots.txt speichert und der Ursprungsserver auf /home antwortet.
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
