© DrHitch/Shutterstock.com
Websecurity

1 SSRF - was ist das, was kann das, und ist das etwa gefährlich?


Das Thema dieses Kapitels sind eine Schwachstelle und ein Angriff, die oft nicht weiter beachtet werden. 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 im folgenden Kapitel 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 retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.“

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.1 sehen.

<?xml version="1.0" encoding="ISO-8859-1"?> 
<Schema name="Device"
xmlns="urn:schemas-microsoft-com:xml-data"
xmlns:dt="urn:schemas-microsoft-com:datatypes"
xmlns:xi="http://www.w3.org/2001/XInclude">
<AttributeType name="name"
dt:type="string"
xmlns:xi="http://www.w3.org/2001/XInclude">
<include xmlns="x-schema:http://[SAP-Server]:50100/ctc/servlet/ConfigServlet?param=com.sap.ctc.util.FileSystemConfig;EXECUTE_CMD;CMDLINE=calc"/>
</AttributeType>
</Schema>

Listing 1.1: XML-Datei mit Exploit für SAP

Alles, was der Angreifer dafür noch wissen muss, ist der Domainname oder die IP-Adresse des SAP-Servers. Diese kann er mit einem Portscan im lokalen Netz ermitteln, den er über SSRF von außen durchführen kann. Damit schließt sich der Kreis zum „harmlosen“ Beispiel 1 und 2.

Da über das Low-Level-Protokoll der Industriesteuerungen auch XSS-Angriffe auf die webbasierten Steuerungen möglich sind, könnte auch ein JavaScript-basierter Portscanner verwendet werden. Aber das ist hier nicht weiter relevant.

SSRF auf den Sicherheitskonferenzen

Wenn SSRF sogar quasi „nebenbei“ auf den Sicherheitskonferenzen verwendet wird, wäre es doch sehr verwunderlich, wenn es nicht auch ganze Vorträge zu diesem Thema gäbe. Und die gibt es in der Tat; tatsächlich wurde SSRF sogar erstmals auf einer Sicherheitskonferenz beschrieben: Im Februar 2008 auf der ShmooCon 2008.

Wie alles begann …

Der Vortrag von Deral Heiland hatte den Titel „Web Portals: Gateway To Information, Or A Hole In Our Perimeter Defenses“ und beschrieb einen beim Test eines Webportals gefundenen neuen Angriff [7]. Der Server mit dem Webportal stand hinter einer Firewall und war mit mehreren Servern im lokalen Netz vernetzt. Beim Test einer XSS-Schwachstelle stellte Deral Heiland fest, dass er darüber HTTP-Requests an andere Server auslösen konnte. Aufgrund der Art der Schwachstelle konnte er über HTTP-URI beliebige Dokumente abfragen, die dann als Rohdaten dargestellt wurden.

Aus dieser ersten Entdeckung entwickelte sich dann unter anderem die anfangs beschriebene Möglichkeit, nach offenen Ports zu suchen oder andere Schwachstellen auszunutzen. Das ist schon schlimm genug, aber sie wissen ja: Schlimmer geht immer. Auf der Black Hat USA 2012 wurden deutlich gefährlichere Angriffe vorgestellt.

Von außen durch die Firewall ins Unternehmensherz

Der Vortrag von Alexander Polyakov und Dmitry Chastuhin hatte den sehr passenden Titel „SSRF vs. Business Critical Applications“ [8]. In der Theorie befinden sich alle kritischen Systeme ja bekanntlich geschützt von einer Firewall und einem IDS/IPS in einem sicheren Subnetz und werden regelmäßig gepatcht. In der Praxis sieht das meist anders aus, aber selbst im Idealfall wären Angriffe über SSRF möglich. SSRF wird von den beiden Forschern so beschrieben:

  • Der Angreifer sendet ein Pake...

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