Web Cache Deception Burp-Erweiterung

Eine Burp-Erweiterung zum Testen von Anwendungen auf Schwachstellen gegenüber dem Web Cache Deception-Angriff.

Nachdem die Erweiterung geladen wurde, kann sie im Reiter Target – Sitemap aufgerufen werden. Klicken Sie mit der rechten Maustaste auf die zu testende Ressource. Es wird ein kontextsensitives Menüelement namens „Web Cache Deception Test“ angezeigt, mit dem die Tests durchgeführt werden können. Wenn die Ressource anfällig ist, wird ein Issue erstellt, das die Schwachstelle beschreibt.

Das kontextsensitive Menüelement ist auch für Anfragen im Reiter Proxy – HTTP History verfügbar.

Installation

• Laden Sie die Datei WebCacheDeceptionScanner.jar herunter.
• Öffnen Sie in Burp Suite den Reiter Extender. Klicken Sie im Reiter Extensions auf die Schaltfläche Add.
• Wählen Sie die heruntergeladene Jar-Datei aus -> Next.
• Überprüfen Sie die Installation auf Fehlermeldungen.

Schwachstelle

Im Februar 2017 enthüllte der Sicherheitsforscher Omer Gil einen neuen Angriffsvektor namens „Web Cache Deception“ (https://omergil.blogspot.co.il/2017/02/web-cache-deception-attack.html).

Der Web Cache Deception-Angriff kann verheerende Folgen haben, ist aber sehr einfach durchzuführen:

1. Der Angreifer zwingt das Opfer, einen Link auf dem gültigen Anwendungsserver zu öffnen, der die Payload enthält.
2. Der Angreifer ruft die neu zwischengespeicherte Seite auf dem Server mit demselben Link auf, um genau dieselbe Seite wie das Opfer zu sehen.

** Natürlich macht dieser Angriff nur Sinn, wenn die dem Angreifer zugängliche anfällige Ressource sensible Daten zurückgibt.

Der Angriff hängt von einer sehr spezifischen Reihe von Umständen ab, um die Anwendung anfällig zu machen: 1. Die Anwendung liest nur den ersten Teil der URL, um die zurückzugebende Ressource zu bestimmen.
Wenn das Opfer anfordert:

https://www.example.com/my_profile

Die Anwendung gibt die Profilseite des Opfers zurück. Die Anwendung verwendet nur den ersten Teil der URL, um zu bestimmen, dass die Profilseite zurückgegeben werden soll. Wenn die Anwendung eine Anfrage erhält für

https://www.example.com/my_profile_test

Sie würde immer noch die Profilseite des Opfers zurückgeben, wobei der hinzugefügte Text ignoriert wird. Gleiches gilt für andere URLs wie

https://www.example.com/my_profile/test

2. Der Anwendungs-Stack speichert Ressourcen basierend auf ihren Dateierweiterungen zwischen, nicht basierend auf Cache-Header-Werten. Wenn der Anwendungs-Stack so konfiguriert ist, dass er Bilddateien zwischenspeichert. Er speichert alle Ressourcen mit den Endungen .jpg .png oder .gif zwischen. Das bedeutet, dass z. B. das Bild unter

https://www.example.com/images/dog.jpg

Würde beim ersten Aufruf vom Anwendungsserver abgerufen. Alle nachfolgenden Anfragen für das Bild werden aus dem Cache abgerufen, wobei dieselbe Ressource zurückgegeben wird, die ursprünglich zwischengespeichert wurde (solange die Cache-Timeout-Dauer eingestellt ist).

Angriff

Diese Voraussetzungen können wie folgt für den Web Cache Deception-Angriff ausgenutzt werden:  

Schritt 1: Ein Angreifer verleitet das Opfer, einen bösartig erstellten Link zu öffnen:

  https://www.example.com/my_profile/test.jpg  

• Die Anwendung ignoriert den Teil 'test.jpg' der URL, die Profilseite des Opfers wird geladen.
• Der Caching-Mechanismus identifiziert die Ressource als Bild und speichert sie zwischen.  

Schritt 2: Der Angreifer sendet eine GET-Anfrage für die zwischengespeicherte Seite:

https://www.example.com/my_profile/test.jpg  

• Die zwischengespeicherte Ressource, die tatsächlich die Profilseite des Opfers ist, wird an den Angreifer (und an alle anderen, die sie anfordern) zurückgegeben.

GEISTESBLITZ Wie einfach ist das?

Änderungsprotokoll

1.1

• Geändert, sodass das Scannen nach diesem Problem beim aktiven Scan enthalten ist.
• Aktualisiertes Scannen, um Erkenntnisse aus realen Umgebungen einzubeziehen.
• Die Meldung erfolgt jetzt nur noch durch Hinzufügen

1.0 Veröffentlichung