Server-Side-Request-Forgery - Was es ist und wie man sich schützen kann

Server-Side-Request-Forgery

Was es ist und wie man sich schützen kann

Andrea Hauser
von Andrea Hauser
am 18. Juni 2020
Lesezeit: 8 Minuten

Keypoints

So schützen Sie sich vor Server-Side-Request-Forgery

  • Server-Side-Request-Forgery wird abgekürzt mit SSRF
  • Es handelt sich um eine Angriffstechnik, bei der ein Server dazu gebracht wird, vom Angreifer kontrollierte Requests auszulösen
  • Angriffe können gegen das interne Netzwerk, den verwundbaren Server selbst oder externe Drittparteien ausgeführt werden
  • Sich dagegen zu schützen ist nicht trivial, was sich darin zeigt, dass die Definition, was eine gültige IP-Adresse oder URL ist, auch von Bibliotheken nicht immer gleich umgesetzt wird

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:

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:

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:

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

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

Sie wollen die Sicherheit Ihrer Firewall prüfen?

Unsere Spezialisten kontaktieren Sie gern!

×
GraphQL

GraphQL

Andrea Hauser

Policy Analyzer

Policy Analyzer

Andrea Hauser

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv