Project Zero: Fireeye-Appliances lassen sich mittels Java-Datei übernehmen

Eine schwerwiegende Sicherheitslücke in Fireeye-Geräten haben Mitglieder von Googles Project Zero aufgedeckt. Ein Parser für Java-Dateien führt Code aus, um Obfuscation-Techniken zu umgehen.

Artikel veröffentlicht am 16. Dezember 2015, 13:54 Uhr, Hanno Böck

Sind Appliances von Fireeye ein Sicherheitsrisiko? Die Scan-Architektur scheint einige Mängel zu haben. (Bild: Fireeye)

Erneut ist eine schwerwiegende Sicherheitslücke in Geräten der Firma Fireeye entdeckt worden. Natalie Silvanovich und Tavis Ormandy von Googles Project Zero beschreiben in einem Blogeintrag, wie sie mittels einer manipulierten Java-JAR-Datei die volle Kontrolle über eine Fireeye-Appliance erlangt haben. Die konkrete Sicherheitslücke wurde von Fireeye gefixt, doch die grundsätzliche Architektur der Fireeye-Malware-Scans scheint alles andere als sicher zu sein.

Fireeye-Geräte werden als Firewalls vor allem in großen Firmennetzwerken eingesetzt. Alle Daten, die zwischen dem Internet und dem lokalen Intranet ausgetauscht werden, werden durch die Fireeye-Geräte untersucht. Dateien, die via E-Mail oder über Webseiten übertragen werden, untersucht das Fireeye-Gerät mit verschiedenen Methoden. Eine Sicherheitslücke in diesen Scans lässt sich durch einen Angreifer sehr einfach ausnutzen. Er muss nur eine E-Mail mit einem Dateianhang an das jeweilige Opfer versenden. Gelingt es, die Kontrolle über die Geräte zu übernehmen, hat ein Angreifer Zugriff auf den gesamten externen Datenverkehr eines Unternehmens. Passwörter, aufgerufene Webseiten oder E-Mails - alles lässt sich anschließend mitlesen und auch manipulieren.

Zahlreiche Tools zur Dateianalyse

Übertragene Dateien werden in den Fireeye-Geräten von einer Komponente namens Malware Input Processor (MIP) analysiert. Dieser ruft je nach Dateityp verschiedene weitere Tools zur Analyse der Dateien auf. Die Google-Forscher erwähnen, dass für Apple-DMG-Dateien 7-Zip genutzt wird, PNG-Dateien werden mittels des zu Libpng gehörenden Tools pngcheck analysiert und Flash-Dateien mit einem Programm namens flasm dekompiliert.

Ein besonderes Augenmerk warfen die Google-Forscher jedoch auf die Analyse von Java-Dateien mit der Endung jar. Zunächst wird deren Signatur mit einem Tool namens jarsigner geprüft, anschließend werden die Dateien mittels eines Programms namens Jode weiter analysiert. Jode ist ein Java-Decompiler, die letzte Version wurde 2004 veröffentlicht. Der Quellcode ist unter der LGPL-Lizenz verfügbar.

Java-Decompiler führt Obfuscated-Code aus

Ormandy stellte fest, dass sich im Code von Jode eine Funktion befindet, die bestimmte Codeteile in den analysierten Java-Dateien mittels einer Java-VM ausführte. Der Grund dafür ist, dass Jode versucht, sogenannten Obfuscated-Code zu decodieren, also Codeteile, die absichtlich so geschrieben wurden, dass sie schlecht lesbar sind.

Es gelang den Google-Forschern nach einigem Experimentieren, selbst Code zu erzeugen, der von Jode in der Java-VM ausgeführt wurde. Dafür nutzten sie ein Programm namens Jasmin, ein Assembler für Java-Bytecode. Somit waren sie in der Lage, Java-Code innerhalb des Malware Input Processors auszuführen. Da sich auf den Maschinen eine Installation des Tools netcat befand, war es trivial, damit eine Remote-Shell zu öffnen. Den Jasmin-Code haben die Google-Forscher veröffentlicht.

Die Remote-Shell läuft mit den Rechten der Malware-Input-Processor-Komponente, damit ist ein Angreifer bereits in der Lage, einen Großteil des übertragenen Datenverkehrs zu analysieren. Doch Silvanovich und Ormandy gelang es auch, Root-Rechte auf den Fireeye-Geräten zu erlangen. Die Details dazu haben sie jedoch im Moment noch nicht bekanntgegeben. Fireeye hatte demnach darum gebeten, für die Lösung dieses Problems noch einige Zeit zu bekommen.

Die konkrete Sicherheitslücke beim Parsen der Java-Dateien wurde nun von Fireeye behoben. Laut Project Zero sind alle Geräte der NX-, FX-, AX-, und EX-Serie von Fireeye betroffen, die Version 427.334 der Fireeye-Firmware behebt das Problem. Fireeye selbst hat ebenfalls ein Security-Advisory herausgegeben.

Scan-Konzept generell sehr riskant

Doch auch wenn die aktuelle Sicherheitslücke kein Risiko mehr darstellt: Die Architektur der Fireeye-Geräte scheint insgesamt sehr riskant. Unterschiedliche Dateien werden mit zahlreichen Parsern analysiert, die oft selbst vermutlich nicht besonders sicher sind. Von den im Google-Blogeintrag erwähnten scheint insbesondere flasm ein Risiko zu sein. In einem Test fand der Autor dieses Artikels mittels Fuzzing innerhalb von Minuten zahlreiche Probleme, darunter unter anderem Stack Overflows.

Auf Twitter empörte sich der IT-Sicherheitsforscher Thomas Dulien, der auch unter dem Nickname Halvar Flake bekannt ist, über die Fireeye-Architektur und legt nahe, dass ein verantwortungsvoller IT-Sicherheitschef in einem Unternehmen die Fireeye-Geräte zur Zeit besser abschalten sollte.

Im September hatte bereits Felix Wilhelm von der Heidelberger Firma ERNW Sicherheitslücken im Malware Input Processor der Fireeye-Appliances aufgedeckt. Bemerkenswert sind die unterschiedlichen Reaktionen von Fireeye auf beide Vorfälle.

Einstweilige Verfügung gegen ERNW, schnelle Reaktion gegenüber Google

Laut Googles Project Zero hatte Fireeye auf die Berichte innerhalb sehr kurzer Zeit reagiert, bereits nach zwei Tagen stand ein Fix bereit. Im Fall von ERNW vergingen mehrere Wochen, bis Fireeye überhaupt auf die Meldung reagierte. In einem Gespräch mit Golem.de im September hatte Fireeye-CEO David DeWalt gesagt, dass Fireeye mit der Veröffentlichung von ERNW vor allem deswegen ein Problem hatte, weil Fireeye mehr Zeit benötigt hätte, um die Lücken zu beheben. Jedoch lagen zwischen der Meldung der Sicherheitslücke von ERNW an Fireeye und der geplanten öffentlichen Präsentation mehrere Monate.

Einen Teil der geplanten Veröffentlichung von ERNW hatte Fireeye mittels einer einstweiligen Verfügung verhindert. Dabei ging es nicht um die Lücke selbst, sondern um Erklärungen zur Architektur der Fireeye-Geräte.