Bei Server-Side-Request-Forgery (SSRF) wird ein Server dazu gebracht, von Angreifern kontrollierte Anfragen auszulösen. Die dadurch ausgelösten Requests können auf den verwundbaren Server selbst, weitere interne Systeme oder je nach Firewall-Einstellungen sogar auf externe Drittsysteme geleitet werden. Dadurch kann es unter anderem möglich werden, auf interne Daten zuzugreifen oder interne Aktionen auszulösen. Im schlimmsten Fall kann die SSRF-Schwachstelle sogar bis zu einer Remote-Code-Execution führen. Wenn die Requests an ein externes Drittsystem versandt werden, kann ein Angreifer damit den verwundbaren Server als den Übeltäter dastehen lassen und bleibt für das Drittsystem völlig unbekannt.

Grundsätzlich können alle Features anfällig sein, die Requests auslösen, bei denen der Empfänger des Requests mindestens aus Teilen von Benutzereingaben abhängig ist. Bei den folgenden Bereichen handelt es sich allerdings um Features, die oft auf SSRF anfällig sind:

• WebHooks: Ein WebHook löst bei einem bestimmten Ereignis einen Request an einen durch den Benutzer definierten Endpunkt aus. Beispiele für Schwachstellen aufgrund von WebHooks finden sich unter anderem bei GitHub, wo die Schwachstelle schlussendlich zu Remote-Code-Execution führte und bei einem Zahlungsportal aus Südostasien, wo die Schwachstelle für den Zugriff auf AWS Private Keys ausgenutzt werden konnte.
• Bilder- und Dateiuploads: Dabei kann ein Angreifer beim Parsen einer Datei Requests auslösen. Beispiele für diese Schwachstellen sind der WordPress Video Upload, bei dem FFmpeg genutzt wird, um interne Dateien zu lesen. Eine ähnliche Schwachstelle hatte auch der Video zu Gif Konverter von Imgur. Ebenfalls problematisch kann es sein, wenn die Datei von einer externen URL heruntergeladen wird. Dabei kann die externe URL durch einen Angreifer verändert werden. Als Beispiele können hier unter anderem Instacart, Ghost CMS und DuckDuckGo genannt werden.
• XML-Parser: Speziell hervorgehoben werden sollten die XML-Parser, da es in XML unterschiedliche Möglichkeiten gibt, Ressourcen einzubinden. Als Beispiel kann Shopify angeschaut werden. Dabei konnte anhand von vorhandenen beziehungsweise nicht vorhandenen Bildern auf dem Server das Existenz sowie die Versionen von Bibliotheken enumeriert werden. Bei Rockstar Games konnten dank eines SVG zu PNG Konverters interne Dateien gelesen werden.

SSRF gegen den Server selbst

Bei SSRF-Angriffen gegen den verwundbaren Server selbst wird dieser dazu gebracht, eine Request an sein eigenes Loopback-Interface zu senden. Dabei wird die ursprüngliche URL im Request zum Beispiel durch 127.0.0.1 oder localhost ersetzt. Da die ausgelöste Request von einer internen Quelle stammt und nicht mehr von Extern, kann es sein, dass dabei auf mehr Informationen zugegriffen werden kann. Ein Angreifer kann ebenfalls versuchen, die offenen Ports des verwundbaren Servers durch SSRF herauszufinden. Da hier auch wieder von einer internen Verbindung ausgegangen wird, kann es sein, dass mehr offene Ports festgestellt werden können und auf nur intern zugängliche Interfaces zugegriffen werden kann.

Ein Angreifer ist allerdings nicht zwingend auf HTTP und HTTPS-Requests eingeschränkt. Wenn ein Angreifer die volle URL kontrollieren kann, kann er auch das Schema verändern. Und so mit file:// auf Dateien des verwundbaren Servers zugreifen. Weitere spannende Schemas sind zum Beispiel ftp:// und gopher://.

SSRF gegen das interne Netzwerk

Ähnlich wie gegen den verwundbaren Server selbst, können auch Requests ans interne Netzwerk versandt werden und so ein Portscanner für das interne Netzwerk erstellt werden. Für einen Angreifer erschwerend kommt hier allerdings dazu, dass der interne Netzwerk-Range wahrscheinlich nicht bekannt ist. Ein Angreifer muss also zuerst den Netzwerk-Range herausfinden. Anders ist dies, wenn sich der Server in der Cloud befindet. Denn dort gibt es weitere Angriffsziele, wie zum Beispiel die AWS und Google Cloud Metadaten Endpunkte. Über diese Endpunkte können teilweise sogar Access Tokens herausgefunden werden. Mit diesen Access Tokens kann im schlimmsten Fall auf die gesamte Umgebung eines Unternehmens in der Cloud zugegriffen werden. Bei interessanten Cloud-Metadaten-URLs handelt es sich zum Beispiel um die folgenden:

• http://169.254.169.254/latest/user-data (AWS)
• http://instance-data/latest/meta-data/iam/security-credentials/ (ebenfalls AWS)
• http://metadata.google.internal/computeMetadata/v1beta1/ (Google Cloud)
• Noch viele weitere interessanten Endpunkte werden zum Beispiel im GitHub Repository PayloadsAllTheThings aufgeführt

Umgehung von SSRF Gegenmassnahmen

Falls es notwendig ist URLs oder Domains aus Benutzereingaben abzuleiten, ist es nicht einfach, sich wirkungsvoll gegen SSRF-Angriffe zu schützen. Dies liegt unter anderem auch daran, dass – wie Untersuchungen von Orange Tsai aufzeigen – sich nicht einmal Bibliotheken einig sind, wie gewisse IP-Adressen oder URLs zu interpretieren sind. In seinen Untersuchungen zeigt er zum Beispiel auf, dass die folgende URL von unterschiedlichen Python Bibliotheken unterschiedlich interpretiert wird:

http://1.1.1.1 &@2.2.2.2# @3.3.3.3/

Zum Zeitpunkt seiner Analyse interpretierten die Bibliotheken urllib2 und httplib 1.1.1.1 als die gültige IP-Adresse. Allerdings wird von der Bibliothek requests die IP-Adresse 2.2.2.2 als die gültige Adresse interpretiert. Die IP-Adresse 3.3.3.3 schlussendlich wird von der Bibliothek urllib als die gültige IP-Adresse interpretiert. Wenn also im Code bei der Überprüfung von IP-Adressen und der Ausführung der effektiven Requests unterschiedliche Bibliotheken verwendet werden, kann eine Kombination dieser Interpretationen dazu führen, dass ein Angreifer die Überprüfung von IP-Adressen umgehen kann.

Dabei handelt es sich allerdings nicht um den einzigen Trick, der bei der Umgehung von unsorgfältigen SSRF-Gegenmassnahmen angewandt werden kann. So kann auch versucht werden, eine IP-Adresse auf unterschiedliche Arten zu schreiben. Bei sämtlichen unten gezeigten Beispielen handelt es sich um IP-Adressen, die auf den localhost verbinden:

• http://localhost
• http://127.0.0.1
• http://127.1
• http://127.127.127.127
• http://0/
• http://[::]:80/
• http://2130706433 (dezimal IP-Adresse)
• http://0x7F000001 (hexadezimal IP-Adresse)
• Und auch hier gibt es noch etliche weitere Beispiele.

Ein Angreifer kann sich weiter auch DNS zu Gebrauch machen. Wenn durch den Angreifer externe DNS-Requests ausgelöst werden können, kann ein Angreifer auf eine DNS-Request mit einer beliebigen IP-Adresse antworten. Wenn der Angreifer also zum Beispiel evil.com kontrolliert und für diese Domain für die Bekanntgabe der IP-Adresse angefragt wird, kann der Angreifer mit 127.0.0.1 Antworten, und so eventuelle Einschränkungen umgehen.

Wirkungsvolle Gegenmassnahmen

Wie bereits erwähnt, ist es nicht einfach, sich gegen SSRF-Angriffe wirkungsvoll zu schützen. Grundsätzlich sollte immer erst abgeklärt werden, ob für die Erstellung einer Domain, URL oder IP-Adresse tatsächlich Benutzereingaben notwendig sind. Soweit möglich sollten diese Angaben nicht durch Benutzer gesteuert werden können. Falls es allerdings nicht möglich ist, dies umzusetzen, so muss zwischen zwei Ansätzen unterschieden werden. Einerseits gibt es Fälle, in denen vom Server nur bekannte und vertrauenswürdige Applikationen angesteuert werden müssen. In diesem Fall sollte ein Whitelist-Ansatz gewählt werden, um die Eingaben des Benutzers zu überprüfen. Zusätzlich sollte auf Netzwerkebene sichergestellt werden, dass auch nur die notwendigen Server wirklich erreichbar sind. Andererseits gibt es allerdings auch Fälle, bei denen die externen Domains und IP-Adressen nicht eingeschränkt werden können, da die Zielserver für die Applikation unbekannt sind. Dies ist zum Beispiel der Fall, wenn WebHooks angeboten werden. In diesen Fällen kann kein Whitelist-Ansatz verwendet werden, dementsprechend wird auf das Konzept einer Blacklist zurückgegriffen. Wobei deutlich gemacht werden muss, dass eine Blacklist niemals so effektiv wie eine Whitelist ist. Dementsprechend ist es umso wichtiger, dass sich solche Server in einer eigenen Zone befinden, damit ein Angreifer bei Umgehung der Blacklist keinen Zugriff auf das interne Netzwerk erlangt.

Vertieftere Erklärungen zu Gegenmassnahmen gegen SSRF sind im OWASP Cheat Sheet Server-Side-Request-Forgery Prevention zu finden.

Fazit

Bei Server-Side-Request-Forgery handelt es sich um eine Schwachstelle, die vielseitig ausgenutzt werden kann. Dementsprechend können die Auswirkungen von Enumeration von internen Services über Zugriff auf interne Informationen bis Remote-Code-Execution reichen. Angreifbar sind dabei sowohl der Server selbst, das interne Netzwerk sowie externe Drittparteien. Um sich gegen SSRF zu schützen, sollte wenn immer möglich keine Benutzereingaben in URLs, Domains oder IP-Adressen genutzt werden. Falls Benutzereingaben notwendig sind, sollte auf ein Whitelist-Verfahren zurückgegriffen werden, sowie auf Netzwerkebene sichergestellt werden, dass nur notwendige Zugriffe tatsächlich möglich sind.

Über die Autorin

Andrea Hauser hat ihren Bachelor of Science FHO in Informatik an der Hochschule für Technik Rapperswil abgeschlossen. Sie setzt sich im offensiven Bereich in erster Linie mit Web Application Security Testing und der Umsetzung von Social Engineering Kampagnen auseinander. Zudem ist sie in der Forschung zum Thema Deepfakes tätig. (ORCID 0000-0002-5161-8658)

Links

• https://blog.orange.tw/2017/07/how-i-chained-4-vulnerabilities-on.html
• https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html#cases
• https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Request%20Forgery#ssrf-url-for-cloud-instances
• https://hackerone.com/reports/115857
• https://hackerone.com/reports/158016
• https://hackerone.com/reports/223203
• https://hackerone.com/reports/237381
• https://hackerone.com/reports/347139
• https://hackerone.com/reports/358119
• https://hackerone.com/reports/508459
• https://hackerone.com/reports/793704
• https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf