Vor circa zehn Jahren wurde ein Fehler entdeckt, der den OpenSSL Zufallszahlengenerator beziehungsweise die damit kreierten privaten Schl\u00fcssel unbrauchbar gemacht hat. Der als Debian-Bug bezeichnete Fehler ist damit wohl eine der gravierendsten Sicherheitsl\u00fccken in der Geschichte der Kryptographie. Selbst nach so langer Zeit sind noch heute die Folgen durch verwundbare Schl\u00fcssel sichtbar.<\/p>\n
<\/p>\n
Am Anfang stand ein Problem: Der originale OpenSSL-Code nutzte f\u00fcr den Zufallszahlengenerator uninitialisierten Speicher. Die Debian-Entwickler st\u00f6rten 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 \u00e4nderte.<\/p>\n
Und hier passierte ein gravierender Fehler: Der Zufallszahlengenerator wurde de facto au\u00dfer Betrieb gesetzt. Erst zwei Jahre sp\u00e4ter, am 13. Mai 2008 entdeckte der Sicherheitsexperte Luciano Bello n\u00e4mlich, 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 \u2013 und unter Linux kann die Prozess-ID Werte zwischen 1 und 32.768 annehmen.<\/p>\n
Die gr\u00f6\u00dften Auswirkungen hatte dieser Fehler auf die Erzeugung von kryptographischen Schl\u00fcsseln. Er f\u00fchrte n\u00e4mlich dazu, dass seit Einspielung des Patches vom 19. September 2006 gerade einmal 32.768 unterschiedliche Krypto-Schl\u00fcssel erzeugt wurden. Die erste betroffene Version war 0.9.8c-1, die am 17. September 2006 in den Unstable-Zweig der Distribution gelangte.<\/p>\n
Die Beschr\u00e4nkung bei der Schl\u00fcsselerzeugung \u00f6ffnete T\u00fcr und Tor f\u00fcr Brute-Force-Attacken \u2013 vor allem gegen SSH-Server. Dabei war es war v\u00f6llig 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\u00fcssel zur Authentifizierung, konnte er ganz einfach geknackt werden. Angreifer mussten daf\u00fcr lediglich alle m\u00f6glichen Schl\u00fcsselvarianten erzeugen, um in den Besitz des privaten Schl\u00fcssels zu kommen. Jeder, der zwischen 2006 und 2008 einen SSH-Key auf seinem SSH-Server angelegt hatte, musste diesen nun \u00fcberpr\u00fcfen, unsichere sperren und einen neuen Schl\u00fcssel erstellen.<\/p>\n
Anders ausgedr\u00fcckt: Alle Server, die unter Debian oder einem Derivat generierte SSL-Zertifikate verwendeten, verwundbar \u2013 unabh\u00e4ngig vom Betriebssystem des Servers. Das f\u00fchrte 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.<\/p>\n
Allerdings war auch das nicht das Ende der Fahnenstange, denn die mit OpenSSL erzeugten Schl\u00fcssel 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\u00e4ndig kontrollierbare Infrastruktur aufbauen k\u00f6nnen. Damit wurden nun auch diese anf\u00e4llig, ganz unabh\u00e4ngig davon, ob es sich um eine Debian-basierte Distribution handelte oder nicht. Infolgedessen wurden SSH-Zug\u00e4nge von Benutzern einer Debian-basierten Distribution mal eben abgeschaltet. Was wie eine drastische Ma\u00dfnahme klingt, war keinesfalls so \u00fcberzogen: Denn binnen k\u00fcrzester Zeit hatte die Cracker-Szene alle m\u00f6glichen Schl\u00fcssel berechnet und damit DIE Quelle f\u00fcr diverse Server-Einbr\u00fcche gefunden.<\/p>\n
Obwohl Debian und Ubuntu rasch Updates f\u00fcr OpenSSL auslieferten, war die Lage alles andere als unter Kontrolle. Denn mit dem Update wurde nur die Erstellung neuer Kypto-Schl\u00fcssel gesichert. Alle zuvor erzeugten Schl\u00fcssel blieben weiterhin angreifbar. So sind auch heute noch vereinzelt verwundbare private Schl\u00fcssel zu finden.<\/p>\n
Im Jahr 2015 war es dem Programmierer Ben Cox m\u00f6glich, bei GitHub zahlreiche \u00f6ffentliche SSH-Schl\u00fcssel 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, \u00c4nderungen in ihren Quelltext-Datenbanken, den Repositories, mit Hilfe von SSH-Schl\u00fcsseln zu autorisieren. Grunds\u00e4tzlich macht eine solche Authentifizierung mit Public-Key-Infrastruktur auch Sinn, denn sie ist sicherer als die Verwendung reiner Passw\u00f6rter.<\/p>\n
Allerdings lassen sich \u2013 aufgrund des Debian-Bugs \u2013 die verwendeten Schl\u00fcssel ganz einfach auslesen. Mit einigen dieser Schl\u00fcssel h\u00e4tte sich Ben Cox damit leicht Zugriff zu prominenten Repositories verschaffen und diese manipulieren k\u00f6nnen, darunter das von Python, der Python-Webentwicklungsumgebung Django und von einigen gro\u00dfen Firmen wie Spotify, Yandex und Couchbase.<\/p>\n
Eigentlich sollte es bei TLS-Zertifikaten f\u00fcr Webseiten nicht m\u00f6glich sein, verwundbare Schl\u00fcssel zu verwenden. Alle Zertifikate, die damals g\u00fcltig waren, sind inzwischen l\u00e4ngst abgelaufen. Zudem sehen die Baseline Requirements<\/a>, ein Regelwerk, auf das sich Zertifizierungsstellen und Browserhersteller geeinigt haben, vor, dass bei der Zertifikatsausstellung gepr\u00fcft wird, ob ein bekannter kompromittierter Schl\u00fcssel verwendet wird. Der Debian-OpenSSL-Bug wird dabei explizit als Beispiel erw\u00e4hnt.<\/p>\n Dennoch tauchen immer noch Zertifikate auf, die von dem Bug betroffen sind. 2017 gelang es dem IT-Journalist Hanno B\u00f6ck ein Zertifikat mit verwundbarem Schl\u00fcssel<\/a> bei Let\u00b4s Encrypt zu erstellen. Obwohl B\u00f6ck dies gemeldet hatte, wurde das Zertifikat nicht widerrufen. Erst nachdem die Zertifizierungsstelle angeschrieben wurde, tat sich etwas: Inzwischen hat Let\u00b4s Encrypt einen Check eingebaut, der die Ausstellung solcher Zertifikate verhindert. B\u00f6ck suchte weiter und fand in den Daten der Certificate-Transparency-Logs zwei von Certum ausgestellte Zertifikate, deren Schl\u00fcssel mit einem verwundbaren Debian-System<\/a> erzeugt wurden. Zudem enthielten zwei Zertifikate von Startcom, eins von QuoVadis sowie eins von Wosign verwundbare, private Schl\u00fcssel.<\/p>\n Wenngleich Browserhersteller den Zertifizierungsstellen Wosign und Startcom inzwischen das Vertrauen entzogen haben (wir haben berichtet<\/a>), finden sich offensichtlich immer noch andere CAs, die Zertifikate mit verwundbarem Schl\u00fcsseln 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\u00fcfen.<\/p>\nFazit des Debian-Bugs: Alte Bugs sterben nie<\/strong><\/h3>\n