Dipl.-Inform. Carsten Eilers

Der Titel, den Adobes Sicherheitschef Brad Arkin für seinen Blog-Beitrag gewählt hat, dürfte einen Preis als Untertreibung des Jahres verdient haben: "Inappropriate Use of Adobe Code Signing Certificate".

dict.leo.org schlägt als Übersetzung von Inappropriate einiges vor: unangebracht, unangemessen, ungeeignet, ungünstig, unpassend, unsachgemäß, untunlich, unzweckmäßig und zweckwidrig. Das passt sicher alles auf den Vorgang, aber das klingt alles viel zu harmlos. Oder sollte ich besser verharmlosend schreiben, denn Adobe sollte die Bedeutung des Vorfalls ja klar sein?

Was ist da los?

Laut Brad Arkin hat Adobe zwei bösartige Tools erhalten, die mit einem gültigen Adobe-Zertifikat signiert waren. Bei der Untersuchung des Vorfalls stieß man auf einen kompromittierten Build-Server mit Zugriff auf die Code-Signing-Infrastruktur. Adobe plant nun, das missbrauchte Zertifikat am 4. Oktober zurückzurufen und für die damit signierten Programme Updates zu veröffentlichen.

Betroffen sind laut Brad Arkin und dem veröffentlichten Security Advisory außer drei AIR-Anwendungen für Windows und Mac OS X "nur" Programme für Windows, laut FAQ scheinen es dort aber auch mehr oder weniger alle zu sein. Der FAQ zufolge sollen aber alle Nutzer von Coldfusion 10 das Update installieren - einschließlich denen, die Linux verwenden. Wieso, weshalb, warum? Das weiß nur Adobe, und zumindest in der FAQ hat man es nicht verraten. Entweder ist das ein schlichter Fehler in der FAQ, oder es ist mal wieder mehr passiert als man zugeben möchte.

Die bösartigen Tools mit Adobe-Signatur

Beim ersten bösartigen Tools handelt es sich um pwdump7, ein Programm zum Extrahieren von Passwort-Hashwerten aus Windows-Systemen. Außer der Programmdatei selbst wurde auch eine Version der davon genutzten OpenSSL-Bibliothek libeay.dll signiert.

Beim zweiten Tool handelt es sich um einen ISAPI-Filter, eine Erweiterung für Microsofts Webserver IIS. Was diese Erweiterung mit dem Dateinamen myGeeksmail.dll macht, ist nicht angegeben.

Die Daten der bösartigen Tools wie MD5-Hash und Dateigröße sowie die Daten des betroffenen Zertifikats sind im Security Advisory angegeben.

Was ist nun zu tun?

Die Antivirenhersteller wurden über das Microsoft Active Protection Program (MAPP) mit den bösartigen Programmen versorgt. Früher oder später sollten also alle am MAPP teilnehmenden Hersteller Updates veröffentlichen, die diese Programme erkennen.

Als Workaround schlägt Brad Arkin vor, ggf. die Ausführung der beiden bösartigen Programme auf Grundlage ihrer MD5-Hashwerte durch eine Software Restriction Policy zu verbieten. Dem betroffenen Zertifikat das Vertrauen zu entziehen führt nicht zum Ziel: Die Ausführung der Programme wird nicht verhindert, das entzogene Vertrauen hat aber negative Auswirkungen auf die "User experience" und verhindert die Ausführung gültiger Adobe-Software mit entsprechender Signatur. Letzteres dürfte bei gewissen Programmen die "User experience" aber eher verbessern. Ich denke da speziell an den Flash Player, durch dessen Ausschalten auf vielen Websites die nervende Werbung verschwindet.

Adobes Code-Signing-Infrastruktur - System mit Fehler

Die privaten Schlüssel der Code-Signing-Zertifikate werden in Hardware Security Modulen (HSM) gespeichert, die an sicheren Orten aufbewahrt werden. Alle Instanzen (im wesentlichen also wohl Build-Server etc.), die digitale Signaturen erstellen lassen dürfen, werden nach festgelegten Verfahren überprüft. Dadurch soll zum einen ihre Identität und zum anderen die Einhaltung der Regeln für die Entwicklungsumgebung sicher gestellt werden. So weit, so gut. Code-Signing-Requests werden über gegenseitig authentifizierte Transport Layer Security (TLS) Verbindungen an den Code-Signing-Dienst übertragen und nur ausgeführt, wenn der Request von der korrekten IP-Adresse stammt. Oh weh.

Falls es Ihnen nicht sofort ins Auge springt: Dieses System weist einen kritischen Fehler auf, dem Adobe ja nun auch zum Opfer gefallen ist. Jeder, der eine dieser Instanzen wie beispielsweise einen der Build-Server kontrolliert, kann darüber sofort Programme signieren lassen. Nun ist es leicht, hinterher zu sagen, dass man das hätte bemerken müssen. Aber meiner Meinung nach hätte man das wirklich erkennen müssen.
Wer ist bloss auf diese Idee gekommen? Oder besser: Warum wurde das nicht längst geändert, um auf bekannte Angriffe zu reagieren? Denn dieser Angriff kommt ja nicht aus heiterem Himmel.

Angriffe auf Zertifizierungsstellen gab es in den vergangenen Jahren reichlich. Und immer wurde dabei "über Bande" gespielt und nach einer Möglichkeit gesucht, Zertifizierungsanträge einzuschleusen, die dann von den CAs signiert wurden. Dass die Cyberkriminellen immer wieder Code-Signing-Zertifikate ausgespäht haben oder sich Schadsoftware signieren ließen, ist allgemein bekannt. Wenn man das zusammen nimmt, war mit entsprechenden Angriffen auf Code-Signing-Infrastrukturen also seit mindestens zwei bis drei Jahren zu rechnen.

Und dann betreibt Adobe eine Code-Signing-Infrastruktur mit mehr oder weniger direkten Anschluss ans Internet? So etwas gehört auf einen allein stehenden Rechner, zu dem nur ausgewählte Mitarbeiter Zugang haben. Nicht in ein lokales Netz, und erst recht nicht in ein Netz, das mit dem Internet verbunden ist. Egal wie viele Schutzmaßnahmen dazwischen sind.

Sofort nach den ersten Untersuchungen der signierten bösartigen Programme wurde die Code-Signing-Infrastruktur außer Betrieb genommen. Als Übergangslösung wurde eine neue Clean-Room-Implementierung einer Code-Signing-Infrastruktur eingerichtet, um alle nach dem 10. Juli 2012 mit dem betroffenen Zertifikat signierten Programme neu zu signieren. Diese Übergangslösung ist auch für das Signieren der neu veröffentlichten Programme zuständig. Als zusätzlicher Sicherheitsfaktor muss ein Mensch bestätigen, dass die zu signierende Software gültige Adobe-Software ist. Hoffentlich prüft er die auch wirklich und verfährt nicht nach dem Muster der bisherigen Softwarelösung "Wenn es von einem unserer Server kommt, stammt es natürlich von uns!"

Eine neue, dauerhafte Code-Signing-Infrastruktur ist in Arbeit. Ich hoffe nur, dass man dabei daran denkt, das Kabel zum Internet zu kappen.

Der Angriff

Adobe konnte laut Brad Arkin einen kompromittierten Build-Server ermitteln, der im Rahmen des Build-Prozesses Zugriff auf den Code-Signing-Dienst hat. Die Konfiguration dieses Servers entsprach nicht den Standards für einen Build-Server, was aber vorher niemanden aufgefallen war. Wieso, wird noch untersucht. Der Server hatte außer dem Recht zu Code-Signing-Requests keinen Zugriff auf weitere Funktionen der Public Key Infrastruktur (PKI).

Auf dem Build-Server wurde Schadsoftware gefunden, auch die mögliche Ursache für die Infektion wurde bereits ermittelt. Außerdem gibt es forensische Beweise dafür, dass der Server die Signatur der bösartigen Programme veranlasst hat. Der Angreifer hatte aber keinen Zugriff auf den privaten Schlüssel des verwendeten Zertifikats.

Der Build-Server hatte nur Zugriff auf den Sourcecode eines (nicht genannten) Produkts. Bei einer Überprüfung der Änderungen am Code-Repository wurden keine Manipulationen festgestellt, auch gibt es keinen Hinweis dafür, dass Code ausgespäht wurde.

Adobe geht davon aus, dass der Angreifer im Rahmen eines Advanced Persistent Threats zuerst einen anderen Adobe-Rechner übernommen und sich von dort Zugriff auf den Build-Server verschafft hat. Von dort wurden dann die Code-Signing-Requests für die bösartigen Programme erzeugt. Die wurde von der Code-Signing-Infrastruktur akzeptiert und die Programme signiert. Mein Mitleid hält sich in Grenzen. Wer so leichtsinnig mit seiner Code-Signing-Infrastruktur umgeht, hat es nicht besser verdient.

Die Folgen des Angriffs

Erst mal muss Adobe eine Menge zerdeppertes Porzellan wegräumen, sprich: Programme neu signieren und verteilen. Laut Mikko Hypponen von F-Secure gibt es 5127 Dateien die mit dem kompromittierten Zertifikat signiert wurden, und nur 3 bösartige. Und unter den betroffenen Programmen befinden sich auch Flash Installer etc.,

Und dann muss Adobe erst mal beweisen, dass man ihren neuen Signaturen vertrauen kann. Wieso sollte man das tun? Vielleicht wäre es an der Zeit, dem Vorbild der angegriffenen CAs zu folgen und einen externen Audit durchführen zu lassen.

Sehr genügsame Angreifer?

Ach ja: Die Build-Infrastruktur wurde ja auch kompromittiert. Wurden eigentlich schon alle anderen Server auf mögliche Kompromittierungen untersucht, oder nur die für die Signaturerzeugung der beiden Programme in Frage kommenden? Nicht, dass in ein paar Wochen dann raus kommt, dass noch mehr Server kompromittiert waren und ein paar Anwendungen verwanzt wurden.

Irgendwie kommen mir die Angreifer nämlich zu genügsam vor. Nur einen allgemein bekannten Passwortsammler und eine IIS-Erweiterung mit unbekannter Funktion signieren zu lassen ist angesichts des betriebenen Aufwands doch ein ziemlich mageres Ergebnis, oder? Vor allem, wenn man doch wohl vom 10. Juli bis Mitte September Zugriff auf die Server hatte. Was haben die Angreifer denn die ganze Zeit gemacht? Nichts? Mit einem Fuss in Adobes LAN? Laut Security Advisory wurden die Programme am 25. und 26. Juli signiert. Und ansonsten war man tatenlos? Das kann ich mir eigentlich nicht vorstellen.

Adobe wurde kompromittiert. Jetzt müssen sie zusehen, wie sie beweisen, dass sie es nicht mehr sind.

Carsten Eilers