Gute Zahlen, schlechte Zahlen

Inhaltsverzeichnis

Durch den seit September 2006 annähernd funktionslosen Zufallszahlengenerator der Debian-Variante von OpenSSL kommt es zu verschiedenen direkten und indirekten Problemen im Zusammenhang mit kryptographisch abgesicherter Kommunikation. Die Folgen treffen dabei nicht nur Debian-Anwender, sondern indirekt auch Benutzer anderer Systeme, die mit einem Debian-System verschlüsselt kommunizieren oder schwache Debian-Schlüssel verwenden. Auch wer kein Debian-System benutzt, kann von dem Problem betroffen sein.

Gute Zufallszahlen sind das Fundament vieler kryptographischer Verfahren und Protokolle. Es ist wichtig, dass die verwendeten Zufallszahlen nicht vorhersagbar sind. Solche Zufallszahlen zu erzeugen, fällt Computern naturgemäß schwer. Da die Qualität der Zufallszahlen von Betriebssystem zu Betriebssystem stark variieren kann, setzt das auf vielen Plattformen verfügbare OpenSSL auf eine eigene Funktion zur Erzeugung von Zufallszahlen aus einem internen Entropie-Pool. Diesem Pool fügt OpenSSL über die interne Funktion ssleay_rand_add() in der Datei crypto/rand/md_rand.c Daten aus verschiedenen Quellen hinzu.

Dabei gehen im Fall von Linux unter anderem die Uhrzeit, die aktuelle Prozess-ID, die User-ID des Benutzers, nicht initialisierter Speicher und vor allem Daten aus dem Unix-Device /dev/urandom ein. OpenSSL merkt sich bei jeder Auffüllung des Entropie-Pools in einer internen Variablen, wieviel zusätzliche Entropie hinzugefügt wurde. Im Gegenzug wird diese Variable um den entsprechenden Wert verringert, sobald OpenSSL Entropie aus dem Pool einverwendet, um Zufallszahlen zu erzeugen.

Zu gut gemeint

In der Absicht, Warnmeldungen von Memory-Debuggern wie Valgrind oder Purify zu verhindern, legte der Eingriff des Debian-Maintainers Kurt Roeckx ausgerechnet die zentrale Instruktion in der Funktion ssleay_rand_add() lahm, die neue Daten in den Entropie-Pool von OpenSSL übernehmen soll. Seine Änderung führte dazu, dass die Funktion die übergebenen Daten schlichtweg ignorierte.

Die OpenSSL-Funktion ssleay_rand_bytes(), deren Aufgabe es ist, eine vom Aufrufer spezifizierte Menge von Zufallszahlen zu erzeugen, verwendete den so vorbereiteten – und in der Debian-Variante völlig leeren – Entropie-Pool, um einen Pseudozufallszahlengenerator (PRNG) mit einem Startwert zu initialisieren. Dabei fügte die Funktion noch einmal selbst die aktuelle Prozess-ID hinzu, die bei einem normalen Linux-System 2^15 mögliche Werte annehmen kann. Somit kamen insgesamt nur 32767 verschiedene Zahlenfolgen zum Einsatz.

Kryptographisch starke Zufallszahlen haben einen ähnlich großen Stellenwert wie die Algorithmen, die sie verwenden. Die Tragweite des Problems wird deutlich, wenn man sich vergegenwärtigt, wo überall sichere Zufallszahlen benötigt werden und welche Auswirkungen es hat, falls sie leicht zu erraten sind. Grundsätzlich gehört nun jede Anwendung auf den Prüfstand, die Zufallszahlen aus dem OpenSSL-Zufallszahlengenerator benutzt. Dazu gehören OpenSSH, OpenVPN und eine Reihe von weiteren Applikationen, die gegen die OpenSSL-Bibliotheken gelinkt sind, nicht aber beispielsweise GPG, das seine eigenen Crypto-Funktionen mitbringt. Die schwachen Zufallszahlen wirken sich je nach OpenSSL-Funktion unterschiedlich aus. Zwar sind konkrete Informationen für einzelne Anwendungen zusammen mit entsprechenden Handlungsanweisungen im OpenSSL-Wegweiser von Heise Security sowie im Debian-Wiki beschrieben, doch die folgende Übersicht soll beim Verständnis der Zusammenhänge helfen, um das persönliche Risiko bewerten zu können.

Asymmetrische und symmetrische Schlüssel

Asymmetrische Schlüssel

OpenSSL verwendet zur Erzeugung der asymmetrischen RSA-, DSA- oder ECC-Schlüssel die eigene Funktion zur Erzeugung von Zufallszahlen. Somit sind zunächst einmal alle von einer defekten OpenSSL-Version erzeugten Schlüsselpaare schwach und leicht zu brechen – ein Angreifer kann mit wenig Aufwand komplette Listen aller möglichen Schlüsselpaare erzeugen und gegen ihm bekannte öffentliche Schlüssel abgleichen. Die vom Debian-Projekt und Metasploit veröffentlichten OpenSSH- und OpenSSL-Blacklists wurden auf diese Weise erzeugt. Sie enthalten die Hashes aller so berechneten Public Keys, die relativ einfach gegen einen zu testenden Public Key geprüft werden können.

Für jeden Satz von Schlüsselerzeugungsparametern (also bei RSA die Schlüssellänge und der öffentliche Exponent) muss jedoch eine eigene Liste erstellt werden. OpenSSH verwendet zwar ebenfalls die OpenSSL-Bibliothek, benutzt jedoch einen anderen öffentlichen Exponenten (35) als OpenSSL in der Standardeinstellung für RSA-Schlüssel (65537) verwendet. Daher taugen die OpenSSH-Blacklists nicht für die Prüfung von mit OpenSSL erzeugten RSA-Schlüsseln.

Symmetrische Schlüssel

Symmetrische Verfahren werden in der Regel nicht alleinstehend eingesetzt, weil das Schlüsselmanagement bei diesen Algorithmen schwer in den Griff zu bekommen ist. Stattdessen werden symmetrische Algorithmen zumeist als Baustein zusammen mit anderen kryptographischen Verfahren eingesetzt und spielen zum Beispiel in Hybridverfahren eine große Rolle zur Verschlüsselung der eigentlichen Sitzungsdaten.

Auch bei der Erzeugung von symmetrischen Schlüsseln spielen Zufallszahlen eine Rolle. In Hybridverfahren erzeugt ein Kommunikationspartner einen zufälligen symmetrischen Schlüssel, den er mit dem öffentlichen Schlüssel des Partners verschlüsselt und zusammen mit den zu schützenden Daten verschickt. Der Empfänger kann mit seinem privaten Schlüssel den symmetrischen Schlüssel entschlüsseln. So funktionieren beispielsweise S/MIME und PGP. Eine weitere Möglichkeit zur Festlegung eines symmetrischen Schlüssels ist ein Schlüsselaustauschverfahren wie Diffie-Hellman (DH), das insbesondere bei Online-Protokollen Verwendung findet.

Diffie-Hellman-Verfahren

Diffie-Hellman-Schlüsselaustausch

Der Diffie-Hellman-Schlüsselaustausch ist ein kryptographisches Protokoll, mit dem sich zwei Kommunikationspartner durch den Austausch nicht geheimer Informationen auf ein gemeinsames Geheimnis einigen können, ohne dass dieses über die Leitung geht. Es dient dann als Sitzungsschlüssel für eine symmetrische Verschlüsselung der ausgetauschten Nachrichten.

Da das DH-Protokoll keine Authentisierung der Partner vorsieht, ist es anfällig für Man-In-The-Middle-Angriffe: Ist ein Angreifer in der Lage, sich aktiv in die Kommunikation zwischen den beiden Partnern einzuschleifen, so kann er gegenüber beiden vorgeben, der jeweils andere Partner zu sein und so selbst mit beiden ein gemeinsames Geheimnis vereinbaren. In der Praxis wird DH daher immer zusammen mit einem zusätzlichen Authentisierungsverfahren verwendet, in der Regel auf Basis von digitalen Signaturen.

Eine wichtige Eigenschaft des Protokolls ist, dass es bei korrekter Implementation sogenannte Perfect Forward Secrecy (PFS) erreicht. Das bedeutet, dass ein Angreifer den ausgehandelten Sitzungsschlüssel selbst dann nicht ermitteln kann, wenn er bereits alle anderen an der Kommunikation beteiligten Schlüssel wie die privaten Schlüssel der Kommunikationspartner kompromittiert hat. Einen Mitschnitt einer solchermaßen geschützten Verbindung kann er auch nachträglich nicht entschlüsseln.

Um Perfect Forward Secrecy für Diffie-Hellman zu erreichen, müssen die beiden Kommunikationspartner lediglich die für den DH-Austausch erzeugten Zufallszahlen unmittelbar nach der Einigung auf den Sitzungsschlüssel verwerfen. Kann der Angreifer jedoch mindestens eine der beiden für Diffie-Hellman verwendeten Zufallszahlen erraten, so bricht die Perfect Forward Secrecy zusammen, und der Angreifer kann unmittelbar auf den vereinbarten symmetrischen Schlüssel zurückschließen.

Auf diese Weise lassen sich mitgelesene Sitzungen nachträglich entschlüsseln. Es ist dabei nicht nötig, die asymmetrischen Schlüssel anzugreifen, da ein direkter Angriff auf den Sitzungsschlüssel möglich ist. Im Fall von OpenSSH gilt dies auch für Verbindungen, bei denen eine Authentisierung nicht mit dem Public Key, sondern mit Benutzername und Passwort erfolgte.

Dass dies in der Praxis funktioniert, zeigt das Skript check_weak_dh_ssh.pl von Alexander Klink, das mitgeschnittene OpenSSH-Sitzungen im PCAP-Format analysiert. Es versucht, anhand der im Handshake ausgehandelten Diffie-Hellman-Parameter durch Proberechnung mit allen unter dem verwundbaren Debian-OpenSSL möglichen Zufallszahlen auf den im Handshake gesendeten Wert zu kommen und gibt im Falle eines Treffers aus, welche Clients mit schlechten Zufallszahlen gearbeitet haben. Das Skript kann zur Zeit keine Server erkennen, die mit schlechten Zufallszahlen arbeiten, da Server pro PID und Verbindungsanzahl eine Zufallszahl generieren und das Skript mehr vorberechnete Daten benötigen würde.

Digitale Signaturen und Zertifikate

DSA- und ECDSA-Signaturen

Digitale Signaturen nach dem DSA-Verfahren (Digital Signature Algorithm) und dem ECDSA-Verfahren (Elliptic Curve Digital Signature Algorithm) benötigen neben dem eigentlichen Signaturschlüssel bei jeder Signaturerzeugung noch eine vom Signaturersteller geheimzuhaltene Zufallszahl. Kennt ein Angreifer diese Zufallszahl, so kann er anhand der Signatur auf den verwendeten DSA- oder ECC-Key schließen.

Diese Eigenschaft ist der Grund dafür, dass auch eigentlich sichere DSA-Schlüssel als kompromittiert gelten müssen, wenn sie von einem unsicheren Debian-System als Client zur DSA-Public-Key-Authentisierung benutzt wurden. Existiert beispielsweise ein Mitschnitt einer solchen SSH-Session, lässt sich aus dieser nachträglich der geheime DSA-Schlüssel rekonstruieren.

X.509-Zertifikate

Da OpenSSH bei der Schlüsselerzeugung einen öffentlichen Exponenten von 35 benutzt, das OpenSSL-Kommando zur RSA-Schlüsselerzeugung jedoch den Exponent 65537 verwendet, kann das von Debian veröffentlichte Testprogramm dowkd.pl keine X.509-Schlüssel prüfen. Das für Ubuntu Linux verfügbare Packet openssl-blacklist enthält jedoch zusätzliche Blacklists, mit denen auch der Test von OpenSSL-Schlüsseln möglich ist. Inzwischen ist es auch als Debian-Backport erhältlich.

Dabei gilt grundsätzlich das gleiche wie bei OpenSSH: mit einem verwundbaren Debian erzeugtes Schlüsselmaterial ist schwach und sollte als gebrochen gelten. Ausstellende CAs sollten betroffene Zertifikate umgehend sperren und neu ausgestellen. Alle TLS/SSL-geschützten Server – etwa Webserver und Server, die wie SMTPS-fähige MTAs und Mailserver mit POP3S oder IMAPS das Protokoll-Kommando STARTTLS verwenden, sollten auf verwundbares Schlüsselmaterial überprüft werden.

Auf unsicheren Schlüsseln basierende Webserver-Zertifikate dürfte es in größerer Zahl geben – erste Stichproben ergaben bei einigen im Internet erreichbaren Webservern schwache Schlüssel. Angreifer können den privaten Schlüssel von solchen Webservern erraten und mit ihm beispielsweise eigene Server mit dessen Zertifikat ausstatten. Auch ist es recht einfach möglich, die mit TLS/SSL verschlüsselte Kommunikation mit dem Originalserver abzuhören: Das Analysetool Wireshark kann SSL-Kommunikation entschlüsseln, wenn man ihm den privaten Schlüssel gibt.

Insbesondere für Phishing und Pharming sind Originalzertifikate eines Webservers zusammen mit den passenden privaten Schlüsseln Gold wert. Gelänge es einem Phisher, seine Opfer beispielsweise mittels des sogenannten Pharmings per DNS-Spoofing oder untergeschobene Hosts-Einträge auf seine eigene Seite zu dirigieren, so könnte der Anwender den Angriff nicht mehr erkennen. Sein Browser würde anzeigen, dass das Sicherheitszertifikat des Servers zur eingegebenen URI passt und dass es von einer vertrauenswürdigen CA ausgestellt wurde.

Hier sind auch in der Zukunft durchaus noch Probleme zu erwarten, weil das Thema der Zertifikatssperrung von den aktuellen Browsern derzeit eher stiefmütterlich behandelt wird. In ihrer Standardeinstellung prüfen viele Browser den Gültigkeitsstatus von Server-Zertifikaten nicht, sodass sie nicht erkennen, wenn eine CA ein Zertifikat in ihrer Certification Revocation List (CRL) widerrufen hat. Wer auf Nummer Sicher gehen möchte, sollte das Prüfen von CRLs in den Browser-Einstellungen aktivieren.

Ein Angreifer kann daher ein gesperrtes Zertifikat bis zum Ende seiner vorgesehenen Gültigkeitsdauer verwenden; die meisten Browser würden es klaglos akzeptieren. Die Prüfung von Sperrinformationen per OCSP (Online Certificate Status Protocol) durch die Browser könnte künftig Abhilfe schaffen. Die meisten Browser beherrschen inzwischen zwar OCSP, die Funktion ist aber in der Regel standardmäßig deaktiviert. Außerdem unterstützen nicht alle CAs das Protokoll.

Die Wurzel

Der schlimmste Fall wäre eine Certificate Authority (CA), die verwundbare Zertifikate eingesetzt hat, um Zertifikate zu signieren. Alle von Microsoft und Firefox mitgelieferten CA-Zertifikate mit 1024 oder 2048 Bit Länge und einem öffentlichen Exponenten von 65537 stellten sich in einem ersten Test als nicht verwundbar heraus, sodass die großen, öffentlichen CAs nicht mit unmittelbaren Problemen zu rechnen haben. Probleme könnte es jedoch für Firmen und Organisationen geben, die eigene PKIs auf einem verwundbaren Debian Linux mit OpenSSL aufgesetzt haben – die Betreiber könnten möglicherweise gezwungen sein ihre komplette PKI neu aufzusetzen.

Browser und Server

Zwischen Browser und Server

Die Absicherung von https-Verbindungen erfolgt via Secure Socket Layer (SSL) beziehungsweise dessen Nachfolger Transport Layer Security (TLS). Sie bauen auf einem Hybridverfahren auf, in dem Client und Server zunächst ein Schlüsselaustauschverfahren vereinbaren. Client und Server gleichen damit ab, welche Methoden sie für Authentisierung, Schlüsselaustausch und symmetrische Verschlüsselung der Sitzung beherrschen.

Dabei stehen Diffie-Hellman sowie ein Austausch eines zufälligen symmetrischen Schlüssels über RSA zur Verfügung. Mit dem Schlüsselaustauschverfahren handeln Client und Server ein gemeinsames "Master Secret" aus, aus dem sie den Sitzungsschlüssel für die TLS-Verbindung ableiten. Einigen sich die Kommunikationspartner auf RSA zum Schlüsselaustausch, berechnet der Client das Master Secret. Ist er von dem Debian-Bug betroffen, ist die Verbindung ebenfalls unsicher.

Ob eine aufgezeichnete https-Sitzung verwundbar ist, lässt sich nicht ohne weiteres sagen, weil es von den ausgehandelten Verschlüsselungsparametern abhängt. Firefox und Mozilla verwenden eigene Crypto-Biliotheken, sind daher auch auf Debian-Systemen kein Risikofaktor. Somit bleiben im Wesentlichen Verbindungen zu Web-Servern, die eine verwundbare OpenSSL-Bibliothek einsetzen und Diffie-Hellman verwenden. Analoges gilt für andere Applikationen, die SSL/TLS für die Verschlüsselung beziehungsweise Authentifizierung einsetzen.

Beim Austausch von S/MIME-gesicherter Mail kommen ebenfalls X.509-Zertifikate zum Einsatz. Sie sind in einer CMS-Struktur (Cryptographic Message Syntax, RFC 3852, basierend auf PKCS#7 1.5) in die E-Mail eingebettet. Grundsätzlich kann ein Angreifer ein auf schwachem Schlüsselmaterial basierendes S/MIME-Zertifikat missbrauchen, um im Namen des Inhabers digitale Signaturen zu erzeugen oder an den Inhaber gerichtete verschlüsselte Nachrichten zu lesen.

Auch die S/MIME-Verschlüsselung ist ein Hybridverfahren. Der Absender erzeugt einen zufälligen symmetrischen Schlüssel und verschlüsselt damit die Nachricht. Den symmetrischen Schlüssel verschlüsselt er mit dem öffentlichen Schlüssel des Empfängers; das Ergebnis packt er ebenfalls in die CMS-Struktur. Führt er diese Verschlüsselungsoperation auf einem verwundbaren Debian-System aus, so ist die verschlüsselte Nachricht selbst dann für einen Angreifer lesbar, wenn die eingesetzten X.509-Zertifikate auf sicheren Schlüsseln basieren. Allerdings verwenden sowohl Thunderbird als auch Evolution die nicht betroffenen Network Security Services (NSS) von Mozilla.

Fazit

Die bange Frage: wer wusste davon?

In das Reich der Spekulationen gehören Überlegungen darüber, ob – und wenn ja wem – dieses Problem schon vorher bekannt war. Immerhin hatten mögliche Angreifer mehr als eineinhalb Jahre Zeit, das Problem zu erkennen und auszunutzen. Dass ein solcher gravierender Fehler seit September 2006 unbemerkt blieb, bis ihn Luciano Bello im Mai 2008 entdeckte und meldete, ist aus mehreren Gründen unwahrscheinlich.

Man mag vermuten, dass nicht nur Sicherheitsexperten und "Black Hats" zu den aufmerksamen Lesern der Changelogs in den Versionskontrollsystemen von kryptographischer Software und Distributoren gehören, sondern insbesondere auch entsprechende Spezialisten im Dienste von Geheimdienstorganisationen, zu deren Aufgaben das Abhören und Sammeln aller möglicher Daten gehört.

Es ist aber in diesem Fall nicht einmal wirklich nötig, die Brisanz der Änderung am OpenSSL-Zufallszahlengenerator anhand des eher unauffällig aussehenden Patches zu erkennen – gut organisierten Angreifern kommt in diesem Fall die Statistik zu Hilfe: Als ziemlich wahrscheinlich dürfte gelten, dass Nachrichtendienste und ähnliche Organisationen nicht nur abgehörte Verbindungen archivieren, sondern auch Datenbanken mit den öffentlichen Schlüsseln pflegen. Die dazu benötigten Daten liegen dabei gewissermaßen auf der Straße – Webserver, VPN-Endpunkte oder SSH-geschützte Server geben bestimmungsgemäß und bereitwillig jedem Anfragenden ihren öffentlichen Schlüssel preis, damit dieser die Authentizität des Servers prüfen kann.

Wer immer sich in den vergangenen 20 Monaten die Mühe gemacht hat, eine Datenbank mit solchermaßen gesammelten öffentlichen Schlüsseln zu pflegen, konnte vermutlich ungefähr ab Oktober 2006 die erstaunliche Beobachtung machen, dass in dieser Datenbank Kollisionen auftreten, wo eigentlich keine passieren dürften. Aufgrund des Geburtstagsparadoxons genügen schon 500 schwache Schlüssel gleicher Länge, um unter ihnen mit rund 95-prozentiger Wahrscheinlichkeit ein Duplikat zu finden. Vom Entdecken eines solchen Duplikats ist es nur noch ein kleiner Schritt, um über den ungefähren Zeitpunkt und den Kontext der betroffenen Schlüssel auf das Debian-Betriebssystem zurückzuschließen und die in dem Zeitraum vorgenommenen Änderungen am Quellcode der kryptographisch relevanten Programmpakete zu untersuchen.

Quo vadis?

Das Debian-Debakel wirft ein schlechtes Licht auf das Open-Source-Entwicklungsmodell. Das offensichtliche Fehlen von wirksamen Qualitätssicherungsmechanismen bei der Pflege von sicherheitskritischen Programmpaketen bei Debian Linux wird es Verfechtern von Open-Source-Software nicht unbedingt leichter machen, diese im professionellen Umfeld einzusetzen. Andererseits wird auch deutlich, dass Source-Code-Review als Mittel zur Identifikation von Sicherheitsproblemen bei Open Source durchaus funktioniert – wenn auch, wie in diesem Fall, nicht immer ganz zeitnah.

Kritiker von Open-Source-Software werden diesen Ball gern aufnehmen und als Munition für das Closed-Source-Modell verwenden. Es bleibt letztlich aber das Gegenargument bestehen, dass im Fall von proprietärer Software ähnliche Probleme möglicherweise völlig unerkannt bleiben, weil deren Quellcode nicht für für Analysen einsehbar ist. (cr)