Skip to content

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 oder login.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.

Carsten Eilers

Trackbacks

Dipl.-Inform. Carsten Eilers am : Drucksache: IT Administrator 1.16 - MitM-Angriffe auf HTTPS

Vorschau anzeigen
Im IT-Administrator Januar 2016 ist ein Artikel über Angriffe auf HTTPS-Verbindungen erschienen. HTTPS schützt eine Verbindung sowohl vor dem Abhören als auch vor Manipulationen. Aber nur, wenn sich der Angreifer nicht in die