Security-Breakout 001 – Server Side Request Forgery (SSRF)

Willkommen zum Security-Breakout 001 der Swissmakers GmbH. Mit dieser Blogserie möchten wir Menschen für Sicherheitsfragen sensibilisieren und regelmässig neue Angriffsmethoden, Technologien und Hacking-Praktiken vorstellen. Heute präsentieren wir euch das Security-Breakout 001 – SSRF.

Was wird unter SSRF verstanden?

Server Side Request Forgery (SSRF) ist eine Web-Sicherheitslücke, die es einem Angreifer ermöglicht, die serverseitige Anwendung dazu zu bringen, Anfragen an ungewollte Ziele zu senden.

Bei einem typischen SSRF-Angriff veranlasst der Angreifer den Server, Verbindungen zu internen Diensten innerhalb der Infrastruktur der Organisation herzustellen. In anderen Fällen kann er den Server dazu zwingen, Verbindungen zu beliebigen externen Systemen herzustellen, wodurch möglicherweise sensible Daten wie Zugangsdaten offengelegt werden können.

Welche Auswirkungen haben SSRF-Angriffe?

Ein erfolgreicher SSRF-Angriff kann zu unbefugten Aktionen oder dem Zugriff auf Daten innerhalb der Organisation führen, entweder in der verwundbaren Anwendung selbst oder auf anderen Back-End-Systemen, mit denen die Anwendung kommunizieren kann. In einigen Fällen kann eine SSRF-Schwachstelle einem Angreifer ermöglichen, beliebige Befehle auszuführen.

Ein SSRF-Exploit, der Verbindungen zu externen Drittsystemen herstellt, kann bösartige Angriffe ausführen, die so aussehen, als kämen sie von der Organisation, welche die verwundbare Anwendung hostet.

Gängige SSRF-Angriffe

SSRF-Angriffe nutzen häufig Vertrauensbeziehungen aus, um einen Angriff von der verwundbaren Anwendung aus zu eskalieren und unbefugte Aktionen durchzuführen. Diese Vertrauensbeziehungen können sich entweder auf den Server selbst oder auf andere Back-End-Systeme innerhalb derselben Organisation beziehen.

SSRF-Angriffe gegen den Server selbst

Bei einem SSRF-Angriff gegen den Server selbst veranlasst der Angreifer die Anwendung, eine HTTP-Anfrage an den Server zu senden, auf dem die Anwendung gehostet wird, über seine Loopback-Netzwerkschnittstelle. Dies beinhaltet normalerweise das Bereitstellen einer URL mit einem Hostnamen wie 127.0.0.1 (eine reservierte IP-Adresse, die auf den Loopback-Adapter verweist) oder localhost (ein häufig verwendeter Name für denselben Adapter).

Nehmen wir zum Beispiel eine Einkaufsanwendung, die es dem Benutzer ermöglicht, den Lagerbestand eines bestimmten Artikels in einem bestimmten Geschäft einzusehen. Um die Lagerinformationen abzurufen, muss die Anwendung verschiedene Back-End-REST-APIs abfragen, die je nach Produkt und Geschäft unterschiedlich sind. Dies erfolgt durch Übergabe der entsprechenden URL des Back-End-API-Endpunkts über eine HTTP-Anfrage des Front-Ends. Wenn ein Benutzer den Lagerbestand eines Artikels einsehen möchte, stellt sein Browser eine Anfrage wie diese:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

shopApi=http://stock.digitecgalaxus.ch:8443/product/stock/check%3FproductId%3D6%26storeId%3D1

Dies führt dazu, dass der Server eine Anfrage an die angegebene URL stellt, den Lagerbestand abruft und diesen an den Benutzer zurückgibt.

In dieser Situation kann ein Angreifer die Anfrage z. B. mit Burp-Suite modifizieren, um eine URL anzugeben, die lokal auf den Server selbst verweist:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

shopApi=http://localhost/admin

Der Server ruft nun den Inhalt der URL /admin ab und gibt ihn an den Benutzer zurück. Natürlich könnte der Angreifer einfach die URL /admin direkt aufrufen, aber die Administratorfunktionen sind normalerweise nur für geeignete, authentifizierte Benutzer zugänglich.

Wenn ein Angreifer die URL direkt aufruft, sieht er nichts Interessantes. Wenn die Anfrage jedoch vom lokalen Rechner selbst kommt, werden die normalen Zugriffskontrollen umgangen und die Anwendung gewährt vollen Zugriff auf die Administratorfunktionen, da die Anfrage aus einem vertrauenswürdigen Bereich zu stammen scheint.

Warum verhalten sich Anwendungen auf diese Weise und vertrauen implizit Anfragen, die vom lokalen Rechner stammen?

Dies kann verschiedene Gründe haben:

• Die Zugriffskontrolle kann in einer anderen Komponente implementiert sein, die vor dem Anwendungsserver liegt. Wenn eine Verbindung zum Server selbst hergestellt wird, wird die Überprüfung umgangen.
• Zu Disaster-Recovery-Zwecken erlaubt die Anwendung möglicherweise administrativen Zugriff ohne Anmeldung für Benutzer, die vom lokalen Rechner kommen. Die Annahme hierbei ist, dass nur ein vollständig vertrauenswürdiger Benutzer direkt vom Server selbst kommt.
• Die administrative Schnittstelle kann auf einem anderen Port als die Hauptanwendung lauschen und ist daher von Benutzern möglicherweise nicht direkt erreichbar. Diese Art von Vertrauensbeziehungen, bei denen Anfragen, die vom lokalen Rechner stammen, anders behandelt werden als normale Anfragen, sind oft das, was SSRF zu einer kritischen Schwachstelle macht.

SSRF-Angriffe gegen andere Back-End-Systeme

Ein weiterer Typ von Vertrauensbeziehung, der bei serverseitiger Anfragefälschung häufig vorkommt, besteht darin, dass der Anwendungsserver mit anderen Back-End-Systemen interagieren kann, die für Benutzer nicht direkt erreichbar sind. Diese Systeme haben oft nicht routbare private IP-Adressen. Da die Back-End-Systeme normalerweise durch die Netzwerktopologie geschützt sind, weisen sie häufig eine schwächere Sicherheitslage auf. In vielen Fällen enthalten interne Back-End-Systeme sensitive Funktionen, auf die ohne Authentifizierung zugegriffen werden kann, wenn man mit den Systemen interagieren kann.

Nehmen wir das vorherige Beispiel an, es gäbe also eine administrative Schnittstelle unter der Back-End-URL: https://10.99.251.20/admin.

Hier kann ein Angreifer die SSRF-Schwachstelle ausnutzen, um auf die administrative Schnittstelle zuzugreifen, indem er folgende Anfrage sendet:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

shopApi=http://10.99.251.20/admin

Umgehung gängiger SSRF-Abwehrmassnahmen

Es ist häufig anzutreffen, dass Anwendungen SSRF-Verhalten in Verbindung mit Abwehrmassnahmen enthalten, die darauf abzielen, bösartige Ausnutzung zu verhindern. Oft können diese Abwehrmassnahmen jedoch leicht umgangen werden.

SSRF mit Blacklist basierten Eingabefiltern

Einige Anwendungen blockieren Eingaben, die Hostnamen wie 127.0.0.1 und localhost oder sensible URLs wie /admin enthalten. In solchen Fällen kann man den Filter häufig mit verschiedenen Techniken umgehen:

• Verwendung einer alternativen IP-Darstellung von 127.0.0.1, wie zum Beispiel 4436862246, 6569275799 Hierfür kann man beispielsweise spoofed.burpcollaborator.net verwenden.
• Oder die Registrierung eines eigenen Domainnamen, der auf 127.0.0.1 auflöst.
• Verschleierung blockierter Zeichenfolgen mittels URL-Codierung oder Variation der Gross- und Kleinschreibung.
• Bereitstellung einer URL, die man kontrolliert und die anschliessend auf die Ziel-URL weiterleitet. Man kann verschiedene Umleitungsstatuscodes sowie verschiedene Protokolle für die Ziel-URL verwenden. Beispielsweise kann das Wechseln von einer http: auf eine https: URL während der Umleitung dazu führen, dass einige Anti-SSRF-Filter umgangen werden.

SSRF mit Whitelist basierten Eingabefiltern

Einige Anwendungen erlauben nur Eingaben, die mit einer Whitelist erlaubter Werte übereinstimmen, mit diesen beginnen oder sie enthalten. In solchen Fällen kann man den Filter manchmal umgehen, indem man Inkonsistenzen in der URL-Analyse ausnutzt.

Die URL-Spezifikation enthält einige Funktionen, die oft übersehen werden, wenn man URLs ad hoc analysiert und validiert:

• Man kann Anmeldedaten in einer URL vor dem Hostnamen einbetten, indem man das @-Zeichen verwendet. Zum Beispiel: https://erwarteter-host:gefälschtes-pw@böser-host
• Man kann das #-Zeichen verwenden, um ein URL-Fragment anzugeben.
  Zum Beispiel: https://böser-host#erwarteter-host
• Man kann die DNS-Namenshierarchie nutzen, um die erforderlichen Eingaben in einen vollqualifizierten DNS-Namen zu platzieren, den man kontrolliert.
  Zum Beispiel: https://erwarteter-host.böser-host
• Man kann Zeichen in der URL-Codierung verschlüsseln, um den URL-Analysecode zu verwirren. Dies ist besonders nützlich, wenn der Filter für URL-codierte Zeichen anders behandelt wird als der Code, der die HTTP-Anfrage an das Back-End durchführt. Beachten Sie, dass man auch doppelte Codierung von Zeichen ausprobieren kann. Einige Server dekodieren die empfangene Eingabe rekursiv, was zu weiteren Unterschieden führen kann.
• Man kann natürlich auch Kombinationen all dieser Techniken verwenden.

Fazit

SSRF-Angriffe können schwerwiegende Konsequenzen haben, da sie unberechtigte Zugriffe auf interne Systeme und Daten ermöglichen können. Ein erfolgreich ausgeführter SSRF-Angriff kann zu Datenlecks, unautorisierten Aktionen und potenziell zur vollständigen Übernahme des Servers führen.

Es ist wichtig, dass Entwickler und Sicherheitsfachleute sich der Risiken von SSRF bewusst sind und proaktiv Massnahmen ergreifen, um diese Schwachstellen zu vermeiden. Dies beinhaltet die Implementierung von Whitelisting-Filtern, die Validierung von Benutzereingaben und die sichere Konfiguration von Netzwerkkomponenten.

Indem wir uns der potenziellen Risiken und Auswirkungen von SSRF bewusst sind und bewährte Sicherheitspraktiken anwenden, können wir dazu beitragen, die Sicherheit unserer Webanwendungen zu verbessern und Angreifern einen Schritt voraus zu sein.

Denken Sie daran, dass die Sensibilisierung und regelmässige Schulung von Entwicklern und IT-Mitarbeitern unerlässlich ist, um die Ausnutzung von solchen und anderen Sicherheitslücken zu minimieren.

Bleiben Sie wachsam und halten Sie sich über die neuesten Entwicklungen im Bereich der Cybersicherheit auf dem Laufenden. Nur so können wir den ständigen Bedrohungen einen Schritt voraus sein und unsere Daten und Systeme schützen.