Der erste Oracle Java 0day Exploit des Jahres wurde am 10. Januar entdeckt. Die Aufregung war sogleich gross in den verschiedenen Behörden rund um den Globus. Nachdem die US Homeland Security und das deutsche BSI die Warnung vor dem Exploit veröffentlich hatten, haben sofort verschiedene Technik-Webseiten und sogar teilweise die Online-Massenmedien Warnungen auf ihren Titelseiten veröffentlicht. Man solle Java 7 sofort deaktivieren lautete der einheitliche Tenor. Nachdem sich der Trubel nun ein wenig gelegt hat, möchte ich die Sache nüchtern betrachten was eigentlich vorgefallen ist und wie man sich in Zukunft vor solchen Schwachstellen schützen kann.

Kurze Übersicht über Java

Die seit 1995 existierende Programmiersprache Java zeichnet sich vor allem durch ihre hohe Portabilität aus. So können heute Java Programme, nach Aussage von Oracle, auf über 3 Milliarden Geräten ausgeführt werden. Auch die Vielfalt der erhältlichen oder eingesetzten Applikationen ist gigantisch. Es ist keine Seltenheit, dass eine Branchensoftware komplett in Java geschrieben wurde. Anfänglich war Java in Form von Java Applets auch im Internet sehr verbreitet. Diese wurden in den vergangenen Jahren aber immer mehr durch Lösungen in anderen Programmiersprachen verdrängt. Im sogenannten Web 2.0 gelten Java Applets eher als eine Seltenheit.

Java war schon seit jeher eine mächtige Programmiersprache und ist sei der Jahrtausendwende wohl eines der am meistverbreiteten Plug-Ins für den Browser. Dies ist unter anderem auch so da das Plug-In ein Teil des Java Runtime Environment (JRE) ist. Schon früh wurde erkannt dass man über die Java Applets in Systeme eindringen, Daten auslesen und Programmcode ausführen konnte. Der Sicherheitsgedanke war zu diesem Zeitpunkt praktisch nicht vorhanden. Über die Jahre hinweg und nach etlichen Einbrüchen in Computersysteme, die Java Applets als Einfallstor nutzen, wurden Sicherheitsmechanismen rund um Java implementiert oder verbessert.

Situation heute

Alleine im Jahr 2012 wurden gemäss cvedetails.com 58 Schwachstellen im Java Runtime Environment (JRE) entdeckt und gemeldet. Die letzte 0day Schwachstelle sorgte Ende August rund um die Welt für Wirbel. Die grosse Medienaufmerksamkeit hat sicher dazu beigetragen, dass die Verbreitung im überschaubaren Rahmen blieb. Ebenso hatte es der sogenannte Flashback-Trojaner, der eine bekannte Java-Sicherheitslücke ausnutze, welche von Apple in MacOSX nicht gepatched wurde, in die Medien geschafft. Nebst den bekannten 0day Schwachstellen wurden auch im Jahr 2012 Exploits für Java-Schwachstellen gesichtet, welche von Oracle in einem Update schon behoben wurden. Wenn man jedoch dieses Update nicht zeitnah auf den Rechner verteilt hatte, war man trotzdem gegenüber diesen Exploits verwundbar.

Dass Java ein beliebtes Einfallstor ist zeigt auch das Social Engineering Toolkit, in welchem eine der effizientesten Attacken auf ein Java Applet zurückgreift.

Schwachstelle und mögliche Folgen

Es sind schon einige Analysen des im Internet kursierenden 0day Exploits frei erhältlich und ich möchte nur auf die möglichen Auswirkungen eingehen.

Durch die gezielte Ausnutzung zweier Schwachstellen ist es möglich, die Rechte zu erweitern und danach beliebigen Programmcode auszuführen. Auf Pastebin ist der Proof-of-Concept Code verfügbar, welcher auf einem Windows-System den Taschenrechner startet.

Die Schwachstellen selbst wurden entdeckt, nachdem gängige Hacker-Kits wie BlackHole oder Nuclear Pack ihren Kunden einen neuen Exploit für Java zur Verfügung gestellt haben. Es ist davon auszugehen, dass die Schwachstellen schon länger ausgenutzt und jetzt einfach noch dem Mainstream zur Verfügung gestellt wurde. Wurde ein Benutzer Opfer des Exploit, kann der Schädling beliebigen weiteren Schadcode nachladen und so das komplette System kompromittieren.

Oracle hat nach 3 Tagen einen Update des JRE veröffentlicht. So mancher Bericht hat kurz darauf Entwarnung gegeben und Oracle wurde für ihr rasches Handeln gelobt. Die Entwarnung könnte etwas verfrüht gekommen sein. Vor der Entdeckung existierte der Exploit schon seit einer unbekannten Zeit. Das ergibt als Zwischensumme +3 Tage. Und Oracle hat angeblich mit ihrem Update nur eine der beiden Schwachstellen behoben. Würde die offene Schwachstelle wieder mit einer ähnlichen Schwachstelle kombiniert, könnte der Exploit wieder funktionieren.

Ebenfalls steht gemäss krebsonsecurity.com angeblich schon der nächst 0day Exploit vor der Tür der auch mit dem neusten Update funktionieren soll.

Massnahmen Privat

Zuerst die einfache Lösung für den privaten Rechner. Die Betreiber von Heise stellen seit Jahren einen Browsercheck auf ihrer Webseite zur Verfügung. Man kann nicht nur testen, ob das Java Browser Plug-In aktiv ist, sondern es sind auch Links zu Hilfestellungen vorhanden, wie man das Plug-In im Browser deaktivieren kann. Vor allem wenn man im Web auf Java angewiesen ist, empfiehlt es sich mit zwei verschiedenen Browsern (z.B. Chrome & Firefox) zu arbeiten. Einer für das normale Surfen im Netz mit deaktivierten Plug-Ins, der andere für den expliziten Gebrauch von Webseiten, die Plug-Ins benötigen.

Ebenfalls eine gute Lösung bietet das Browser Plug-In NoScript an, indem Java, JavaScript und Flash nicht mehr automatisch ausgeführt werden, wenn man eine Webseite aufruft. Bei Bedarf kann man für einzelne Webseiten dann die Funktionalität innerhalb des Plug-Ins wieder freischalten.

Ebenfalls hat Oracle seit der Version 7 Update 10 eine Einstellungsmöglichkeit implementiert, mit welcher Java in allen Browsern für den angemeldeten Benutzer deaktiviert werden kann. Unter dem Punkt Sicherheit in den Einstellungen kann einfach die Checkbox deaktiviert werden. Somit kann man immer noch lokale Java Programme benutzen, ohne sich der Gefahr von Java-Drive-by Downloads im Browser auszusetzen.

Massnahmen Firma

Gerade in der Geschäftswelt und vor allem in der IT wird immer wieder mit Java Applets gearbeitet. Management Konsolen von grossen Software Herstellern setzen teilweise noch immer auf diese Technologie und IT-Administratoren wie auch Benutzer können dadurch von dieser Technologie abhängig sein. Also kommt in diesem Umfeld ein komplettes Deaktivieren der Plug-Ins nicht in Frage. Was nun?

Im Rahmen des IT Risk Management sollte eine Analyse des Problems erstellt werden. Das Resultat dieser Analyse kann natürlich je nach Branche, Grösse und Region unterschiedlich ausfallen. Wichtig ist auch das allfällige Eingriffe in die Funktionalität von einer internen Stelle abgesegnet werden und die Stelle sich den jeweiligen Risiken bewusst ist. Häufig ist diese Stelle ein Mitglied der Geschäftsleitung. Ebenfalls ist eine Lösung meistens mit Aufwand verbunden. Zusätzlich können noch einmalige wie auch wiederkehrende Kosten für eine technische Lösung entstehen. Also ist es ratsam von Anfang an die Risiken und Massnahmen mit der Geschäftsleitung abzustimmen.

Wie auch im privaten Bereich kann natürlich auf eine Zweitbrowserlösung gesetzt werden. Dies ist sicher die kostengünstigste Variante, bedingt aber, dass sich alle Mitarbeiter strikt an die Vorgaben der Browsernutzung halten müssen. Erweitern könnte man diese Lösung mit einem Proxy-Ansatz, wobei dem Browser mit deaktivierten Plug-Ins der Zugriff über den Proxy ins Internet erlaubt und dem anderen der Zugriff verwehrt würde.

Oder man trennt gleich das Internet von der internen Infrastruktur. Dies könnet über eine Terminal Server oder eine Virtual Desktop Infrastruktur realisiert werden, welche in einer abgeschotteten DMZ betrieben würde. Die dabei entstehenden Kosten können sich natürlich je nach Lösung erheblich unterscheiden.

Eine weitere Lösung ist das Whitelisting. Viele Firmen verfügen schon über eine Proxy-Infrastruktur, welche über verschiedene Inhaltsfilter-Funktionalitäten verfügt. Somit bietet es sich an, die sogenannten MIME-Types von Java generell auf dem Proxy zu sperren. Falls doch ein Mitarbeiter Zugriff auf Java-Inhalte benötigt, können diese explizit für die jeweilige Webseite freigegeben werden, nachdem sie als vertrauenswürdig eingestuft wurden. Dies ist sicher kurzfristig mit einem höheren Aufwand verbunden, doch wird die Gefahr durch Java Applets gesenkt. Man kann natürlich in diesem Schritt dasselbe auch gleich für Flash Inhalte implementieren, aber dies ist eine andere leidige Geschichte.

Egal für welche Lösung man sich am Ende entscheidet, wichtig sind folgende Punkte:

• Es können je nach Lösung Kosten und Aufwände anfallen.
• Die technische Lösung sollte zentral managebar sein und sich in die bestehende Infrastruktur einfügen.
• Es bedarf je nach Lösung einer Anpassung oder Erstellung von Prozessen. Dies geschieht am besten möglichst früh mit der entsprechenden Stelle.
• Je nach Resultat der Risikoanalyse kann das Risiko natürlich auch getragen werden, ohne dass eine entsprechende technische Lösung angestrebt wird.

Fazit

Apple hat es vorgemacht und rigoros auf Java und Flash auf ihren iOS Geräten verzichtet und so gezeigt, dass das Web auch ohne diese Technologien wunderbar funktionieren kann. Java wird auch in Zukunft eine wichtige Rolle in den Unternehmen spielen, aber Java Applets werden über kurz oder lang aus dem Web verschwinden. Und als proaktiver Schutz vor solchen 0day Schwachstellen sollte man, wenn möglich, auf dieses Browser Plug-In verzichten.

Links

• http://heise.de/-1782352
• http://immunityproducts.blogspot.com.ar/2013/01/confirmed-java-only-fixed-one-of-two.html
• http://isc.sans.edu/diary/14917
• http://krebsonsecurity.com/2013/01/new-java-exploit-fetches-5000-per-buyer/#more-18509
• http://malware.dontneedcoffee.com/2013/01/0-day-17u10-spotted-in-while-disable.html
• http://noscript.net
• http://pastebin.com/raw.php?i=cUG2ayjh
• http://www.cvedetails.com/product/19117/Oracle-JRE.html?vendor_id=93
• http://www.heise.de/security/dienste/Browsercheck-2107.html
• https://vuldb.com/?id.5000
• https://vuldb.com/?id.6014
• https://vuldb.com/?id.7313
• https://www.trustedsec.com/downloads/social-engineer-toolkit/