© saicle/Shutterstock.com
SSRF - was ist das, was kann das, und ist das etwa gefährlich?

Fälschungsalarm auf dem Server


Das Thema dieses Artikels ist eine Schwachstelle und ein Angriff, der oft nicht weiter beachtet wird. Ist diese Missachtung einer möglichen Gefahr gerechtfertigt, oder sollte man vor den Angriffen nicht doch besser auf der Hut sein?

Sie kennen ja sicherlich die Cross-Site Request Forgery (CSRF), bei der eine Webseite eine Aktion auf einer anderen Website im Namen des aktuellen Benutzers ausführt, während dieser dort angemeldet ist. Ein beliebtes Beispiel ist ein IMG-Tag in der Seite des Angreifers, dessen SRC-Attribut den Link zum Ausloggen des Benutzers auf der angegriffenen Website enthält [1]. Also etwa sowas in der Art:

<img src="http://www.angegriffene-site.example/benutzer/logout.php">

Wenn der Browser versucht, das Bild zu laden, sendet er einen Request an den URL http://www.angegriffene-­site.­example/benutzer/logout.php und fügt die von www.angegriffene-site.example gesetzten Cookies hinzu. An denen wird der Benutzer erkannt und ausgeloggt.

Wow, was für eine Gefahr!

Da zittern gleich alle vor Angst, oder? Natürlich nicht. Aber das ist auch gar nicht beabsichtigt. Dieses Beispiel zeigt nur, wie CSRF funktioniert. Tatsächlich sind sehr viel gefährlichere Angriffe möglich; einige neue Entwicklungen im Bereich der CSRF werden in der nächsten Ausgabe des PHP Magazins vorgestellt.

Wer aber nur das einfache Beispiel kennt, kommt zum Schluss, dass CSRF ja eigentlich harmlos ist. Und genauso sieht es auf den ersten Blick bei der mit der CSRF weitläufig verwandten Server-side Request Forgery (SSRF) aus. Beide gehen übrigens auf das uralte Problem des „Confused Deputy“ [2] zurück, falls Sie die Hintergründe interessieren.

Server-side Request Forgery in der Theorie

Server-side Request Forgery wird als CWE-918 im Common Weakness Enumeration Dictionary wie folgt beschrieben [3]: „The web server receives a URL or similar request from an upstream component and re­trieves the contents of this URL, but it does not suf­fi­ciently ensure that the request is being sent to the expected des­tination.“

Diese Beschreibung ist formal halbwegs richtig (es können auch andere Server als Webserver angegriffen werden), aber wenig anschaulich. Bei einem SSRF-Angriff sendet ein Angreifer einen Request an einen Server A, der diesen dazu bringt, selbst einen Request an einen anderen Server B zu senden und das Ergebnis an den Angreifer zurückzuliefern. Der Vorteil für den Angreifer: Für Server B kommt der Request von Server A. Das ist natürlich besonders nützlich, wenn Server B zwar Requests von Server A entgegennimmt, nicht aber von anderen Quellen. Aber ein Angreifer kann so auch seine Herkunft verschleiern, während er zum Beispiel nach angreifbaren Servern sucht.

Das alles lässt sich viel besser mit einem Beispiel erklären. Ein klassisches Beispiel für SSRF ist eine Webanwendung, der man zum Beispiel einen URL zum Laden eines Bilds übergeben kann und die dabei auch Portangaben auswertet. Lässt sich dann je nach Fehlermeldung auch noch feststellen, ob der Port offen oder geschlossen ist, handelt es sich um eine SSRF-Schwachstelle.

Auch das ist noch nicht wirklich anschaulich. Also nehmen wir besser ein Beispiel, das es „in the Wild“ wirklich gab. Oder zwei. Oder drei.

Beispiel 1: Eine Schwachstelle auf „marketplace.mozilla.org“

Fangen wir mit einer im Juli 2013 gemeldeten Schwachstelle auf marketplace.mozilla.org an [4]. Beim Anmelden einer App konnte ein URL für das App-Manifest angegeben werden. Der URL konnte eine Portangabe enthalten, die auch ausgewertet wurde. Wurde als URL http://scanme.nmap.org:22 angegeben (Port 22 ist ein offener Port), wurde die Fehlermeldung

Your app failed validation with 1 error. Manifests must be served with the HTTP header "Content-Type: application/x-web-app-manifest+json". See https://developer.mozilla.org/en/Apps/Manifest#Serving_manifests for more information.

zurückgeliefert. Beim URL http://scanme.nmap.org:21 mit einem geschlossenen Port gab es dagegen die Fehlermeldung: „Your app failed validation with 1 error. No manifest was found at that URL. Check the address and try again“.

Ein Angreifer kann darüber also prüfen, ob bei einem Server bestimmte Ports offen oder geschlossen sind und danach entscheiden, ob sich ein Angriff auf diesen Server lohnt oder nicht.

Beispiel 2: Eine Schwachstelle auf „add.yahoo.com“

Das zweite Beispiel ist eine im März entdeckte und im Juni nach ihrer Korrektur veröffentlichte SSRF-Schwachstelle auf add.yahoo.com [5]. Beim Vorschlagen einer Website konnte im URL ein Port angegeben werden; über die Rückmeldungen konnte dann zwischen offenen, gefilterten und geschlossenen Ports unterschieden werden.

Bei einem geschlossenen Port wurde die Fehlermeldung „The following resulted when trying to access your document: connect: Connection refused“ ausgegeben, bei einem gefilterten Port lautete die Fehlermeldung „The following resulted when trying to access your document: Request Timeout“ und bei einem offenen Port kam entweder die Erfolgsmeldung „Your Site Has Been Submitted“ oder die Fehlermeldung „Document contains no data“.

Beispiel 3: Ein Angriff auf SAP-Systeme

Sie finden Portscans über Bande langweilig? Wie wäre es denn dann mit einem richtig bösen Angriff? Code einschleusen zum Beispiel. Und das auf einen Server im Intranet, an den der Angreifer von außen gar nicht rankommt? Auch das ist mit SSRF möglich. Der Angreifer muss nur einen Server finden, dem er einen URL zum eigentlichen Angriffsziel übergeben kann und der dann samt angehängtem Exploit für eine Schwachstelle ans Angriffsziel gesendet wird.

Ein schönes Beispiel für so einen Angriff haben Alexander Bolshev und Gleb Cherbov im August 2014 auf der Black Hat USA vorgestellt. Der Titel ihres Vortrags: „ICSCorsair: How I Will PWN Your ERP Through 4-20 mA Current Loop“ [6]. Es ging darin gar nicht primär um SSRF-Schwachstellen, sondern um Angriffe auf – oder besser über – Industriesteuerungen. Genauer: Die Protokolle, über die die Sensoren und Aktoren mit ihren Steuerungen kommunizieren.

Über einen an das Kontrollnetzwerk angeschlossenen Microcontroller konnten die Forscher ein XML-Tag in die Adressfelder des verwendeten Low-Level-Protokolls einschleusen, das zum Laden eines externen XML-Schemas führte. Darüber konnte dann der Exploit für eine Remote Code Execution in einem SAP-System eingeschleust werden, den Sie in Listing 1 sehen.

Listing 1: XML-Datei mit Exploit fü...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang