Menü
Alert!

Zero-Day-Alarm für viele Server mit Java

Gefährliche Zero-Day-Exploits für WebLogic, WebSphere, JBoss, Jenkins und OpenNMS demonstrieren nachdrücklich, dass auch Java-Anwendungen auf dem Server nicht automatisch sicher sind. Konkreter Auslöser ist die verbreitete Bibliothek Common Collections.

Lesezeit: 2 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 177 Beiträge
Update
Von

Die veröffentlichten Zero-Day-Exploits für WebLogic, WebSphere, JBoss, Jenkins und OpenNMS sind nur Beispiele, mit denen Stephen Breen Aufmerksamkeit auf ein lange unterschätztes Problem von Java-Anwendungen auf dem Server lenken will. Er demonstriert das mit einer akuten Sicherheitslücke in der weit verbreiteten Java-Bibliothek Common Collections. Das schlimmste daran: Obwohl die Lücke seit neun Monaten bekannt ist, gibt es immer noch keinen richtigen Fix.

Auf verwundbaren Servern können Angreifer direkt eigenen Code einschleusen und ausführen; eine vorherige Authentifizierung ist dafür nicht erforderlich. Die Zahl der anfälligen Server-Anwendungen ist derzeit nicht abzuschätzen. Common Collections kommt bei sehr vielen Java-Applikationen zum Einsatz; die aufgeführten Flaggschiffe sind lediglich Beispiele. Mit den bereitgestellten Tools und der Dokumentation lassen sich auch für andere Java-Applikationen recht einfach scharfe Exploits basteln.

Java im Browser hat seinen Ruf als immanentes Sicherheitsproblem bereits weg und ist dort auch quasi bedeutungslos. Für Server-Anwendungen genießt die objektorientierte Programmiersprache nach wie vor einen guten Ruf – unter anderem weil ihr Einsatz die verbreiteten Pufferüberläufe verhindert. Doch bereits vor neun Monaten wiesen Gabriel Lawrence und Chris Frohoff mit ihrem Vortrag Marshalling Pickles auf eine andere große Baustelle hin, die man sich beim Einsatz von Java einhandelt: die Serialisierung.

Für die Kommunikation mit Java-Anwendungen werden Objekte in eine lineare Folge von Bytes umgewandelt, die sich abspeichern und übertragen lässt. Der Empfänger liest diese Byte-Folge ein und macht daraus wieder aktive Objekte. Obwohl diese angelieferten Objekte aus dem Netz stammen und Code enthalten können, prüfen die Java-Server-Applikationen oft gar nicht oder nur sehr flüchtig, ob sie tatsächlich vertrauenswürdig sind. Sprich: Ein Angreifer, der einer Java-Server-Applikation ein passendes Objekt senden kann, hat gute Chancen, damit Unheil anzurichten und im Extremfall sogar eigenen Code im Kontext des Servers zu aktivieren.

Konkret wiesen die Forscher dieses Problem mit fatalen Konsequenzen in der Funktion InvokerTransformer der beliebten Java-Bibliothek Common Collections nach. Für die gibt es noch keine aktualisierte Version, die die Lücke stopft. Doch schlimmer noch: Selbst wenn es die gäbe, wird es sehr lange dauern, bis das Problem aus der Welt geschafft ist. Denn es ist keineswegs mit einem einfachen Update-Befehl getan; Java-Applikationen wie WebLogic, Jenkins und Co bringen in der Regel ihre eigenen Bibliotheken mit und die müssen alle irgendwie aktualisiert werden.

Admins, die Server mit Java-Anwendungen betreiben, müssen somit sich auf einiges an Arbeit einrichten. Denn obwohl das Problem bereits seit neun Monaten bekannt ist, gibt es immer noch keinen richtigen Fix. Tests der eigenen Installationen und eine zumindest provisorische Absicherung des Server sind somit weitgehend Handarbeit.

Einen ersten Überblick kann sich ein verunsicherter Admin mit einem Befehl wie

# grep -Rl InvokerTransformer .
./webapps/ROOT/WEB-INF/lib/commons-collections-3.2.1.jar

verschaffen. Das sollte alle jar- oder class-Dateien auflisten, die die anfällige Funktion enthalten. Wer dabei fündig wird, sollte möglichst dafür sorgen, dass die zugehörigen Dienste zumindest nicht mehr aus dem Internet zu erreichen sind. Als recht kruden Schutz empfiehlt Breen in seiner ausführlichen Zusammenfassung des Serialisierungs-Problems, die anfällige Funktion aus dem Java-Archiv zu entfernen. Da es sich dabei nur um ZIP-Dateien handelt, kann man mit einem Zip-Utility darin einfach die Datei org/apache/commons/collections/functors/InvokerTransformer.class löschen. Nur wenige Applikationen nutzen diese Funktion direkt, sodass die Chancen gut stehen, dass dabei nichts kaputt geht. Trotzdem sollte man das natürlich ausgiebig testen, bevor man es auf einem Produktionssystem macht.

Update 10.11.2015, 18:00: Red Hat stellt zusätzliche Informationen bereit, ob Red-Hat-JBoss-Produkte von dem Serialisierungs-Problem betroffen sind. Demzufolge ist insbesondere die JBoss Enterprise Application Platform ab Version 5 nicht akut betroffen, da dort eine Authentifizierung vorgeschaltet ist. Das Jenkins-Team beschreibt einen Workaround, wie man das Problem temporär entschärfen kann.


Update 11.11.2015, 14:15 Uhr: Mittlerweile hat Oracle einen Patch für WebLogic angekündigt. (ju)