JPEG-Attacke Forscher kapert Microsoft-Server mit Bilddatei

Manche Windows-Webserver scheinen hochgeladene Bilder nur oberflächlich zu überprüfen. Das erlaubt Angreifern, mit manipulierten Bilddateien in das System einzudringen.

Microsoft-Logo: Sicherheitslücke in Windows Server 2012 R2 entdeckt
AP/dpa

Microsoft-Logo: Sicherheitslücke in Windows Server 2012 R2 entdeckt


Auf der RSA-Sicherheitskonferenz im kalifornischen San Francisco hat ein Sicherheitsforscher vor Attacken auf Windows-Server gewarnt. Hacker könnten mithilfe einer JPEG-Bilddatei Zugang zu SQL-Servern und Domänen-Controllern erlangen.

Den dafür nötigen Schadcode fügte Marcus Murray vom IT-Beratungsunternehmen Truesec in das Kommentarfeld der EXIF-Dateien des Bildes ein. EXIF-Dateien speichern üblicherweise Informationen zu Größe, Auflösung oder Entstehungsdatum des Motivs, sogenannte Metadaten.

An die Dateiendung .jpeg hängte Murray die Endung .aspx an. Sie steht sonst für Dateien, die von Microsoft-Webservern ausgeführt werden. Die manipulierte Datei wurde vom Testserver trotzdem als Bilddatei erkannt und für den Upload akzeptiert.

Nach dem Hochladen des Bilds musste Murray nur noch die Vorschaufunktion verwenden: Anstelle der Bildanzeige wurde nun das im EXIF-Kommentarfeld verborgene Skript ausgeführt. Murray ermöglichte das den Zugriff auf zusätzliche Informationen über den Server.

Ein Server als Sprungbrett

Im beschriebenen Fall diente der eroberte Server als Sprungbrett, um sich Zugang zu weiteren Rechnern im Netzwerk zu verschaffen. In der zugänglich gemachten Server-Datenbank konnte Murray auf die IP-Adresse des DNS-Servers zugreifen, der im beschriebenen Fall gleichzeitig als Domänen-Controller diente.

Das Problem liegt nicht beim Dateiformat JPEG als solches, lautet die Einschätzung des Fachportals "Heise". Derartige Dateien seien ja prinzipiell nicht ausführbar. Die Gefahr rühre vielmehr von der mangelhaften Kontrollroutine des Microsoft-Webservers, der das JPEG zwar korrekt als Bild erkennt. Gleichzeitig sorge die zusätzlich angefügte Endung dafür, dass der Server die Datei auch auszuführen versuche - mit allen verborgenen Inhalten.

"Heise" betont, dass es sich bei dem von Murray angegriffenen Beispielserver um einen Windows Server 2012 R2 handelt. Diese Version sei deutlich seltener anzutreffen als etwa Apache-Webserver. Letztere besäßen eine ganz andere Architektur und seien von der Sicherheitslücke nicht betroffen.

meu



insgesamt 40 Beiträge
Alle Kommentare öffnen
Seite 1
cyberdrop 23.04.2015
1.
In den Kommentaren bei Heise steht das das gleiche Problem auch bei anderen Servern besteht und zwar wenn man die genauso falsch konfiguriert wie den Windows-Server. Kein System ist vor schlechten Admins/Webentwicklern geschützt!
RuebenNase 23.04.2015
2.
Zitat von cyberdropIn den Kommentaren bei Heise steht das das gleiche Problem auch bei anderen Servern besteht und zwar wenn man die genauso falsch konfiguriert wie den Windows-Server. Kein System ist vor schlechten Admins/Webentwicklern geschützt!
In den Kommentaren im Heise-Forums wird leider vieles behauptet, wenn der Tag lang ist. Darin unterscheidet sich das Heise-Forum jedenfalls nur sehr wenig von den Kommentaren auf etlichen anderen Webseiten. ;-) Tatsache ist jedenfalls, daß das eigentliche Problem der altbekannte, grundsätzliche Konstruktionsfehler von MS Windows ist, nämlich Dateien anhand der Endungen des Dateinamens als ausführbare Dateien zu behandeln. Ob dieses Problem nun vom IIS getriggert wird oder einem anderen Windows-Webserver, ist dabei nebensächlich. Alle anderen verbreiteten Betriebssysteme erkennen die Ausführbarkeit einer Datei nicht anhand ihres Namens, sondern anhand ihrer Metainformationen, bei UNIXoiden Systemen beispielsweise an den Execute-Bits. Es ist für Angreifer deutlich schwieriger, diese Metainformationen zu manipulieren, als den Dateinamen; in vielen Szenarien ist dies sogar unmöglich. Wenn Microsoft solche Angriffe gegen seine Produkte und Kunden nachhaltig stoppen will, müßte es diesen integralen Teil der Ausführungsmethoik seiner Systeme ändern. Da dies einen hohen Aufwand, einen Bruch der so (zu?) hoch geschätzten Abwärtskompatibilität und zweifellos auch einen erkennbaren Gesichtsverlust mit sich brächte, ist wohl davon auszugehen, daß das nur dann geschieht, wenn Microsoft-Produkte und -Kunden scharenweise in den Brunnen gefallen sein werden.
cyberdrop 23.04.2015
3.
Zitat von RuebenNaseIn den Kommentaren im Heise-Forums wird leider vieles behauptet, wenn der Tag lang ist. Darin unterscheidet sich das Heise-Forum jedenfalls nur sehr wenig von den Kommentaren auf etlichen anderen Webseiten. ;-) Tatsache ist jedenfalls, daß das eigentliche Problem der altbekannte, grundsätzliche Konstruktionsfehler von MS Windows ist, nämlich Dateien anhand der Endungen des Dateinamens als ausführbare Dateien zu behandeln. Ob dieses Problem nun vom IIS getriggert wird oder einem anderen Windows-Webserver, ist dabei nebensächlich. Alle anderen verbreiteten Betriebssysteme erkennen die Ausführbarkeit einer Datei nicht anhand ihres Namens, sondern anhand ihrer Metainformationen, bei UNIXoiden Systemen beispielsweise an den Execute-Bits. Es ist für Angreifer deutlich schwieriger, diese Metainformationen zu manipulieren, als den Dateinamen; in vielen Szenarien ist dies sogar unmöglich. Wenn Microsoft solche Angriffe gegen seine Produkte und Kunden nachhaltig stoppen will, müßte es diesen integralen Teil der Ausführungsmethoik seiner Systeme ändern. Da dies einen hohen Aufwand, einen Bruch der so (zu?) hoch geschätzten Abwärtskompatibilität und zweifellos auch einen erkennbaren Gesichtsverlust mit sich brächte, ist wohl davon auszugehen, daß das nur dann geschieht, wenn Microsoft-Produkte und -Kunden scharenweise in den Brunnen gefallen sein werden.
Das Execute-Bit funktioniert auch bei PHP Dateien? Das wäre mir neu. Bei jedem Wald und Wiesen Provider werden PHP Dateien automatisch in allen Verzeichnissen ausgeführt. Bei Windows Servern gilt das für ASPX Dateien nur wenn man den entsprechenden Handler für das Stammverzeichnis festlegt und dann vergisst ihn im Unterverzeichnis wieder zu entfernen. Und damit ein solches Script dann auch noch Zugriff auf einen Domänen-Controller haben soll muss man den Server auch noch in dem falschen Benutzerkontext laufen lassen, was in der Default Einstellung schon mal nicht der Fall ist.
AundZwanzig 23.04.2015
4. Das von Ihnen genannte Problem kombiniert mit...
Zitat von RuebenNaseIn den Kommentaren im Heise-Forums wird leider vieles behauptet, wenn der Tag lang ist. Darin unterscheidet sich das Heise-Forum jedenfalls nur sehr wenig von den Kommentaren auf etlichen anderen Webseiten. ;-) Tatsache ist jedenfalls, daß das eigentliche Problem der altbekannte, grundsätzliche Konstruktionsfehler von MS Windows ist, nämlich Dateien anhand der Endungen des Dateinamens als ausführbare Dateien zu behandeln. Ob dieses Problem nun vom IIS getriggert wird oder einem anderen Windows-Webserver, ist dabei nebensächlich. Alle anderen verbreiteten Betriebssysteme erkennen die Ausführbarkeit einer Datei nicht anhand ihres Namens, sondern anhand ihrer Metainformationen, bei UNIXoiden Systemen beispielsweise an den Execute-Bits. Es ist für Angreifer deutlich schwieriger, diese Metainformationen zu manipulieren, als den Dateinamen; in vielen Szenarien ist dies sogar unmöglich. Wenn Microsoft solche Angriffe gegen seine Produkte und Kunden nachhaltig stoppen will, müßte es diesen integralen Teil der Ausführungsmethoik seiner Systeme ändern. Da dies einen hohen Aufwand, einen Bruch der so (zu?) hoch geschätzten Abwärtskompatibilität und zweifellos auch einen erkennbaren Gesichtsverlust mit sich brächte, ist wohl davon auszugehen, daß das nur dann geschieht, wenn Microsoft-Produkte und -Kunden scharenweise in den Brunnen gefallen sein werden.
...der Standardeinstellung bei Endbenutzerversionen von Windows-Systemen, dass nämlich bekannte Dateiendungen ausgeblendet werden, dürfte wohl die gefährlichste Schwachstelle dieser Produkte sein. Die überwiegende Mehrzahl der Windows-Endbenutzer hat - meiner Erfahrung nach jedenfalls - kaum IT-Background, so dass diese grosse Masse überhaupt nicht bemerkt, welcher Gefahr sie ausgesetzt wird. Offensichtlich will Microsoft es den technisch nicht versierten Nutzern ersparen sich mit den (kryptischen) Erweiterungen auseinanderzusetzen, ansonsten wäre die Standardeinstellung der andere Fall, nämlich das Anzeigen der Erweiterungen.
coldplayer1983 23.04.2015
5.
Zitat von RuebenNaseIn den Kommentaren im Heise-Forums wird leider vieles behauptet, wenn der Tag lang ist. Darin unterscheidet sich das Heise-Forum jedenfalls nur sehr wenig von den Kommentaren auf etlichen anderen Webseiten. ;-) Tatsache ist jedenfalls, daß das eigentliche Problem der altbekannte, grundsätzliche Konstruktionsfehler von MS Windows ist, nämlich Dateien anhand der Endungen des Dateinamens als ausführbare Dateien zu behandeln. Ob dieses Problem nun vom IIS getriggert wird oder einem anderen Windows-Webserver, ist dabei nebensächlich. Alle anderen verbreiteten Betriebssysteme erkennen die Ausführbarkeit einer Datei nicht anhand ihres Namens, sondern anhand ihrer Metainformationen, bei UNIXoiden Systemen beispielsweise an den Execute-Bits. Es ist für Angreifer deutlich schwieriger, diese Metainformationen zu manipulieren, als den Dateinamen; in vielen Szenarien ist dies sogar unmöglich. Wenn Microsoft solche Angriffe gegen seine Produkte und Kunden nachhaltig stoppen will, müßte es diesen integralen Teil der Ausführungsmethoik seiner Systeme ändern. Da dies einen hohen Aufwand, einen Bruch der so (zu?) hoch geschätzten Abwärtskompatibilität und zweifellos auch einen erkennbaren Gesichtsverlust mit sich brächte, ist wohl davon auszugehen, daß das nur dann geschieht, wenn Microsoft-Produkte und -Kunden scharenweise in den Brunnen gefallen sein werden.
Lustigerweise beweisen Sie gerade mit Ihrem Kommentar, dass es nicht nur im Heise-Forum Leute gibt, die das Problem nicht verstanden haben und dann in alte Dogmen verfallen. Wenn Sie sich etwas mit dem Problem beschäftigt hätten, wäre Ihnen aufgefallen, dass es hier eben nicht um ausführbare Dateien (.EXE unter Windows) geht, sondern um .ASPX-Dateien, die genauso wie etwa auch .PHP-Dateien interpretiert bzw. (bei .NET meist) kompiliert werden, also ist Ihr Argument mit dem Execute-Bit leider völlig falsch, wie das auch im Heise-Forum bereits dargelegt wurde. Das Problem geht stattdessen auf einen üblen *Web-Entwickler*-Fehler (und auch Administratoren-Fehler) zurück, der jedem einigermaßen talentierten Web-Entwickler niemals passieren darf und in jedem brauchbaren Schriftstück über die korrekte Implementierung von File-Uploads in Web-Anwendungen beschrieben wird. Upgeloadete Dateien dürfen niemals in einem direkt über HTTP erreichbaren Verzeichnis abgespeichert werden, in dem dann auch noch die Ausführung von ASPX-Dateien aktiviert ist. Darüber hinaus müssen Eingaben vom Client (und nichts anderes ist ein File-Upload) immer in jeder Hinsicht überprüft werden (z.B. auch Prüfung der Dateiendung). Als PHP-Entwickler unter Linux lässt sich der gleiche Käse mit den gleichen Mitteln anrichten wie bei Heise detailliert ausgeführt. Fazit: Microsoft kann nichts für unfähige Entwickler oder Basher ohne ausreichenden Sachverstand.
Alle Kommentare öffnen
Seite 1

© SPIEGEL ONLINE 2015
Alle Rechte vorbehalten
Vervielfältigung nur mit Genehmigung


TOP
Die Homepage wurde aktualisiert. Jetzt aufrufen.
Hinweis nicht mehr anzeigen.