Java pfuscht bei Zertifikatschecks

Auf den Seiten der TU Chemnitz platzierten Gauner ein Java-Applet, das Rechner infizierte. Allerdings hätte das trotz digitaler Signatur nicht so einfach funktionieren sollen, weil das Zertifikat bereits gesperrt war. Aber wir reden ja von Oracle.

In Pocket speichern vorlesen Druckansicht 350 Kommentare lesen
Lesezeit: 2 Min.

Dieses digital signierte Java-Applet war ein Trojaner.

(Bild: Eric Romang)

Beim Aufruf des Online-Wörterbuchs Beolingus der TU Chemnitz erschien eine Abfrage, ob der Anwender eine Java-Anwendung ausführen möchte. Das angebliche "Java ClearWeb Security Update" trug eine anscheinend gültige digitale Unterschrift der Firma CLEARESULT CONSULTING INC. Doch wer auf "Run" klickte, infizierte seinen Rechner mit Schad-Software, berichtet der Blogger Eric Romang.

Auf den Web-Seiten der TU Chemnitz war demnach eine Variante des g01pack-Exploit-Kits eingeschleust worden, das das Java-Applet aktivierte. Mit seiner digitalen Signatur durfte es die Java-Sandbox verlassen und aus dem Internet nachgeladene Programme auf dem Rechner des Anwenders installieren. Allerdings hatte der Herausgeber Godaddy das dafür verwendete Code-Signing-Zertifikat bereits ab dem 7.12.2012 gesperrt ("Cessation Of Operation"); vermutlich war wohl dem Eigentümer aufgefallen, dass der geheime Schlüssel zum Signieren von Code gestohlen worden war. Ein Programm, das das Zertifikat richtig überprüft – also auch die dort festgelegte Widerrufsliste vom CRL Distribution Point abholt und kontrolliert – hätte bemerken müssen, dass es dort als ungültig gelistet ist.

Die Überpüfung auf eine eventuelle Sperrung ist standardmäßig nicht aktiv.

Aber wir reden hier von Oracle: Und die Herren über den Java-Code haben die Gültigkeitsprüfung von Zertifikaten zwar vorgesehen – aber nicht aktiviert. Weder die Kontrolle der Sperrlisten noch der Online-Check via OCSP sind in den Standardeinstellungen aktiv. Und das obwohl Oracle der digitalen Signatur eines Applets so hohen Stellenwert beimisst, dass es damit aus der Sandbox aussteigen und das System eines Anwenders beliebig manipulieren darf – was einem unsignierten Applet prinzipiell erstmal nicht möglich ist.

Diese Entdeckung riss den obersten Malware-Analysten des AV-Herstellers Avast Jindrich Kubec zu einem deftigen wtf hin. Es bleibt somit bei der Empfehlung: Wer es nicht unbedingt braucht, sollte Java komplett deinstallieren. Als Kompromiss kann man zumindest die Java-Einbindung im Browser deaktivieren beziehungsweise das von Firefox und Chrome angebotene Click-to-Play einsetzen, um wirklich benötigte Java-Applets von Hand zu starten. Auf die eingebauten Sicherheitsmechanismen von Java sollte man sich nicht verlassen.

Update 7.3.2013, 17:15: Frank Richter vom Universitätsrechenzentrum Chemnitz weist darauf hin, dass der Schadcode bereits am 4. März entfernt wurde – unmittelbar nachdem die ersten Hinweise dazu eingingen. Der Die Analysen, wie es zu der verantwortlichen Werbeeinblendung kam, dauern noch an, "wir vermuten eine Lücke im eingesetzten OpenX-Server", erklärt Richter gegenüber heise Security. (ju)