Fehler mit Folgen: Debian-Bug hinterlässt verwundbare Schlüssel

Vor circa zehn Jahren wurde ein Fehler entdeckt, der den OpenSSL Zufallszahlengenerator beziehungsweise die damit kreierten privaten Schlüssel unbrauchbar gemacht hat. Der als Debian-Bug bezeichnete Fehler ist damit wohl eine der gravierendsten Sicherheitslücken in der Geschichte der Kryptographie. Selbst nach so langer Zeit sind noch heute die Folgen durch verwundbare Schlüssel sichtbar.

Der Sicherheits-Super-GAU im Debian-Projekt

Am Anfang stand ein Problem: Der originale OpenSSL-Code nutzte für den Zufallszahlengenerator uninitialisierten Speicher. Die Debian-Entwickler störten sich jedoch daran, dass das Debugging-Tool Valgrind dazu die Warnung ausgab, dass auf nicht initialisierte Variablen lesend zugegriffen wurde. Dieses Problem sollte mittels Patch ausgeschaltet werden, der den Quellcode an zwei Stellen änderte.

Und hier passierte ein gravierender Fehler: Der Zufallszahlengenerator wurde de facto außer Betrieb gesetzt. Erst zwei Jahre später, am 13. Mai 2008 entdeckte der Sicherheitsexperte Luciano Bello nämlich, dass nur wenige Daten in den internen Status des Zufallszahlengenerators gelangten. Die einzige Quelle zur Generierung von Zufallszahlen war die Prozess-ID der jeweils laufenden Softwareinstanz – und unter Linux kann die Prozess-ID Werte zwischen 1 und 32.768 annehmen.

Die größten Auswirkungen hatte dieser Fehler auf die Erzeugung von kryptographischen Schlüsseln. Er führte nämlich dazu, dass seit Einspielung des Patches vom 19. September 2006 gerade einmal 32.768 unterschiedliche Krypto-Schlüssel erzeugt wurden. Die erste betroffene Version war 0.9.8c-1, die am 17. September 2006 in den Unstable-Zweig der Distribution gelangte.

Konsequenzen des Debian-Bug

Die Beschränkung bei der Schlüsselerzeugung öffnete Tür und Tor für Brute-Force-Attacken – vor allem gegen SSH-Server. Dabei war es war völlig gleich, welche Linux-Distribution auf dem Server lief: Verwendete ein Nutzer einen seit 2006 mit OpenSSL, OpenSSH und zahlreichen anderen kryptografischen Tools unter Debian erzeugten schwachen Schlüssel zur Authentifizierung, konnte er ganz einfach geknackt werden. Angreifer mussten dafür lediglich alle möglichen Schlüsselvarianten erzeugen, um in den Besitz des privaten Schlüssels zu kommen. Jeder, der zwischen 2006 und 2008 einen SSH-Key auf seinem SSH-Server angelegt hatte, musste diesen nun überprüfen, unsichere sperren und einen neuen Schlüssel erstellen.

Anders ausgedrückt: Alle Server, die unter Debian oder einem Derivat generierte SSL-Zertifikate verwendeten, verwundbar – unabhängig vom Betriebssystem des Servers. Das führte soweit, dass sogar Microsoft-Windows-Server durch ein fehlerhaftes Zertifikat betroffen sein konnten. Nur mit Sicherheitsupdates und der Installation neuer SSL-Zertifikate konnte dem entgegengewirkt werden.

Allerdings war auch das nicht das Ende der Fahnenstange, denn die mit OpenSSL erzeugten Schlüssel wurden von vielen Software-Entwicklern auch zur Autorisierung auf Online-Code-Repositories genutzt. Dabei handelt es sich um freie Software, mit deren Hilfe Entwickler lokal eine vollständig kontrollierbare Infrastruktur aufbauen können. Damit wurden nun auch diese anfällig, ganz unabhängig davon, ob es sich um eine Debian-basierte Distribution handelte oder nicht. Infolgedessen wurden SSH-Zugänge von Benutzern einer Debian-basierten Distribution mal eben abgeschaltet. Was wie eine drastische Maßnahme klingt, war keinesfalls so überzogen: Denn binnen kürzester Zeit hatte die Cracker-Szene alle möglichen Schlüssel berechnet und damit DIE Quelle für diverse Server-Einbrüche gefunden.

Auswirkungen bis heute: Noch immer sind verwundbare Schlüssel im Einsatz

Obwohl Debian und Ubuntu rasch Updates für OpenSSL auslieferten, war die Lage alles andere als unter Kontrolle. Denn mit dem Update wurde nur die Erstellung neuer Kypto-Schlüssel gesichert. Alle zuvor erzeugten Schlüssel blieben weiterhin angreifbar. So sind auch heute noch vereinzelt verwundbare private Schlüssel zu finden.

Github Repositories bedroht

Im Jahr 2015 war es dem Programmierer Ben Cox möglich, bei GitHub zahlreiche öffentliche SSH-Schlüssel von Entwicklern, die mit alten Debian-Systemen erstellt worden waren, ausfindig zu machen. GitHub ist ein Onlinedienst, der Software-Entwicklungsprojekte auf seinen Servern bereitstellt. Der Dienst erlaubt es Anwendern, Änderungen in ihren Quelltext-Datenbanken, den Repositories, mit Hilfe von SSH-Schlüsseln zu autorisieren. Grundsätzlich macht eine solche Authentifizierung mit Public-Key-Infrastruktur auch Sinn, denn sie ist sicherer als die Verwendung reiner Passwörter.

Allerdings lassen sich – aufgrund des Debian-Bugs – die verwendeten Schlüssel ganz einfach auslesen. Mit einigen dieser Schlüssel hätte sich Ben Cox damit leicht Zugriff zu prominenten Repositories verschaffen und diese manipulieren können, darunter das von Python, der Python-Webentwicklungsumgebung Django und von einigen großen Firmen wie Spotify, Yandex und Couchbase.

SSL-Zertifikate mit verwundbarem Schlüssel ausgestellt

Eigentlich sollte es bei TLS-Zertifikaten für Webseiten nicht möglich sein, verwundbare Schlüssel zu verwenden. Alle Zertifikate, die damals gültig waren, sind inzwischen längst abgelaufen. Zudem sehen die Baseline Requirements, ein Regelwerk, auf das sich Zertifizierungsstellen und Browserhersteller geeinigt haben, vor, dass bei der Zertifikatsausstellung geprüft wird, ob ein bekannter kompromittierter Schlüssel verwendet wird. Der Debian-OpenSSL-Bug wird dabei explizit als Beispiel erwähnt.

Dennoch tauchen immer noch Zertifikate auf, die von dem Bug betroffen sind. 2017 gelang es dem IT-Journalist Hanno Böck ein Zertifikat mit verwundbarem Schlüssel bei Let´s Encrypt zu erstellen. Obwohl Böck dies gemeldet hatte, wurde das Zertifikat nicht widerrufen. Erst nachdem die Zertifizierungsstelle angeschrieben wurde, tat sich etwas: Inzwischen hat Let´s Encrypt einen Check eingebaut, der die Ausstellung solcher Zertifikate verhindert. Böck suchte weiter und fand in den Daten der Certificate-Transparency-Logs zwei von Certum ausgestellte Zertifikate, deren Schlüssel mit einem verwundbaren Debian-System erzeugt wurden. Zudem enthielten zwei Zertifikate von Startcom, eins von QuoVadis sowie eins von Wosign verwundbare, private Schlüssel.

Fazit des Debian-Bugs: Alte Bugs sterben nie

Wenngleich Browserhersteller den Zertifizierungsstellen Wosign und Startcom inzwischen das Vertrauen entzogen haben (wir haben berichtet), finden sich offensichtlich immer noch andere CAs, die Zertifikate mit verwundbarem Schlüsseln ausgeben. Damit zeigt sich, dass alte Bugs offenbar nie sterben. Zertifizierungsstellen sind deshalb angehalten, bei der Zertifikatsausstellung noch besser auf die Debian-Schwachstelle zu prüfen.