Falsche Zertifikate für Google und andere - ist SSL tot?
Aus aktuellem Anlass heute ein anderes als das angekündigte Thema:
Der niederländische Zertifizierungs-Dienstleister (Certificate
Authority, CA) DigiNotar hat SSL- und
Extended Validation SSL (EVSSL)-
Zertifikate für mehrere Domains ausgestellt, die nicht vom
eigentlichen Domain-Inhaber beantragt wurden. Darunter
am 10. Juli eins
für alle google.com-Domains (*.google.com), das damit sieben und nicht wie
oft behauptet fünf Wochen (die 28. bis 34.) unentdeckt blieb, bis es
am 28. August entdeckt
und
am 29. August zurückgezogen
wurde.
Herausgekommen
ist der Vorfall, als
Man-in-the-Middle-Angriffe,
insbesondere auf Nutzer von Google Mail, bekannt wurden. Es wird vermutet,
dass sich die iranische Regierung das Zertifikat beschaffte, um die
iranische Bevölkerung auszuspähen.
Verkauft oder gestohlen?
Während es anfangs hieß, das gefälschte Google-Zertifikat wäre regulär bei DigiNotar gekauft worden (niederländischer Artikel, englische Microsoft-Translator-Übersetzung, die deutsche ist leider völlig unbrauchbar), erklärte das Unternehmen später, es sei Opfer eines Angriffs geworden. Diese Erklärung wirft aber mehr Fragen auf als sie beantwortet.
Demnach wurde am 19. Juli ein Angriff auf die CA erkannt, die von den Angreifern ausgestellten Zertifikate zurückgerufen und ein externer Sicherheits-Audit eingeleitet. Hier ist erst mal festzustellen, dass das Google-Zertifikat am 10. Juli ausgestellt wurde (s.o.), die Angreifer also mindestens 9 Tage unbemerkt die Kontrolle über die angegriffenen Systeme hatten. Wie viele gefälschte Zertifikate ausgestellt wurden und für welche Domains sie gelten, wurde bisher verschwiegen. Google hat in Chromium 247 Zertifikate neu gesperrt, wie viele prominente Domains betroffen sind kann man nur raten. Laut The Register befinden sich darunter addons.mozilla.org, Yahoo.com, das Tor Project, WordPress und der iranische Blog-Anbieter Baladin. Während im Fall von addons.mozilla.org der Firefox-Chefentwickler zitiert wird, gibt es für die anderen Angaben keine verlässliche Quelleninformation.
Der externe Audit ergab, das alle betroffenen Zertifikate zurückgezogen wurden. Trotzdem wurde (mindestens) ein Zertifikat übersehen, ausgerechnet das für *.google.com. Mal abgesehen davon, dass der externe Audit vollkommen versagt hat stellt sich die Frage, wieso niemandem aufgefallen ist, dass man ein Zertifikat für Google ausgestellt hat. Oder warum sich niemand darüber gewundert hat, dass Google sich ein Zertifikat bei einer kleinen niederländischen CA holt und nicht wie zuvor bei Thawte.
Desweiteren stellt sich die Frage, wieso keine Warnung vor den falschen Zertifikaten veröffentlicht wurde. Sollte man in den Niederlanden nichts vom Angriff auf die CA von Comodo und deren Folgen gehört haben?
Nach dem Audit sollte ja eigentlich alles in Ordnung sein. Sollte man meinen. Dem ist aber ganz und gar nicht so, denn wie F-Secure herausfand, haben ein paar Hacker auf der Website von DigiNotar ihre Visitenkarten hinterlassen. Nun haben Webserver und CA-Infrastruktur (hoffentlich) nichts miteinander zu tun, aber wenn ein Angreifer 9 Tage sein Unwesen auf einem System getrieben hat, ist man gut beraten, dass und alle damit verbundenen Systeme sehr genau zu prüfen. Das ist anscheinend unterblieben. Denn die Defacement-Spuren sind "uralt", u.a. aus dem Mai 2009.
Und dann hat DigiNotar noch einen Artikel in niederländisch (englische Microsoft-Translator-Übersetzung) veröffentlicht, in dem erklärt wird, dass 99,99% der Browser-Warnungen vor ihren Zertifikaten ignoriert werden können. Einen gefährlicheren Rat kann man wohl kaum geben. Hätte man die Liste der gefälschten Zertifikate veröffentlicht und erklärt, bei allen anderen bestünde keine Gefahr, wäre das durchaus akzeptabel. So stellt sich die Frage, woran man die 0,01% echten Warnungen erkennt.
Update:
Vom Tor Project wurde
bestätigt,
dass gefälschte Zertifikate für deren Server erstellt wurden.
Swa Frantzen hat im ISC Diary den bisher gekannten
Zeitablauf
zusammen gestellt.
Update Ende
Trau, schau wem!
Fassen wir mal zusammen:
- Die CA wurde erfolgreich angegriffen
- Der Angriff wurde erst nach mindestens 9 Tagen entdeckt
- Es wurden mehrere gefälschte Zertifikate ausgestellt, darunter mindestens ein Extended-Validation-Zertifikat, dessen Ausgabe an besonders strenge Vergabekriterien gebunden ist - zumindest letzteres darf einer CA nicht passieren
- Alle Zertifikate wurden zurückgezogen, dabei aber (mindestens) eins übersehen
- Es wurde keine Warnung vor den gefälschten Zertifikaten veröffentlicht, obwohl einer CA bekannt sein muss, dass der Zertifikatsrückruf nicht unbedingt sicher ist und viele Browser die Rückruflisten nicht per Default überwachen
- Ein externer Audit stellt fest, dass alle gefälschten Zertifikate zurückgerufen wurden (was man nicht der CA anlasten kann, der kann man höchstens vorwerfen, den falschen Dienstleister gewählt zu haben)
- Ein übersehenes Zertifikat wird entdeckt, erst jetzt entschließt man sich zu einer Presseerklärung
- Nach dem Audit finden sich noch Spuren von Hackern auf der Website der CA
- Die CA gibt den Rat, die Benutzer sollten die Warnungen vor den Zertifikaten in den allermeisten Fällen ignorieren.
Die Frage nach der Vertrauenswürdigkeit so einer CA braucht man wohl nicht mehr zu stellen. Bis auf weiteres will DigiNotar keine Zertifikate mehr ausstellen, aber wer sollte auch Interesse dran haben? Von den meisten Browsern wird denen sowieso kein Vertrauen mehr entgegen gebracht, und im Zweifelsfalls ist eine Website ohne Zertifikat wohl vertrauenswürdiger als eine, die ein Zertifikat einer nicht vertrauenswürdigen CA vorweist.
Die Reaktionen
Eigentlich ist es ganz einfach, das Problem zu lösen: Wenn Sie das Root-Zertifikat einer unerwünschten CA aus ihrem System bzw. Browser löschen oder ihm das Vertrauen entziehen, werden danach alle von dieser CA ausgestellten Zertifikate als unbekannt bzw. ungültig erkannt und entsprechend gemeldet. Wobei im Fall einer Kompromittierung dem Zertifikat besser das Vertrauen entzogen werden sollte, da das ja den Tatsachen entspricht. Beim Löschen des Zertifikats besteht bei der späteren Meldung "Das Zertifikat konnte nicht geprüft werden, da die CA unbekannt ist" die Gefahr, dass dem Zertifikat irrtümlich doch vertraut wird. Bei der Warnung, dass es nicht vertrauenswürdig ist, ist diese Gefahr deutlich geringer.
In diesem Fall muss also nur dem Root-Zertifikat von DigiNotar das Vertrauen entzogen werden, um jede Gefahr zu beseitigen. Wie das in Firefox funktioniert, wird in der Online-Hilfe beschrieben. Prinzipiell funktioniert das bei allen Browsern und Systemen ähnlich. Es gibt aber auch Sonderfälle. So suchen Benutzer von Safari unter Mac OS X eine entsprechende Einstellung in ihrem Browser vergeblich. Safari nutzt die Zertifikatsverwaltung des Systems, die Konfiguration wird in der Schlüsselbundverwaltung, zu finden bei den Dienstprogrammen, erledigt, wie hier von Coriolis beschrieben. Dort wird empfohlen, das Zertifikat nicht nur zu sperren, sondern zu löschen, da Safari sonst eine irreführende Warnung ausgibt. Wenn sie sowieso gerade die Schlüsselbundverwaltung offen haben, sollten sie in den Einstellungen unter "Zertifikate" gleich noch die Einstellungen für deren Prüfung kontrollieren. Sowohl für OCSP als auch für CRL sollte "Bester Versuch" ausgewählt sein, die Priorität sollte auf OCSP gestellt werden.
Einige Hersteller haben bereits Maßnahmen ergriffen, um Ihnen das manuelle Ändern der Zertifikate zu ersparen. Von Mozilla gibt es Updates für Firefox für Windows, Mac OS X und Linux, SeaMonkey und Thunderbird, in denen dem DigiNotar Root-Zertifikat das Vertrauen entzogen wurde. Und auch Google hat eine neue Version von Chrome für Windows, Mac OS X und Linux veröffentlicht, in der DigiNotar deaktiviert wurde. Bei Opera dagegen verfolgt man einen anderen Ansatz, der auf der Certificate Revocation List basiert. Ist die nicht erreichbar, wird die Seite als normale Seite gekennzeichnet. Das ist zwar besser als nichts, eine Warnung erfolgt aber nicht.
Microsoft hat ein Security Advisory veröffentlicht. Windows-Versionen ab Vista verwenden die Microsoft Certificate Trust List, über die dem DigiNotar Root-Zertifikat Systemweit das Vertrauen entzogen wurde. Es gibt also auch eine Warnung, wenn z.B. versucht wird, ein mit einem DigiNotar-Zertifikat signiertes Programm zu installieren. Für Windows XP und Windows Server 2003 ist ein Update notwendig, das noch nicht zur Verfügung steht.
Ist SSL tot?
Nach dem Angriff auf Comodo im März ist dies der zweite erfolgreiche Angriff auf eine CA in kurzer Zeit, bei der gefälschte Zertifikate "erbeutet" wurden, und auch davor wurden schon falsche Zertifikate ausgestellt. Muss man SSL also misstrauen? Die Antwort lautet "Jein": SSL funktioniert aus technischer Sicht einwandfrei, die verschlüsselt übertragenen Daten sind sicher. Das Problem ist das Zertifizierungssystem. Es gibt zu viele Zertifizierungsstellen, denen die Webbrowser und Systeme "von Haus aus" vertrauen. Dieses Vertrauen ist vielleicht in den meisten Fällen gerechtfertigt, aber es wird grundlos auf alle und damit auch auf die schwarzen Schafe ausgedehnt. Über mögliche Alternativen wird bereits nachgedacht, mehr dazu in der nächsten Folge.
Trackbacks
Dipl.-Inform. Carsten Eilers am : Vertrauensfragen
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Der Angriff auf DigiNotar und seine Folgen
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Alternativen zum SSL-CA-Zertifizierungssystem
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Das RAT, das aus dem Stuxnet kam
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Neues zu SSL und Duqu
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Apple geg. Kaspersky, Angreifer geg. PHP, Irgendwer geg. den Iran, und mehr
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Flame und die Windows-Updates
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : SSL - Der nächste Nagel im Sarg?
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Code Signing - Auch Schadsoftware kann signiert sein
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Kommentare zu Webcam-Spannern, EMET 4.0 und einer neuen 0-Day-Schwachstelle
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Einige Angriffe auf CAs im Überblick
Vorschau anzeigen