Juice Shop: Software hacken zum Spaß (Teil 2)

Im ersten Artikel dieser Reihe habe ich dir schon unsere aktuelle Fortbildung beim Method Park vorgestellt: Wir stärken unsere Kenntnisse in IT-Sicherheit, indem wir unsere eigene Instanz des OWASP Juice Shop hacken. Heute will ich zwei weitere Herausforderungen des Juice Shop vorstellen, und dir zeigen, wie ich diese gelöst habe.

ACHTUNG SPOILER!!!

Juice Shop Herausforderung: XXE Data Access

XML External Entity (XXE) Attacken sind außerhalb der IT-Sicherheit Community nicht so bekannt wie andere prominentere Attacken beispielsweiße Cross-Site Scripting (XSS). Trotzdem ist diese Attacke sehr gefährlich, da Angreifer sie verwenden können, um vertrauliche Daten zu extrahieren.

Potenziell angreifbar sind alle Programme/Bibliotheken die XML verarbeiten. Auch Bibliotheken die nur indirekt XML-Dateien verarbeiten, wie beispielsweiße SVG oder docx, können angreifbar sein. Für die Attacke nutzt man das Konzept der External Entity aus, das im XML-Standard spezifiziert ist. Dies erlaubt es in XML externe Daten einzubetten. Dieser Mechanismus wird detailliert auf der OWASP Webseite erläutert.

Durch eine vorherige Herausforderung weiß ich, dass der Juice Shop eine Schnittstelle enthält, die XML verarbeitet. Unter „Complaint“ gibt es die Möglichkeit Dateien hochzuladen. Trotz einer bereits veralteten Funktion können wir hier auch XML-Dateien hochladen.

Complaint Upload Formular

Zum Testen des Verhaltens erstelle ich eine kleine XML-Testdatei und lade diese auf den Server:


<?xml version="1.0" encoding="ISO-8859-1"?>
<test>abc</test>

Dieser antwortet mit einer Fehlermeldung, dass aus Sicherheitsgründen diese Schnittstelle überholt ist und anscheinend nicht mehr unterstützt wird. Allerdings enthält die Antwort auch den Inhalt unserer Datei.

Resultat des XML Uploads

Ich erstelle mir eine weitere XML-Datei, die eine External Entity inkludiert. Mit etwas Glück nutzt der Server einen XML-Parser, um den Inhalt des Uploads zu analysieren und anschließend in der Fehlermeldung zurückzugeben. Mit noch mehr Glück löst er auch meinen External Entity Verweis auf und inkludiert mir den Inhalt von /etc/passwd. Historisch waren in dieser Datei alle Nutzer des Systems und deren gehashte Passwörter gespeichert. Die Passwörter werden in heutigen Systemen in der /etc/shadow Datei ausgelagert.



<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE test [
  <!ELEMENT test ANY >
  <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<test>&xxe;</test>

Als Antwort erhalte ich wieder die gewohnte Fehlermeldung, aber der Parser hat die External Entity aufgelöst und den Inhalt integriert, bevor der Server die Antwort an mich zurückgeschickt hat. Yeah! Konfetti ist zu sehen und ich halte nun den Inhalt der /etc/passwd Datei in Händen. Mit dieser Methode hätte ich auch andere Dateien aus dem Dateisystem extrahieren können.

Erfolgreiche XXE Attacke

Um den Schaden einer potenziellen XXE-Attacke möglichst gering zu halten, solltest du die Rechte des XML-Parser Prozesses einschränken. Der Prozess sollte nur Zugriff auf benötigte Daten erhalten. Als Entwicklerin/Entwickler kannst du XXE-Attacken auch komplett verhindern, indem du das Feature Document Type Definition (DTD) im XML-Parser deaktivierst.

Juice Shop Herausforderung: Allowlist Bypass

Auch in dieser Herausforderung nutze ich eine Schnittstelle des Juice Shop, die mir schon durch eine vorherige Herausforderung bekannt ist. Der Shop verwendet die URL https://juice.internal/redirect, um auf andere Webseiten weiterzuleiten. Beispielsweiße auf den Quellcode des Juice Shops, der auf Github gehostet wird: https://juice.internal/redirect?to=https://github.com/bkimminich/juice-shop. Abgesichert ist diese Schnittstelle über eine Whitelist, die eine Weiterleitung nur auf spezifizierte Seiten erlaubt. In dieser Herausforderung soll ich den Whitelist-Mechanismus umgehen und mich zu einer beliebigen Seite weiterleiten lassen.

Juice Shop: Weiterleitung auf Github

Als Erstes teste ich die naive Lösung: https://juice.internal/redirect?to=https://google.com. Der Juice Shop quittiert mir meinen Versuch mit einer Fehlermeldung: Unbekanntes Ziel!

Als Nächstes versuche ich auf ein spezifischeres Ziel weiterzuleiten. Dazu hänge ich Pfadteile an die Github URL: https://juice.internal/redirect?to=https://github.com/bkimminich/juice-shop/tree/master/data. Dieser Versuch ist erfolgreich. Der Juice Shop führt die Weiterleitung durch.

Überprüft der Juice Shop vielleicht nur, ob ein Eintrag der Whitelist im Parameter enthalten ist und nicht, ob dieser exakt dem Eintrag entspricht? Meine Vermutung wird durch den Test mit https://juice.internal/redirect?to=https://www.google.com/https://github.com/bkimminich/juice-shop bestätigt. Der Juice Shop leitet prinzipiell weiter, aber das Ziel existiert so natürlich nicht.

Die letzte Hürde nehme ich noch, indem ich eine Raute # (%23 URL-Encodiert) in den Parameter einfüge: https://juice.internal/redirect?to=https://www.google.com/%23https://github.com/bkimminich/juice-shop. Nach absenden dieser Anfrage werde ich erfolgreich zu Google weitergeleitet. Ich nutze die Raute, um ein URL Fragment zu spezifizieren. Der Juice Shop validiert weiterhin nur, ob ein Whitelist-Eintrag im Parameter der Anfrage vorhanden ist. Die Weiterleitung wird erfolgreich durchgeführt und der URL Fragment-Teil (https://github.com/bkimminich/juice-shop) wird vom Ziel (Google) ignoriert.

Man könnte diese Sicherheitslücke beheben, indem die Redirect API den Parameter auf genaue Übereinstimmung in der Whitelist überprüft.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.