Einige Angriffe auf CAs im Überblick
Das größte Problem bei der Sicherheit von SSL/TLS allgemein und HTTPS im besonderen ist und bleibt das bestehende Zertifizierungssystem. Es gibt einfach zu viele CAs, denen die Browser und Betriebssysteme ab Werk vertrauen. Stellt eine dieser CAs Zertifikate aus, ohne dazu autorisiert zu sein, so werden die vom Browser natürlich als gültig akzeptiert. So ein "echtes" Zertifikat macht einem MitM-Angriff natürlich sehr viel leichter. Und dabei muss diese CA gar nicht mal böswillig handelt, es reicht wenn sie erfolgreich angegriffen wird oder unsauber arbeitet.
Einige Beispiele für Angriffe auf CAs sowie unsauber arbeitende CAs hatte ich bereits hier im Blog:
2011: Das Zertifizierungssystem wird zum brennenden Kartenhaus
Besonders schlimm war es 2011:
- Anfang 2011 wurde die CA Comodo
erfolgreich angegriffen,
der Angreifer konnte sich Zertifikate für eine Reihe hochrangiger
Domains wie zum Beispiel
login.live.com
,mail.google.com
,login.yahoo.com
oderlogin.skype.com
ausstellen lassen. Der Angriff war erfolgreich, weil bei Comodo niemand damit gerechnet hat, dass die für die Prüfung von Anträgen zuständigen Registration Authorities angegriffen werden könnten.
- Im Sommer 2011 wurden von der CA DigiNotar unberechtigt sowohl
normale SSL-Zertifikate als auch "Extended Validation SSL"-Zertifikate
(EVSSL)
ausgestellt,
unter anderem für Google-Domains. Was der CA
nicht gut bekam.
Zumal sie widersprüchliche Gründe für die Ausstellung der Zertifikate
lieferte und versuchte, den Vorfall zu vertuschen. Und das, obwohl
mindestens 531 Zertifikate
ausgestellt wurden.
- Im Oktober 2011 wurde bekannt, dass weitere CAs
kompromittiert wurden.
- Im November 2011 stellte die CA KPN Corporate Market die Ausgabe
von SSL-Zertifikaten auf unbestimmte Zeit
ein.
Sicherheitshalber, da auf einem Webserver des Unternehmens ein Tool
zum Durchführen von DDoS-Angriffen gefunden wurde. Man wollte sicher
gehen, dass die CA nicht kompromittiert wurde, bevor man wieder
Zertifikate ausstelle. Wobei mir gerade auffällt, dass man vom Ausgang
der Prüfungen gar nichts gehört hat.
- Ebenfalls im November 2011 wurde der CA "Digicert Sdn. Bhd. (Digicert Malaysia)" von Microsoft und Mozilla das Vertrauen entzogen. Die CA hatte 22 Zertifikate mit schwachem RAS-Schlüssel (mit einer Schlüssellänge von nur 512 Bit) und fehlenden Zertifikatserweiterungen und Rückrufinformationen ausgestellt und damit gegen etliche Regeln verstoßen.
2012: Eine CA stellt ein MitM-Zertifikat aus
2012 wurde es nicht wirklich besser, denn die CA Trustwave musste ein "MitM-Zertifikat" zurückrufen, mit dem der Inhaber selbst Zertifikate für beliebige Domains ausstellen konnte. Das Zertifikat wurde für einen "internal corporate network customer" ausgestellt, der damit in einem Data Loss Prevention System (DLP) den SSL-geschützten Netzwerkverkehr als Man-in-the-Middle beobachten wollte. Was einen Missbrauch natürlich nicht ausschließt. Genau so wäre es möglich gewesen, dass der private Schlüssel des Zertifikats unbemerkt ausgespäht wird. Denn der wird sicher nicht so gut geschützt wie die privaten Schlüssel der CAs.
2015: Ein falsches Zertifikat, aber das streng nach Vorschrift!
Dann war es etwas ruhiger um die CAs, zumindest hier im Blog. Die nächsten Fälle waren entweder nicht wirklich interessant, oder es gab wichtigeres zu berichten oder zu kommentieren. Viel schlimmer als 2011 und 2012 konnte es ja auch gar nicht werden.
Interessant wurde es wieder im April vergangenen Jahres. Da hat mal wieder eine CA falsch gespielt, was ich aber damals nur der Vollständigkeit halber erwähnt habe und es auch nur deshalb hier erwähne.
Wichtiger war ein von einer anderen CA unberechtigt ausgestelltes
Zertifikat, bei dessen Ausstellung alle Regeln eingehalten wurden. Sie
denken, das geht nicht? Doch, tut es: Ein Finne hat sich von der CA Comodo
erfolgreich ein Zertifikat für Microsofts Domain live.fi
ausstellen lassen.
Das war ganz einfach. Vor der Ausstellung eines Zertifikats muss die CA
prüfen, ob der Antragsteller überhaupt dazu berechtigt ist, es zu
beantragen. Eine Möglichkeit, dass zu tun, besteht darin, eine E-Mail mit
einem Verifizierungscode an eine E-Mail-Adresse zu schicken, die unter der
Kontrolle des Domaininhabers steht, zum Beispiel postmaster@
oder root@
.
Comodo akzeptiert unter anderem auch hostmaster@
, und der
Finne konnte beim Freemailer live.fi
die Adresse
hostmaster@live.fi
registrieren. Danach hat er testweise
versucht, ein Zertifikat zu erhalten. Erfolgreich. Für die Folgen und
Schlussfolgerungen siehe den verlinkten Blog-Eintrag.
Trackbacks
Dipl.-Inform. Carsten Eilers am : Drucksache: IT Administrator 1.16 - MitM-Angriffe auf HTTPS
Vorschau anzeigen