Kleines, böses JPEG: Microsoft-Server mit manipulierten EXIF-Daten kapern

Inhaltsverzeichnis

Marcus Murray von Truesec hat auf der RSA-Sicherheitskonferenz gezeigt, wie man mit einem simplen JPEG unautorisierten Zugriff auf einen Microsoft-Webserver erlangen kann. Über den Webserver als Einfallstor gelang es ihm eigenen Angaben zufolge einen SQL-Server und zuletzt sogar den Domänencontroller zu kapern. Mit dem Zugriff auf den Domänencontroller hat man in typischen IT-Landschaften de facto die Kontrolle über alle Rechner eines Unternehmens.

Die von Murray vorgestellte Methode per JPEG Schadcode in den Webserver zu schleusen ist zwar kreativ, technisch aber alles andere als kompliziert. Für den Upload der Datei zum Webserver nutzte er ein öffentlich zugängliches Uploadformular. Derartige Funktionen bieten viele Web-Apps, beispielsweise damit Benutzer Bilder für ihre Benutzerprofile hochladen können. Der Webserver prüft dabei, ob wirklich JPEGs hochgeladen werden. Diesen Sicherheitscheck hat Murray mit der Kombination verschiedener Tricks ausgehebelt.

Schritt 1: JPEG umbenennen

Für den Angriff benutzte er ein gewöhnliches JPEG-Bild. Es handelte sich um eine kleine Bilddatei, ein Foto an dem er allerdings einige Modifikationen vorgenommen hatte. Die erste Änderung betraf den Dateinamen. An die vorhandene Endung ".jpg" hängte er zusätzlich noch das Kürzel ".aspx" an. ASPX-Dateien sind ausführbare Dateien die bei Microsoft-Webservern eingesetzt werden. Die so veränderte Bilddatei wurde beim Upload anstandslos und zutreffend als JPEG erkannt.

Schritt 2: Schadcode per EXIF einfügen

Im nächsten Schritt hat Murray daher in das Kommentarfeld der EXIF-Dateien ein Skript eingefügt. In diesem Fall war es Schadcode, welcher auf dem betroffenen System den Zugriff auf die Shell ermöglicht. In seiner Vorlagendatei musste er das Kommentarfeld mit dem ExifTool dafür erst noch anlegen. Manche Kameras legen das Kommentarfeld direkt bei der Aufnahme an. In jedem Fall handelt es sich um eine recht simple Operation, um den Schadcode in die Bilddatei einzuschleusen.

Schritt 3: Schadcode über die Vorschau ausführen

Nach dem erneuten Upload des umbenannten und manipulierten JPEGs reichte dann ein Klick auf die Vorschaufunktion, um den Schadcode auszuführen. Aufgrund der geänderten Dateiendung hält der Server das JPEG nämlich für eine ausführbare Datei. Statt den Bildinhalt anzuzeigen, führt er bei der Vorschau den im EXIF-Feld eingebetteten Schadcode aus. Über dieses Skript erlangt der Angreifer dann Zugriff auf die Kommandozeile des Webservers. Sie wird dann statt der Bilddatei im Browser angezeigt. Dieser unautorisierte Zugrifff ermöglicht weitgehende Manipulationen am betroffenen Server.

Schritt 4: Weitere Server angreifen

Murray hat den gehackten Server dann als Einfallstor genutzt, um sich in dem angegriffenen Unternehmens-Netzwerk nach und nach Zugriff auf weitere Rechner zu verschaffen. Ob und in welchen Ausmaß das möglich ist, hängt natürlich von der Konfiguration dieser Server und dem gesamten Aufbau der Serverlandschaft ab. In dem von Murray beschriebenen Fall war es zuletzt sogar möglich, den Domänencontroller zu kontrollieren. Ein kleines JPEG reichte also aus, um ein Worst-Case-Szenario auszulösen.

Fazit: Schuld ist nicht das JPEG

Das eigentliche Sicherheitsproblem liegt nicht im JPEG, denn ein JPEG ist laut Spezifikation eine nicht ausführbare Datei. Die Sicherheitslücke liegt vielmehr auf der Ebene der Anwendungen auf dem Server. Der hier angegriffene MS-Webserver (IIS-Server) erkennt zwar einerseits das JPEG korrekt als Bilddatei. Andererseits versucht er aufgrund der geänderten Dateiendung, die Datei auszuführen obwohl sie nur angezeigt werden sollte. Erst durch diese fehlerhafte Behandlung durch den MS-Webserver wird der Schadcode aktiv. Im vorliegenden Fall war der attackierte Webserver ein Windows Server 2012 R2. Ob andere Versionen des Windows-Webservers davon ebenfalls betroffen sind, ist derzeit noch unklar.

[Update: 24.04.2015: In der ursprünglichen Version dieser Meldung hieß es ". Apache Webserver [...] dürften aufgrund ihrer Architektur nicht von dem Problem betroffen sein." Richtig ist: Apache Webserver, die einen deutlich höheren Marktanteil haben als die entsprechenden IIS-Server von Microsoft, laufen im Regelfall auf dem Linux-Betriebssystem. Anders als beim Windows-Betriebssystem hängt das Dateihandling unter Linux in der Regel nicht von der Dateiendung ab. Man kann in der Konfiguration aber auch Apache-Webserver anweisen, bestimmte Dateiendungen wie Skripte zu behandeln. Ähnliche Attacken, wie die von Murray beschriebene, sind also auch auf Apache Servern durchaus möglich. Bitte vergleichen Sie hierzu auch die Diskussion im Forum.]

Im Video zeigt Murray detailliert, wie er vorgegangen ist.

(sts)