Einführung

In der 2021 Version der OWASP Top Ten taucht erstmals die Schwachstelle Server Side Request Forgery (kurz: SSRF) auf. In den letzten Jahren hatten wir öfter einmal diese Schwachstelle in einem unserer Penetrationstests gefunden, weswegen wir die Schwachstelle einmal genauer beleuchten wollen. Dieser Blog-Artikel soll verschiedene Fragen beantworten, unter anderem „Was ist ein SSRF-Angriff?“, „Wie kann man SSRF ausnutzen?“ und „Wie schütze ich mich vor SSRF?“. Um den ganzen auch etwas mehr Praxisbezug zu geben, werden auch ein paar Beispiele für SSRF-Angriffe aufgeführt.

Was ist ein „Server Side Request Forgery (SSRF)“-Angriff?

Ganz einfach gesagt ist es für Angreifende möglich, einen Server dazu zu bringen, Anfragen zu verschicken. Tatsächlich werden solche Funktionen gerne auch mal für sinnvolle Zwecke eingesetzt. Ein ganz einfaches Beispiel ist die Vorschau-Funktion für Links, die in bestimmten Messengern oder Chat-Programmen angezeigt werden. Auch Schutzsoftware prüft Links, beispielsweise wenn diese in einer E-Mail stehen.

In einer Übersicht sieht der technische Ablauf folgendermaßen aus:

Der Client bringt also im Rahmen einer Aktion den Server dazu, eine Anfrage an eine Ressource zu stellen. Wer mit modernen Kommunikationsmitteln wie WhatsApp oder Slack arbeitet und dies gewohnt ist, wird sich nun vielleicht fragen, wo das eigentliche Problem ist.

Was ist das Problem bei einem SSRF-Angriff?

Wenn es also, ein gewünschtes Feature ist, wo ist denn dann das Problem? Zum einen können Angreifende damit die Herkunft von Anfragen verschleiern. Da das aber auch viel einfacher geht, ist das andere Szenario das größere Thema: das Hauptproblem bei einem SSRF-Angriff entsteht dann, wenn der Server Zugriff auf Ressourcen hat, auf die der Angreifende sonst keinen Zugriff hätte.

Folgende Grafik veranschaulicht den Angriff bei dem SSRF problematisch ist:

Hier wird das Problem schnell deutlich: eigentlich hätten Angreifende keine Möglichkeit auf das System hinter der Firewall zuzugreifen. Durch den SSRF-Angriff ist es allerdings möglich Anfragen an das Zielsystem zu senden.

Dadurch, dass diese Anfragen gesendet werden können, besteht – je nach Art der Schwachstelle – die Möglichkeit vertrauliche Informationen auszulesen, unberechtigt auf Funktionen zuzugreifen oder im schlimmsten Fall sogar dazu, Zugriff auf das interne Netzwerk zu erlangen.

Welche Beispiele gibt es für SSRF-Angriffe?

Da dies vielleicht ein wenig abstrakt wirkt, sollen im Folgenden ein paar Beispiele aufgeführt werden. Allen voran geht es um Ressourcen, die entweder nur lokal zugänglich sind, oder aber von anderen Systemen, wie einer Firewall, abgeschottet werden.

Bei einem SSRF, welches beispielsweise den NetzwerkausrüsterMimosa getroffen hat (siehe CVE-2022-21215), war es durch das Server Side Request Forgery möglich, auf Systemfunktionen zuzugreifen, die eigentlich nur innerhalb der Applikation im Backend aufrufbar hätten sein dürfen. Diese Schwachstelle hat damit den Zugriff auf private Schlüssel und sogar die Durchführung von Konfigurationsänderungen erlaubt.

Wird eine Anwendung in einer Cloud-Umgebung betrieben, stehen hier auch weitere Angriffsmöglichkeiten zur Verfügung. So können beispielsweise Metadaten-Services aufgerufen werden (z.B. über die IP 169.254.169.254). Der „Capital One“-Hack aus dem Jahre 2019 wurde dadurch ermöglicht.

Ein etwas ferneres Beispiel ist die Enttarnung von Hidden Services im Tor-Netzwerk. Die Hidden Services zeichnen sich dadurch aus, dass diese ausschließlich über Tor aufgerufen werden können. Der springende Punkt ist: Tor fungiert beim Zugriff als eine Art lokaler Proxy-Server. Wird also über ein Hidden Service auf einen Dienst zugegriffen (z.B. Webserver), so sieht der Webserver als IP-Adresse des gegenüber 127.0.0.1. Dies hatte zur Folge, dass beim Einsatz eines Apache Webservers, der standardmäßig das „status“-Modul aktiv hatte, die URL „/server-status“ aufrufen konnte. Die dort hinterlegten Informationen halfen Hidden Services zu enttarnen.

Wie entsteht diese Schwachstelle?

Damit ein SSRF-Angriff funktioniert muss es eine Funktion geben, welche Anfragen in das Netzwerk absendet. Da dies je Programmiersprache auch noch über mehrere Wege möglich ist, kann hier keine abschließende Aufzählung der theoretisch angreifbaren Funktionen gegeben werden. Wir suchen bei unseren Pentests deswegen immer nach folgenden Funktionen:

• Import- und Export-Funktionen, bzw. Upload- und Download
• Vorschau-Funktionen
• Beim Verarbeiten von XML-Dokumenten
• Beim Verarbeiten von Office-Dokumenten
• Bei Weiterleitungs- bzw. Proxy-Funktionen

Wenn keine Schutzfunktion vorgeschaltet ist, die kontrolliert, welche Ressourcen abgerufen werden können, ist der SSRF-Angriff möglich.

Wie kann ich mich vor SSRF-Angriffen schützen?

Prinzipiell gibt es zwei Arten um sich vor SSRF-Angriffen zu schützen. Tatsächlich sind auch beide relevant.

Zum einen kann der Schutz natürlich auf Applikationsebene erfolgen. Hierfür ist die Empfehlung eine Allowlist zu definieren, die sicherstellt, dass nur Ressourcen angesprochen werden können, die für die Funktion der Anwendung tatsächlich nötig ist. Dies kann eine Liste von definierten Server sein.

Auf den Einsatz von Blocklists sollte – wie immer in der Applikationssicherheit – verzichtet werden. Auf einer Blocklist würden dann z.B. die Metadaten-Services, localhost und andere lokale Netze stehen. Dennoch: hier ist der bessere Ansatz die Allowlist.

Ein Schutz ist allerdings auch auf Infrastrukturebene möglich. Zum einen natürlich durch einen sehr restriktiven Firewall-Regelsatz, welcher steuert, welche Systeme worauf zugreifen können. Gerade die Filterung von ausgehenden Verbindungen ist nicht so weit verbreitet, wie sie es sein sollte.

Im Übrigen: wer eine restriktive Firewall-Einstellung gewählt hat, hat hervorragende Möglichkeiten im Rahmen eines Security Monitorings zu erkennen, dass ein Angriff stattfindet. Fängt nämlich der Webserver auf einmal an Verbindungen nach sonst wo hin aufzubauen, ist das definitiv ein Indiz dafür, dass etwas nicht stimmt.

Des Weiteren ist auch eine Server-Härtung (inkl. Updates) für jedes einzelne System unerlässlich. Ressourcen, die „nur lokal zugreifbar sein sollten“, haben in einem SSRF-Szenario wirklich Probleme. Diese Ressourcen sollten wenn irgendwie möglich vollständig deaktiviert werden (z.B. mod_status deaktivieren). Aber auch auf Applikationsserver-Ebene kann hier gehärtet werden, beispielsweise bei PHP durch das verbieten von allow_url_fopen.

Zusammenfassung zum Server Side Request Forgery

Zusammengefasst lässt sich sagen, dass mit einem SSRF-Angriff den Angreifenden die Möglichkeit gegeben wird, Anfragen durch den Applikationsserver durchführen zu lassen. Dies kann von dem Einfachen abfließen vertraulicher Informationen, bis hin zur vollständigen Übernahme der Infrastruktur führen.

Gelöst werden kann das Thema mit dem SSRF sowohl auf Applikationsebene, hierbei vor allem durch den Einsatz einer Allowlist. Auch auf Infrastrukturebene können Vorkehrungen getroffen werden, allen voran eine restriktive Firewall-Konfiguration, sowie ein gehärteter Webserver.

Bildnachweise:

Titelbild: Adobe Stock / petrunine

Grafiken: OSA Icon Set