Java-basierte Malware: Die Bedrohungen durch JRE-Sicherheitslücken eindämmen

Unternehmen müssen sich vor den immer wieder auftretenden Sicherheitslücken in der Java Laufzeitumgebung schützen. Lösungen gibt es einige.

Die Java-Laufzeitumgebung (Java Runtime Environment/JRE) gehört zu den am meisten installierten Softwarepaketen. Viele Unternehmen halten die JRE für unerlässlich, da sie eine Abstraktions-Schicht in Enterprise-Systemen zu Verfügung stellt. Mit ihrer Hilfe lässt sich Software mit einer Programmiersprache und einer Code-Basis schreiben, die sich dann wiederum auf vielen weiteren Betriebssystemen und Geräten ausführen lässt.

Viele Enterprise-Applikationen sind in Java geschrieben und werden mithilfe der JRE betrieben. Die Anreize hierfür liegen in der Plattform-übergreifenden Unterstützung und in der leichteren Software-Entwicklung. Die JRE ist aber auch deswegen so populär, weil viele geschäftskritische Applikationen JRE zwingend erforderlich machen. Unternehmen haben oftmals also gar keine andere Wahl, als sie zu nutzen.

Leider zielt ein großer Teil von Malware auf JRE ab, gerade weil die Software für Unternehmen so wichtig ist. JRE erfreut sich nicht nur einer großen Anwenderbasis, sondern ist auch noch wesentlich komplexer als viele andere Software-Programme. Gründe dafür sind die große Anzahl an unterstützten Geräten und die verfügbare Funktionalität. Somit ist die Angriffsfläche entsprechend groß und das wiederum ist natürlich für viele Hacker verlockend. Der Großteil der Malware zielt auf Windows- und Mac-Systeme, allerdings nimmt auch Java-basierte Malware für mobile Geräte laufend zu. Die JRE auf anderen Plattformen, wie zum Beispiel Toastern und anderen Embedded-Geräten, wurde bisher nicht von Malware heimgesucht. Die lange Geschichte von Java-Sicherheitslücken zeigt aber auch, dass keine Java-Implementierung sehr lange vor Malware verschont bleibt.

In diesem Tipp sprechen wir über die andauernden Bedrohungen, denen Unternehmen durch Java-basierte Malware ausgesetzt sind. Ebenso erörtern wir, wie sich Unternehmen schützen können.

Enterprise-Bedrohungen: Dauernder Beschuss durch JRE-Malware

JRE unter Windows und Mac war in der Vergangenheit ein ernsthaftes Sicherheitsproblem. Deswegen sollten Unternehmen eine Rechnung aufstellen: Was kostet eine komplette Deaktivierung von JRE verglichen mit einem ernsthaften durch JRE verursachten Security-Zwischenfall? Das ist natürlich einfacher gesagt als getan. Die Kosten eines JRE-Malware-Desasters oder die Deaktivierung lassen sich schlecht quantifizieren. Dennoch ist dies eine Schlüssel-Komponente der kompletten Risiko-Einschätzung. Die Kosten eines Security-Zwischenfalls können Sie mit den regelmäßig erscheinenden Studien des Ponemon Institute abwägen. Wollen Sie die Kosten berechnen, wenn Sie JRE deaktivieren und somit das Risiko minimieren oder zusätzliche Security-Kontrollen einsetzen, müssen Sie die Gesamtbetriebskosten (TCO) für diese mögliche Strategie neu kalkulieren. In diese TCO gehören sämtliche Enterprise-Applikationen, die möglicherweise auf die JRE angewiesen sind.

Woher wissen Unternehmen eigentlich, dass Sie dem Risiko ausgesetzt ist, ein potenzielles Opfer von Malware zu sein? In der Vergangenheit hat sich gezeigt, dass Unternehmen mit geschäftskritischen Applikationen, die wiederum auf JRE setzen, zur höchsten Risiko-Gruppe gehören. Zu den betroffenen Software-Paketen gehören ERP-Lösungen (Enterprise Resource Planning) sowie Software zum Customer Relationship Management (CRM).

Solange sie von ihren Anstrengungen profitieren, werden Angreifer immer neue Sicherheitslücken in JRE finden, indem sie neue Funktionalitäten und Bug-Fixes auf dem Radar haben oder die Sandbox direkt ins Visier nehmen. Das gilt vor allen Dingen für solche Schwachstellen, von denen die meisten Systeme betroffen sind. Solange Unternehmen wiederum Java-basierte Anwendungen ohne zusätzliche und angemessene Security-Maßnahmen installieren, werden sie garantiert zu den Opfern gehören.

Wie können Sich Unternehmen vor Java-basierter Malware schützen?

Ist die Deaktivierung der JRE keine Option, gibt es diverse Maßnahmen zum Schutz vor Java-basierter Malware. Zunächst einmal sollten Sie sicherstellen, dass Ihre Firma die aktuellste Version der JRE im Einsatz hat. Haben Sie an den Endpunkten noch keine Antimalware-Netzwerk-Appliance installiert, die digital unterzeichnete Applets und Whitelisting stützt, sollten Sie an dieser Stelle beginnen.

Durch die wachsende Komplexität von Java und JRE-Sicherheitslücken müssen Sie allerdings auch neue Verteidigungsmechanismen einsetzen. Andere und weniger konventionelle Optionen helfen, das Risiko für Ihre Endgeräte zu minimieren. Dazu gehören die Nutzung von JRE in einer Sandbox oder virtuellen Maschine (VM) oder das Umwandeln von Java-Applets in direkt ausführbare Dateien. Zum Beispiel könnten Sie ein Linux-Backend mit JRE-Unterstützung einsetzen, auf dem Java-Applets in virtuellen Maschinen laufen. Oder Sie könnten JRE in einer Sandbox halten, die den Zugriff auf das lokale System begrenzt und zusätzlich nach verdächtigem Verhalten Ausschau hält.

Auf der anderen Seite könnte eine komplette virtuelle Maschine einen ähnlichen Schutz bieten und die Umgebung müsste weniger restriktiv und spezialisiert sein. Dort ließen sich mehrere Applets und Applikationen verwenden, allerdings ist dafür natürlich auch ein Management der VM notwendig. Eine weitere Option wäre es, das Java-Applet in eine normal ausführbare Datei umzuwandeln. Somit müssen Sie unter Umständen die JRE nicht mehr verwenden und können das Applet ohne JRE ausführen. Behalten Sie allerdings im Hinterkopf, dass jede dieser Optionen mit ausführlichen Tests verbunden sein sollte, da Sie sich absolut sicher sein müssen, ob Ihre gewählte Lösung in Ihrer Umgebung und mit der entsprechenden Applikation auch tatsächlich funktioniert.

Beachten Sie auch, dass JRE-basierte Angriffe, die IP-Verbindungen als Befehlskontrolle verwenden, eine entscheidende Schwäche haben: Sie benötigen eine Verbindung zu einem IP-Netzwerk, das deshalb mithilfe von Security-Tools überwacht werden sollte. Das Monitoring bezüglich verdächtiger IP-Verbindungen ist eine Mammut-Aufgabe, trotzdem sollten Sie nach Anomalien hinsichtlich der Verhaltensmuster Ausschau halten. Somit identifizieren Sie wahrscheinlich die Systeme, die man im Anschluss genauer unter die Lupe nehmen sollte. Den Ausgangspunkt hierfür stellt eine Basis an bekannten gutartigen Verhaltensmustern dar. Alles, was dann aus dem Rahmen fällt, sollten Sie sich genauer ansehen. Sollten Angreifer allerdings Bluetooth- oder andere drahtlose Netzwerkverbindungen nutzen, wäre dies allerdings wesentlich schwieriger über eine Analyse des IP-Traffics zu bemerken.

Unternehmen sollten zudem mit Nachdruck darauf hinarbeiten, von Ihren Software-Anbietern Anwendungen zu erhalten, die nicht JRE nutzen. Zumindest muss es eine Version geben, die nicht von alten JRE-Ausgaben abhängig ist. Wenn Sie komplett auf eine andere geschäftskritische Applikation umstellen ist dies sicherlich mit hohen Kosten verbunden. Allerdings sollten Sie an diesem Punkt nochmals an die Studien des Ponemon Institute zurückdenken und überschlagen, wie hoch die Kosten durch einen von JRE verursachtem Security-Zwischenfall wären.

Sprechen wir über Software von Drittanbietern, sollten kommerzielle Software-Hersteller für Ihre selbst verursachten Sicherheitslücken haftbar sein. Das würde helfen, die Kosten für JRE-Sicherheitslücken im Rahmen zu halten. Im Moment sind Unternehmen dazu gezwungen, diese Kosten selbst zu tragen. Würde man die kommerziellen Anbieter in die Pflicht nehmen, hätten diese sicherlich einen Anreiz, ihre Applikationen auch in einer anderen Programmiersprache als Java anzubieten. Alternativ könnte das ausdrücklich bedeuten, dass JRE-Applikationen des Anbieters in einer Umgebung lauffähig sind, in der andere, bereits bestehende Antimalware-Tools ebenfalls eingesetzt werden.

Fazit: Java-basierte Sicherheitslücken sind unvermeidlich – also bereiten Sie sich darauf vor

Die JRE steht durch die lange Geschichte an Sicherheitslücken immer wieder massiv in der Kritik. Allerdings sollte man sich bewusst machen, dass die JRE nicht alleine an den Security-Zwischenfällen Schuld hat. Lässt sich die Unternehmenssicherheit durch so eine Sicherheitslücke erheblich kompromittieren, sollte man eine neue Bewertung des Informations-Security-Programms durchführen. Sie sollten also nachsehen, ob die definierten Prozesse, mit denen sich die Risiken minimieren lassen, auch tatsächlich ausreichen.

Wenn JRE für Unternehmen ein so wichtiger Bestandteil ist, dass er nicht einfach eliminiert werden kann, dann sollten Sie trotzdem abwägen, ob das Risiko eines durch JRE verursachten Security-Zwischenfalls nicht doch schwerer wiegt.

Die Programmiersprache und der Anwendungsserver selbst sind nicht das Problem. Es geht vielmehr um um die JRE auf Windows- und Mac-Rechnern, auf denen ein Cyberkrimineller bösartigen Code auf dem Endgerät ausführen kann. Für die JRE gibt es zwar auch häufig Updates, was zweifellos die Sicherheit erhöht, auf der anderen Seite aber das Testen und Ausrollen erschwert. Sind Firmen nicht dazu bereit, die Umgebung mit kritischem Auge zu betrachten und zu identifizieren, an welchen Stellen man die Security-Kontrollen verbessern muss, dann setzen sie sich damit einem erhöhten Risiko durch Java-basierter Malware aus.

Über den Autor:

Nick Lewis, CISSP, ist Sicherheitsbeauftragter der Saint Louis University. Nick hat seinen Master of Science in Informationssicherung von der Norwich University im Jahre 2005 und in Telekommunikation von der Michigan State University im Jahre 2002 erhalten. Bevor er bei der Saint Louis University im Jahre 2011 anfing, arbeitete Nick an der University of Michigan und im Boston Children's Hospital. Weiterhin war er für Internet2 und die Michigan State University tätig.

Folgen Sie SearchSecurity.de auch auf Facebook, Twitter und Google+!

Erfahren Sie mehr über Bedrohungen

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close