Dipl.-Inform. Carsten Eilers

Code Signing basiert auf digitalen Signaturen, also einem asymmetrischen System mit öffentlichen und privaten Schlüsseln: Das fertige Programm wird vom Entwickler mit seinem privaten Schlüssel signiert, vor der Ausführung wird die Signatur mit Hilfe des öffentlichen Schlüssels geprüft. Ist die Signatur in Ordnung, kann man sicher sein, dass das Programm von angegebenen Entwickler stammt und nicht manipuliert wurde. Das sagt natürlich nichts über die Funktion des Programms aus, auch bösartige Programme können signiert werden.

Der Benutzer steht vor dem Problem, dass er sich den öffentlichen Schlüssel des Entwicklers besorgen muss. Und das für jeden Entwickler, und zwar so, dass er sicher ist, wirklich den richtigen Schlüssel zu verwenden. Die einfachste Lösung dieses Problems liefert eine Public Key Infrastruktur mit ihren Zertifizierungsstellen (Certificate Authority, CA): Öffentlicher Schlüssel und Informationen über seinen Inhaber werden zusammen mit diversen Verwaltungsinformationen zu einem Zertifikat zusammengefasst, und die CA bestätigt mit ihrer Unterschrift unter diesem Zertifikat, dass die Informationen darin korrekt sind. Wer der CA vertraut, kann also auch den von ihr signierten Zertifikaten und damit den darin enthaltenen öffentlichen Schlüsseln trauen.

Zufällig gibt es im Internet bereits eine entsprechende PKI: Die, die für SSL/TLS genutzt wird. Also bietet es sich an, diese PKI auch für die Ausstellung und Prüfung der Zertifikate für das Code Signing zu nutzen. Und genau das wird auch gemacht.

Code Signing und die Sicherheit

Je nach Sicherheitsrisiko bekommt der Benutzer vor dem Start einer Java-App andere Sicherheitshinweise zu sehen. Erst wenn er daraufhin seine Zustimmung zum Start der App gibt, wird diese Ausgeführt. Die verschiedenen möglichen Fälle gelten generell für signierten Code, also werde ich im folgenden mal Oracles Annahmen und Ratschläge dazu als Leitfaden verwenden.

1. Apps mit einem Zertifikat einer vertrauenswürdigen CA

Apps mit einem Zertifikat einer vertrauenswürdigen CA hält Oracle für ein geringes Risiko. Wieso schon diese Annahme ein Irrtum ist, erkläre ich weiter unten. Oracle empfiehlt, zu prüfen, ob die im Sicherheitshinweis angegebenen Informationen Anwendungsname, Namen des Anbieters und Speicherort, d.h. den Server und Pfad, von dem die App geladen wurde, "Sinn macht". Vermutlich soll man also diese Informationen auf Plausibilität prüfen. Das setzt voraus, das der Benutzer diese Informationen überhaupt einschätzen kann. Das Beispiel von Oracle ist ziemlich simpel:

Die App heißt also "Java Detection", wird von "Oracle America, Inc." angeboten und ist unter http://java.com/applet/JavaDetection_applet.jnlp gespeichert. Ist das plausibel? Ich würde sagen: Ja. Aber was ist, wenn zum Beispiel in einem Portal eine Spiele-App eines anderen Herstellers eingebunden wird, die von dessen Server geladen wird? Da sähen die Informationen aus dem Sicherheitshinweis dann zum Beispiel so aus:

Und diese Meldung würde dann zum Beispiel von der Website www.unterhaltungsportal.example ausgegeben. Sind diese Angaben plausibel? Vielleicht ja, vielleicht nein. Wie soll der Benutzer das beurteilen? Lädt das Portal regelmäßig Daten von anderen Server, so dass alles OK ist? Oder wurde der Benutzer zum Beispiel Opfer eines XSS-Angriffs? Oder wurde das Portal kompromittiert? Und selbst wenn alles OK ist - wie sicher ist denn der Server der Spiele-Entwickler?

2. Apps ohne Zertifikat (unsignierte Apps)

Dazu schreibt Oracle:

"Anwendungen dieses Typs können im Allgemeinen gefahrlos ausgeführt werden, weil ihre Aktionen begrenzt sind. Es besteht allerdings ein geringes Sicherheitsrisiko. Es wird empfohlen, dass Sie auf Abbrechen klicken, wenn der Herausgeber der Site, die Sie besuchen, Ihnen nicht bekannt ist. "

Natürlich können diese Anwendungen Schaden anrichten. Zum Beispiel eine Schwachstelle in Java ausnutzen, um aus der Sandbox auszubrechen und Schadcode auf dem Rechner des Benutzers auszuführen. So, wie es in letzter Zeit des öfteren passiert ist. Wer hat denn da bei Oracle den Kanonenknall nicht gehört? Und was das Abbrechen klicken betrifft, wenn der Herausgeber der besuchten Website nicht bekannt ist - hat Oracle noch nie etwas davon gehört, dass Drive-by-Infektionen inzwischen überwiegend auf harmlosen, kompromittierten Websites oder über manipulierte Werbeanzeigen verbreitet werden?

3. Apps mit einem abgelaufenen Zertifikat einer vertrauenswürdigen CA

Zur vertrauenswürdigen CA komme ich noch, bleibt hier das abgelaufene Zertifikat. Laut Oracle stellen diese Apps ein moderates Sicherheitsrisiko dar, da der Anbieter sein Zertifikat nicht erneuert hat. Es soll die gleiche Plausibilitätsprüfung wie für gültige Zertifikate durchgeführt werden. Entsprechend gilt das oben geschriebene auch hier. Übrigens verwendet Oracle zur Zeit ein falsches Bild für dieses Beispiel: Die gezeigte Warnung enthält keine Informationen über die App.

4. Apps mit einem Zertifikat von einer nicht vertrauenswürdigen Quelle

Hierzu schreibt Oracle:

"Anwendungen dieses Typs stellen die höchste Risikostufe dar, weil der Herausgeber nicht identifiziert ist und die Anwendung möglicherweise Zugriff auf persönliche Daten auf Ihrem Computer gewährt. Es wird empfohlen, dass Sie bei Anzeige dieses Hinweises auf "Abbrechen" klicken."

Das ist im Grunde richtig, trifft aber auch alle selbst signierten Apps der Entwickler, die sich kein Zertifikat bei einer CA kaufen können (zum Beispiel weil es ihnen zu teuer ist) oder wollen (zum Beispiel weil sie wissen, wie wenig aussagekräftig das ganze ist). Vor allem Shareware, Open-Source-Software etc. wird damit effektiv behindert. Warum sollte man selbst signierter Open-Source-Software weniger vertrauen als einem womöglich dubiosen Closed-Source-Applet mit Zertifikat einer vertrauenswürdigen CA?

Die Vertrauenswürdigkeit der CA

Kommen wir zum entscheidenden Punkt: Der Vertrauenswürdigkeit der CAs. Jede PKI basiert im Grunde darauf, dass die Benutzer der verwendeten CA vertrauen. Im Fall von SSL/TLS und eben auch dem Code Signing gibt es aber nicht nur eine CA, sondern viele. Und welche davon vertrauenswürdig sind, entscheiden die Hersteller der Betriebssysteme und Anwendungen, die die CAs nutzen. Und die vertrauen im Allgemeinen viel zu vielen CAs. Darunter auch etlichen, bei denen man sich fragt, ob die erstens wirklich vertrauenswürdig sind und/oder zweitens wirklich weltweit entsprechend eingestuft werden müssen.

Das die CAs das in sie gesetzte Vertrauen oft nicht verdienen, haben sie selbst in den letzten Jahren eindrucksvoll bewiesen. Siehe zum Beispiel die Angriffe auf Comodo und vor allem DigiNotar (Ergänzung 1, 2 3), aber auch weitere CAs. Siehe die gegen Regeln verstoßende malaysischen CA Digicert Sdn. Bhd.. Und siehe das von Trustwave ausgestellte MitM-Zertifikat. Denn soll man vertrauen? Wieso?

Eine einzige falsch handelnde CA reicht aus, um die Sicherheit des Gesamtsystems zu unterlaufen. Wenn auch nur eine einzige CA Code-Signing-Zertifikate an nicht vertrauenswürdige Entwickler heraus gibt, egal ob absichtlich oder versehentlich, ist die Sicherheit des Code Signings hinüber. Wer garantiert, dass das nicht passiert? Niemand. Warum also sollten die Benutzer den signierten Apps mehr vertrauen als den unsignierten? Zumindest der Faktor "Aussteller des Zertifikats" (d.h. die CA) muss mit berücksichtig werden, um zu entscheiden, für wie vertrauenswürdig man das Zertifikat hält. Vorausgesetzt, man kann die Vertrauenswürdigkeit der CA einschätzen, was meist nur schwer möglich ist.

Oracle ist es übrigens egal, welche CA die Entwickler verwenden. Man empfiehlt dort, im Internet nach einen passenden Anbieter zu suchen oder selbst signierte Zertifikate zu verwenden.

Die Vertrauenswürdigkeit der Zertifikate
oder
Schadsoftware mit gültigem Zertifikat

Selbst wenn alle CAs sich korrekt verhalten, hat das System noch einen Schwachpunkt: Die Entwickler müssen mit ihrem Zertifikat bzw. genauer dem dazu gehörenden privaten Schlüssel verantwortungsvoll umgehen. Es ist in der Vergangenheit immer wieder vorgekommen, dass Schadsoftware korrekte Signaturen enthielt, meist weil die dafür verwendeten privaten Schlüssel ausgespäht wurden. Und ganz aktuell geht der Trend wohl zum "CA vergibt Zertifikat an dubiose Entwickler". Einige Beispiele:

• Im Februar 2013 entdeckte ESET einen Onlinebanking-Trojaner mit gültiger Signatur. Das pikante daran: Das zugehörige Zertifikat war von der CA DigiCert am 19. November 2012 für ein Unternehmen ausgestellt worden, dass bereits 2011 aufgelöst worden war. Soviel zum Thema "Vertrauenswürdigkeit der CA".
• Kurz zuvor, ebenfalls im Februar 2012, war DigiCert bereits einmal negativ aufgefallen: Malwarebytes berichtete über einen brasilianischen Password Stealer mit gültiger Signatur. Ausgestellt war das zugehörige Zertifikat von DigiCert - für eine nicht existente Scheinfirma.
• Im September 2012 wurde ein Adobe-Zertifikat missbraucht, einige bösartige Tools wiesen eine korrekte Adobe-Signatur auf.
• Im Mai 2012 veröffentlichte Yahoo! versehentlich den privaten Schlüssel zum Signieren von Erweiterungen für den eigenen Browser.
• Stuxnet und seine "Kollegen" wie beispielsweise Duqu enthielten Komponenten mit korrekter Signatur verschiedener Unternehmen. Duqu soll u.a. Zertifizierungsstellen angegriffen haben - vermutlich wollte die Cyber-Krieger ja ihren Vorrat an den benötigten Zertifikaten aufstocken.
• Und hier noch ein paar Beispiele.

Falls ein privater Schlüssel abhanden kommt, ist das theoretisch kein Problem: Wenn es rechtzeitig bemerkt wird, kann man den Schlüssel sperren lassen. Danach werden damit erstellte Signaturen als ungültig betrachtet. Vorausgesetzt, dass die Gültigkeit des Zertifikats geprüft wird. Wer hat das gerade nicht gemacht? Java. Dort muss der Benutzer die Prüfung für zurückgerufene Zertifikate erst einschalten, per Default ist sie ausgeschaltet. Und daran wird sich auch bis zum Juni-2013-Update nichts ändern.

Ein typischer Angriff - vor und nach Oracles Update

Bisher lief die Drive-by-Infektion so ab, dass das bösartige Java-Applet im Hintergrund geladen und ausgeführt wurde. Ohne dass der Benutzer irgend etwas bemerkte, wurde sein Rechner mit Schadcode infiziert.

Seit dem neuesten Java-Update startet Java ein Applet generell erst, nachdem der Benutzer dem Start zugestimmt hat. Der Benutzer wird nun also auf einer Website gefragt, ob er den Start eines Java-Applets erlauben will. Im allgemeinen sind das vertrauenswürdige Websites, deren Server kompromittiert wurde oder auf denen Werbung von einem kompromittierten Ad-Server eingeblendet wird. Was wird der Benutzer also in den meisten Fällen machen? Dem Start des Applets zustimmen, denn er befindet sich ja auf einer vertrauenswürdige Website, die er nutzen will. Zumindest wenn die Cyberkriminellen einen halbwegs plausibel klingenden Namen dafür verwenden. Denn was das Applet macht bzw. machen soll, erfährt der Benutzer in den Sicherheitshinweisen ja nicht. Kann er auch gar nicht, denn das Code Signing dient nur dazu, die Herkunft des Codes zu beweisen. Ob er harmlos oder bösartig ist, ist dabei egal. Und nachdem der Benutzer seine Zustimmung gegeben hat, wird sein Rechner mit Schadcode infiziert, ohne dass er etwas davon bemerkt. Wenn die Cyberkriminellen schlau sind, lassen sie das Applet noch irgend was harmloses machen, damit sich der Benutzer nicht wundert, dass nichts passiert.

Carsten Eilers