Thought Leadership
Sie denken, Internetverbindungen mit digitalen Zertifikaten sind sicher? Und Sie können daher unbekümmert darüber vertrauliche Daten übermitteln? Auch kriminelle Zeitgenossen wissen um diese gefühlte Sicherheit und haben inzwischen ein reichhaltiges Repertoire entwickelt, um mittels gefälschten und trickreichen Zertifikaten in den Besitz von wertvollen Daten kommen zu können. Willkommen in der Wirklichkeit!
Grundlage von X.509, das erstmals 1988 vorgestellt wurde, ist ein hierarchisches System vertrauenswürdiger Zertifizierungsstellen. Diese stellen elektronische Zertifikate für die nächst niedrigere Ebene aus. Das für die verschlüsselte Kommunikation im Internet wichtigste Profil von X.509 ist die Public-Key-Infrastructure (PKI), welche die Internet Engineering Task Force im Jahr 2002 erstmals standardisierte.
Die Sicherheitshierarchie nach X.509
Um eine Nachricht zu verifizieren oder zu entschlüsseln, benötigt der Empfänger den öffentlichen Schlüssel des Senders. Zertifikate geben dem Empfänger vor, dass sie die Echtheit des öffentlichen Schlüssels bestätigen. Dabei setzen sie voraus, dass die Prozesse der Schlüsselerzeugung eingehalten wurden, dass der private Schlüssel nicht kompromittiert ist und dass der Empfänger der höchsten Zertifizierungsstelle des Senders vertraut. Darüber hinaus geben sie Auskunft über den zulässigen Anwendungsbereich.
Entscheidend ist das Vertrauen in die Echtheit des höchsten Zertifikates und des dadurch zertifizierten Schlüssels. Die ausstellende Zertifizierungsstelle einer niedrigeren Ebene unterschreibt ihr Zertifikat mit ihrem privaten Schlüssel, dessen Echtheit mit ihrem öffentlichen Schlüssel überprüft wird. Dass dieser Schlüssel wiederum echt ist, belegt ein übergeordnetes Zertifikat. Dieses ist mit dem privaten Schlüssel der nächst höheren Stelle unterschrieben und kann mit dem verfügbaren öffentlichen verifiziert werden. So entsteht ein Zertifizierungspfad, auch Vertrauenskette (chain of trust) genannt, der mehrere Zertifikatebenen umfasst, die jeweils die Echtheit eines öffentlichen Schlüssels bestätigen, der für die Prüfung des vorhergehenden Zertifikats benötigt wird.
Die Schwachstellen in der Praxis
Fehlende Information und daraus resultierendes unachtsames Verhalten der Anwender stellen sicher eine der größten IT-Sicherheitslücken dar. Verschärft wird dies durch nachlässig umgesetzte Prozesse sowie Softwarefehler.
Auf problematische Prozesse bei der Ausstellung von Zertifikaten hat der US-Forscher Moxie Marlinspike im Rahmen der Black Hat Conference 2009 in Las Vegas aufmerksam gemacht. Eine Möglichkeit, sich selbst ein Zertifikat für www.opfer-domain.de auszustellen ist, dieses mit einem eigenen gültigen Zertifikat zu unterschreiben, das eigentlich gar nicht für diesen Zweck genutzt werden dürfte (siehe Bild 1). Ob alle zwischenliegenden Zertifikate einer gültigen Zertifizierungsstelle gehören, wird aber oftmals nicht geprüft. Der Grund für diese Programmierfehler ist, dass Teile des X.509-Standards zwischenzeitlich „verloren“ und später „wiedergefunden“ wurden, sodass manches wichtige Detail den Entwicklern schlicht entgangen ist.
Bild 1: Für einige SSL-Implementierungen wirkt diese Kette intakt und vertrauenswürdig, da sie nicht überprüfen, ob alle Zertifikate auch zu einer Zertifizierungsstelle gehören. So unterschreibt der Inhaber des Zertifikats www.täter-domain.de das selbst erzeugte Zertifikat www.opfer-domain.de, obwohl das nicht erlaubt ist.
Ein weiterer Ansatzpunkt findet sich in der nunmehr stark automatisierten Ausstellung von Zertifikaten. Bis vor einigen Jahren forderten Zertifizierungsstelle schriftliche Identifikationsnachweise oder nahmen telefonisch Kontakt zu den Antragstellern eines Zertifikats auf. Aufgrund der Nachfrage nach mehr und vor allem kostengünstigeren Zertifikaten bieten die Zertifizierungsstellen nun ein System an, das eine automatisierte Überprüfung durchführt und die Ausstellung der Zertifikate veranlasst. Dieses System nutzt für die Übermittlung des Auftrags den Public Key Cryptography Standard (PKCS) Nummer 10. Der Antragsteller muss dabei unter anderem den Common Name seiner Domain angeben, für die das Zertifikat gültig sein soll. Die Zertifizierungsstelle validiert diesen Common Name, indem sie die Kontaktdaten der Domain abfragt und eine E-Mail an den administrativen und technischen Ansprechpartner schickt (siehe Bild 2).
Bild 2: Bei der Überprüfung des Zertifikatsantrages (CSR) wird von rechts nach links die erste gültige Domain gesucht. Zertifizierungsstellen kontaktieren deshalb den Inhaber von täter-domain.de, ob der Antrag rechtmäßig ist.
Faszinierendes Missverständnis
Ohne den kontrollierenden Blick eines Menschen ist es leichter möglich, ungestört nach Implementierungslücken zu suchen. Was kreative Menschen dabei entdeckt haben, ist wirklich ein faszinierendes Missverständnis. Zertifizierungssysteme sind meist in Programmiersprachen geschrieben, die hohe Prozesssicherheit gewährleisten und Zeichenketten über das Startbit klar begrenzen. Gibt ein Angreifer im Auftrag beispielsweise den Common Name opfer.de\0.täter.de an, fragt das System die Kontaktdaten der höchsten Ebene, also täter-domain.de, ab und kontaktiert den Angreifer per E-Mail. Viele Implementierungen der SSL-Bibliotheken für Anwenderprogramme sind dagegen in der Programmiersprache C geschrieben und benutzen deren Stringfunktion. Diese bieten für einen Entwickler zwar komfortable und erprobte Funktionen, öffnen bei unvorsichtiger Verwendung aber Hintertüren. Dies trifft sowohl für CryptoAPI als auch Network Security Services (NSS) zu. Beide beenden das Lesen von Zeichenketten, wenn sie \0, den Null Terminator, erreichen. Für Clients, die diese APIs nutzen, ist das Zertifikat für opfer-domain.de ausgestellt und gültig (siehe Bild 3)!
Bild 3:Viele SSL-Implementierung in Clients akzeptieren dieses Zertifikat auch für opfer-domain.de, da sie nach dem \0 das Lesen des Common Name beenden.
Mit einer „Wild card“ bei der Zertifizierung von *~.opfer-domain.de\0.täter-domain.de verfügen Fremde über einen Generalschlüssel für opfer-domain.de und können sich damit für jede SSL-Verbindung als beliebiger Rechner innerhalb von opfer-domain.de ausgeben (siehe Bild 3). Wer meint, er könne ungültige Zertifikate mittels Online Certificate Status Protocol (OCSP) identifizieren, kennt den neuesten Trick der Angreifer noch nicht. Anfragen eines Client können mit einer leicht zu fingierenden, weil unsignierten Antwort (OCSP Server-Statusmeldung 3) auf einen späteren Zeitpunkt verschoben werden. Das veranlasst nahezu alle Anwendungen, mit den Angreifer-Zertifikaten weiter zu arbeiten. Verfügt ein Angreifer erst über eine auf diese Weise „gesicherte“ Verbindung, kann er die automatisierten Programmupdates nutzen, um eigene „vertrauenswürdige“ Stammzertifikate und Keylogger auf dem Client zu installieren.
Welche Maßnahmen helfen?
Wichtigste Aufgabe für die IT-Sicherheit des Unternehmens ist die Qualifizierung der Mitarbeiter. Diese müssen für Anzeichen der geschilderten Angriffe sensibilisiert werden. Beispielsweise sollten bei plötzlich fehlender Verschlüsselung oder bei Installationshinweisen für Zertifikate die Alarmglocken schrillen. Zur Bestandsaufnahme sollten IT-Abteilungen beispielsweise die Zertifikatspeicher der Clients hinsichtlich der Gefahr überprüfen, ob dort bereits ein seltsam erscheinendes Stammzertifikat liegt, das von früheren Angriffen stammt und für weit reichende Manipulationen dienen kann. Eine Verabschiedung von der unverschlüsselten Kommunikation und ein standardmäßiges Setzten auf Verschlüsselung ist eine der wichtigsten Maßnahmen. Langfristig müssen sich Unternehmen auch mit der Einführung von DNSSEC befassen.
Dies ist der einzige wirklich zuverlässige Schutz davor, manipulierten DNS Auskünften von Angreifern in die Hände zu fallen. DNSSEC verhindert, dass falsche Domaininformationen in die Clients eingebracht werden können. Damit entfällt eine wesentliche Voraussetzung, um einen Man-in-the-Middle-Angriff über das Internet überhaupt durchführen zu können.
Die Bedeutung von DNSSEC zeigt sich an der Tatsache, dass auch Microsoft den Standard in seiner neuen Betriebssystemfamilie Windows 7 und Microsoft Server 2008 unterstützt. In Deutschland arbeitet die DENIC mit Partnern wie dem Bundesamt für Sicherheit in der Informationstechnologie (BSI) und dem Verband der Internetwirtschaft eco an einer Testumgebung, die alle technischen Aspekte einer Implementierung von DNSSEC für .de untersuchen soll. Auch im Businessnetzwerk Xing gibt es seit kurzem eine Gruppe, in der Anwender und Hersteller Aspekte des Einsatzes von DNSSEC diskutieren.
Bis Mitte 2010 wird die ICANN die Einträge aller Root-Nameserver signieren und so den seit langem geplanten DNSSEC Trust Anchor verwirklichen. Spätestens dann müssen IT-Verantwortliche beispielsweise vorhandene Netzwerkkomponenten auf DNSSECVerträglichkeit prüfen. War die Aktualisierung von Nameserverinformationen bisher ein sehr einfacher Prozess, handelt es sich nun um einen komplexen Vorgang, der eine entsprechende Qualifizierung der verantwortlichen Mitarbeiter voraussetzt. Spezielle Anwendungen automatisieren beispielsweise die Signierung der eigenen Zone und das Key-Management. Doch die Verantwortlichen müssen auch lernen, typische Fehlersituationen zu erkennen und zu beheben. Denn in einer DNSSECgesicherten Umgebung sind fehlerhaft konfigurierte Systeme oder falsche Signaturen die häufigsten Gründe dafür, dass Verbindungen nicht aufgebaut werden können.
Andreas Bäß
[email protected]
