Einführung
Server-Side Request Forgery (SSRF) ist eine Websicherheitslücke, die es einem Angreifer ermöglicht, die serverseitige Anwendung dazu zu bringen, HTTP-Anfragen an eine beliebige Domain seiner Wahl zu senden.
Der entscheidende Punkt ist, dass der Server die Anfrage stellt und nicht der Angreifer direkt. Das bedeutet, dass die Anfrage die Netzwerkposition, die Vertrauensbeziehungen und den Zugriff auf interne Ziele des Servers erbt.
Bei einem typischen SSRF-Angriff könnte der Angreifer den Server dazu veranlassen, eine Verbindung zu internen Diensten innerhalb der Infrastruktur des Unternehmens herzustellen. In anderen Fällen kann er den Server zwingen, eine Verbindung zu beliebigen externen Systemen aufzubauen, was potenziell zum Abfluss sensibler Daten wie Autorisierungsdaten führen kann.
In diesem Lab interagieren Sie mit einer simulierten, anfälligen Webanwendung. Sie lernen, wie man die SSRF-Schwachstelle identifiziert, wie grundlegende Sicherheitsfilter versuchen, bösartige Anfragen zu blockieren, wie man diese Filter umgeht und schließlich sensible interne Daten sowie simulierte Cloud-Metadaten extrahiert. Um die Übung mit geteilten Lab-Umgebungen kompatibel zu halten, verwendet der simulierte Metadaten-Dienst einen nicht privilegierten hohen Port anstelle von Port 80.
URL-Parameter identifizieren
In diesem Schritt lernen Sie, wie man potenzielle SSRF-Schwachstellen erkennt, indem Sie nach Anwendungsfunktionen suchen, die Daten von externen URLs abrufen.
Viele Webanwendungen müssen Ressourcen von anderen Servern abrufen. Beispielsweise könnte eine Anwendung ein Profilbild von einer Social-Media-Seite laden oder Daten von einer Drittanbieter-API abrufen. Wenn die Anwendung eine URL als Benutzereingabe entgegennimmt und diese ohne ordnungsgemäße Validierung abruft, kann sie anfällig für SSRF sein.
Deshalb tritt SSRF häufig in ansonsten legitimen "URL-Abruf"-Funktionen auf. Das gefährliche Verhalten ist in einem Arbeitsablauf verborgen, der aus Produktsicht normal aussieht.
Eine anfällige Webanwendung wurde für Sie auf Port 8080 gestartet. Diese Anwendung verfügt über einen Endpunkt /check, der einen url-Parameter akzeptiert. Er ist darauf ausgelegt, den Status externer Websites zu überprüfen.
Sie können diese Funktionalität testen, indem Sie die Anwendung bitten, eine harmlose externe Website abzurufen, wie zum Beispiel http://example.com. Verwenden Sie den Befehl curl in Ihrem Terminal, um eine HTTP-GET-Anfrage an die anfällige Anwendung zu senden. Falls curl neu für Sie ist: Betrachten Sie es als einen einfachen Kommandozeilen-Webbrowser, der Anfragen sendet und die Antwort des Servers im Terminal ausgibt.
curl "http://localhost:8080/check?url=http://example.com"
Wenn Sie diesen Befehl ausführen, empfängt die auf Port 8080 laufende Anwendung Ihre Anfrage, extrahiert den url-Parameter und stellt eine eigene HTTP-Anfrage an http://example.com. Anschließend sendet sie die HTML-Antwort an Sie zurück.
<!doctype html>
<html>
<head>
<title>Example Domain</title>
...
Indem Sie beobachten, dass der Server den Inhalt der angeforderten URL erfolgreich abgerufen und zurückgegeben hat, haben Sie bestätigt, dass der url-Parameter aktiv verarbeitet und für serverseitige Anfragen verwendet wird. Dies ist das erste Anzeichen für eine SSRF-Schwachstelle.
SSRF gegen Localhost (127.0.0.1) testen
In diesem Schritt versuchen Sie, die SSRF-Schwachstelle auszunutzen, um auf einen internen Dienst zuzugreifen, der auf dem Server läuft.
Die Hauptgefahr von SSRF besteht darin, dass der Server, der die Anfrage stellt, oft eine privilegierte Position im Netzwerk einnimmt. Er kann auf interne Dienste zugreifen, die nicht für das öffentliche Internet freigegeben sind. In unserem Szenario läuft ein internes Admin-Panel auf Port 5000. Dieses Admin-Panel ist an 127.0.0.1 (localhost) gebunden, was bedeutet, dass es nur vom Server selbst aus aufgerufen werden kann, nicht von einer anderen Maschine. Sie können sich 127.0.0.1 als den Computer vorstellen, der mit sich selbst spricht.
Als Angreifer können Sie die SSRF-Schwachstelle auf Port 8080 nutzen, um den Server dazu zu bringen, in Ihrem Namen auf das Admin-Panel auf Port 5000 zuzugreifen.
Versuchen Sie, auf das interne Admin-Panel zuzugreifen, indem Sie dessen lokale URL an den anfälligen /check-Endpunkt übergeben.
curl "http://localhost:8080/check?url=http://127.0.0.1:5000/admin"
Wenn Sie diesen Befehl ausführen, werden Sie feststellen, dass die Anfrage nicht erfolgreich ist. Stattdessen erhalten Sie eine Fehlermeldung.
Error: Localhost access is blocked by WAF!
Entwickler implementieren häufig Web Application Firewalls (WAF) oder Eingabefilter, um SSRF-Angriffe zu verhindern. In diesem Fall prüft die Anwendung, ob die bereitgestellte URL die Zeichenfolge 127.0.0.1 oder localhost enthält. Da Ihre Eingabe mit diesem Filter übereinstimmte, hat die Anwendung die Anfrage blockiert.
Einfache String-Filter sind anfällig, da Netzwerkziele mehrere äquivalente Darstellungen haben können. Verteidiger benötigen eine Validierung, die die kanonische Netzwerkbedeutung versteht und nicht nur den wörtlichen Text.
Zu verstehen, wie die Anwendung Eingaben filtert, ist ein entscheidender Schritt bei der Ausnutzung von SSRF, da es Ihnen zeigt, welche Einschränkungen Sie umgehen müssen.
Eingabefilter umgehen
In diesem Schritt lernen Sie, wie Sie den grundlegenden Eingabefilter umgehen, auf den Sie im vorherigen Schritt gestoßen sind.
Umgehungstechniken funktionieren hier, weil URL-Parsing, Hostname-Auflösung und Eingabefilter nicht immer dieselben Interpretationsregeln verwenden.
Eingabefilter, die auf einfachem String-Abgleich basieren (wie das Blockieren von 127.0.0.1), sind oft fehlerhaft, da IP-Adressen auf verschiedene Weise dargestellt werden können. Der Netzwerk-Stack des Betriebssystems löst diese alternativen Darstellungen zwar zum selben Ziel auf, aber der Textfilter der Anwendung erkennt sie möglicherweise nicht.
Hier sind einige gängige Möglichkeiten, die Localhost-IP-Adresse (127.0.0.1) darzustellen, die einen schlecht implementierten Filter umgehen könnten. Sie können eine verkürzte IP wie 127.1, eine dezimale IP wie 2130706433, eine oktale IP wie 0177.000.000.001 oder eine hexadezimale IP wie 0x7f000001 verwenden.
Da die Anwendung nur die exakten Zeichenfolgen 127.0.0.1 und localhost blockiert, können Sie die verkürzte IP-Darstellung 127.1 verwenden, um den Filter zu umgehen und auf das interne Admin-Panel zuzugreifen.
Führen Sie den folgenden Befehl aus, um die Umgehungstechnik zu testen:
curl "http://localhost:8080/check?url=http://127.1:5000/admin"
Da 127.1 nicht mit den blockierten Zeichenfolgen übereinstimmt, lässt die Anwendung die Anfrage zu. Der Netzwerk-Stack des Servers löst 127.1 zu 127.0.0.1 auf und ruft erfolgreich die interne Admin-Seite ab.
Welcome to the Internal Admin Panel. Secret Key: SSRF_ADMIN_SUCCESS
Sie haben den Eingabefilter erfolgreich umgangen und die SSRF-Schwachstelle ausgenutzt, um auf einen eingeschränkten internen Dienst zuzugreifen.
Auf interne Metadaten zugreifen
In diesem Schritt nutzen Sie die SSRF-Schwachstelle, um auf sensible Cloud-Metadaten zuzugreifen.
Wenn Anwendungen in Cloud-Umgebungen (wie AWS, Google Cloud oder Azure) gehostet werden, haben sie oft Zugriff auf eine spezielle, nicht routbare IP-Adresse: 169.254.169.254. Diese Adresse hostet den Instance Metadata Service (IMDS), der Informationen über die laufende Cloud-Instanz bereitstellt, einschließlich hochsensibler temporärer IAM-Anmeldeinformationen (Identity and Access Management). "Nicht routbar" bedeutet, dass die Adresse für die lokale Cloud-Infrastruktur gedacht ist und nicht für den allgemeinen öffentlichen Internetzugriff.
Wenn ein Angreifer eine SSRF-Schwachstelle in einer Cloud-gehosteten Anwendung findet, ist das Abfragen dieses Metadaten-Endpunkts oft sein Hauptziel, da dies zur vollständigen Kompromittierung der Cloud-Umgebung führen kann.
In dieser Lab-Umgebung läuft ein simulierter Cloud-Metadaten-Dienst auf 169.254.169.254:8000. Der echte Cloud-Metadaten-Dienst verwendet üblicherweise Port 80, aber dieses Lab verwendet absichtlich Port 8000, damit der Dienst ohne spezielle Privilegien und ohne Konflikte mit anderer Software gestartet werden kann. Verwenden Sie zunächst die SSRF-Schwachstelle, um die verfügbaren Metadaten-Verzeichnisse aufzulisten.
curl "http://localhost:8080/check?url=http://169.254.169.254:8000/latest/meta-data/"
Der Server ruft die Auflistung des Metadaten-Verzeichnisses ab und gibt sie an Sie zurück.
iam/security-credentials/admin-role
Die Ausgabe zeigt eine IAM-Rolle namens admin-role. Sie können diesen Pfad nun an Ihren SSRF-Payload anhängen, um die tatsächlichen Sicherheitsanmeldeinformationen zu extrahieren, die mit dieser Rolle verknüpft sind.
Führen Sie den folgenden Befehl aus, um die sensiblen Anmeldeinformationen abzurufen:
curl "http://localhost:8080/check?url=http://169.254.169.254:8000/latest/meta-data/iam/security-credentials/admin-role"
Der simulierte Metadaten-Dienst gibt die Anmeldeinformationen im JSON-Format zurück.
{"AccessKeyId":"AKIAIOSFODNN7EXAMPLE","SecretAccessKey":"wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"}
Falls diese Anfrage in Ihrer Umgebung keine Daten zurückgibt, prüfen Sie kurz /tmp/meta.log und bestätigen Sie, dass ein Dienst auf 169.254.169.254:8000 lauscht.
Durch das erfolgreiche Extrahieren dieser Anmeldeinformationen haben Sie die schwerwiegenden Auswirkungen einer SSRF-Schwachstelle in einer Cloud-Umgebung demonstriert.
Zusammenfassung
In diesem Lab haben Sie erfolgreich eine Server-Side Request Forgery (SSRF)-Schwachstelle untersucht und ausgenutzt. Sie haben gelernt, wie man anfällige URL-Parameter durch Beobachtung des serverseitigen Abrufverhaltens identifiziert. Anschließend sind Sie auf einen grundlegenden Eingabefilter gestoßen, der den lokalen Zugriff blockieren sollte, und haben diesen erfolgreich durch alternative IP-Adressdarstellungen umgangen. Abschließend haben Sie die kritische Auswirkung von SSRF demonstriert, indem Sie sensible simulierte Cloud-Metadaten-Anmeldeinformationen extrahiert haben. Das Verständnis dieser Techniken ist sowohl für die Identifizierung von Schwachstellen bei Sicherheitsbewertungen als auch für die Implementierung robuster Abwehrmechanismen in Webanwendungen unerlässlich.
