Katastrophen-Alarm im Internet: OpenSSL hat Geheimnisse verraten.
Die millionenfach eingesetzte Verschlüsselungs-Software OpenSSL musste einen katastrophalen Fehler einräumen, der von seinen Findern "Heartbleed" getauft wurde.
Dieser Fehler hat es ermöglicht, bei einer SSL-Verbindung (wie sie zum Beispiel beim Homebanking verwendet wird) Speicher aus dem Server-Computer auszulesen. OpenSSL ist eine der am häufigsten verwendeten SSL-Implementationen und wird von einer unüberschaubaren Menge anderer Software verwendet. Über die Hälfte der Webserver auf der Welt verwenden OpenSSL. Das betrifft Banken, Online-Shops, aber auch im Hintergrund ablaufende automatisierte Prozesse wie Software-Updates.
Dieser Fehler ist deshalb besonders gefährlich, weil er es ermöglicht, dass ein Angreifer bei einem Server Teile des Speichers auslesen kann. In diesem Speicher können nun alle möglichen Dinge liegen, die in einer SSL-Implementation so anfallen -- insbesondere Schlüssel und die entschlüsselten Daten. In einigen Fällen lagen dort nicht nur die Daten von dieser Sitzung, sondern noch die von vorigen anderen Sitzungen, womöglich gar von anderen Benutzern. SSL kann zwar auch dafür benutzt werden, sich sicher auszuweisen, aber es wird im Regelfall nur dafür benutzt, eine reguläre Username+Passwort-Anmeldung durch Verschlüsselung vor Mitlesern zu schützen. Durch diesen Fehler in OpenSSL konnte man jetzt die Usernamen und Passwörter von anderen Benutzern sehen. Schlimmer noch: Man muss davon ausgehen, dass Angreifer teilweise auch die geheimen Schlüssel des SSL-Servers sehen konnten. Wer diesen Schlüssel hat, der kann sich anderen gegenüber als der Server ausgeben -- genau das, was SSL verhindern sollte!
Das Schlimme an diesem Fehler ist, dass wir nachträglich nicht sehen können, was für Daten unsere Systeme verlassen haben. Wir müssen davon ausgehen, dass wir alle so verlierbaren Daten auch verloren haben. Alle betroffenen Webseiten müssen ihre alten Schlüssel für ungültig erklären und neue beantragen. Das ist normalerweise kein Problem; der Kunde merkt es nicht einmal. Betroffene SSL-Webseiten müssen davon ausgehen, dass die Passwörter ihrer Benutzer so zumindest partiell ausgelesen werden konnten. Eigentlich müsste man jetzt alle Benutzer auffordern, ihre Passwörter zu ändern. Und da viele Benutzer das selbe Passwort bei verschiedenen Webseiten verwenden, müssten das eigentlich auch alle nicht direkt betroffenen Webseiten tun.
Als wäre das alles nicht schon apokalyptisch genug, muss man auch davon ausgehen, dass es Angreifern möglich war, mit ausgelesenen Server-Schlüssel Opfern gefälschte Software-Updates aufzuspielen. Glücklicherweise sichern einige Hersteller ihre Software-Updates über separate Signaturen. Unglücklicherweise sichern viele Hersteller ihre Software-Updates nicht einmal per SSL -- durch einen SSL-Totalschaden sind deren Kunden dann auch nicht unsicherer als vorher.
Der Code, der diesen Fehler enthält, ist übrigens vom Januar 2012.
In der Post-Snowden-Welt liegt bei so einem Vorkommnis die Frage nahe, ob das möglicherweise eine von den Geheimdiensten herbeigeführte Sabotage-Aktion war. Wir wissen ja inzwischen, dass GCHQ und NSA schwindelerregende Budgets dafür haben, die Verschlüsselungsstandards der Welt zu schwächen, und ihren Opfern Wanzen und Hintertüren unterzuschieben. In diesem Fall kam der Code mit dem Fehler von einem noch keine 30 Jahre alten FH-Studenten aus Deutschland, der allerdings später bei der Telekom-Tochter T-Systems anfing, die dafür bekannt ist, BND-Kollaborateur zu sein. (Siehe http://wikileaks.org/wiki/German_Secret_Intelligence_Service_%28BND%29_T-Systems_network_assignments,_13_Nov_2008)
Stand der Technik beim Einbau von Hintertüren ist, dass man "plausibles Abstreiten" ermöglicht, indem die Hintertür wie ein Fehler aussieht. Sicher kann man daher anhand des Codes nicht entscheiden, ob das eine Hintertür oder bloß ein Fehler war. Man kann aber sehr wohl sagen, dass dieser Fehler alle technischen Kriterien an eine nützliche Hintertür erfüllt.
Wichtiger als die Schuldfrage ist, dass wir solche Probleme in Zukunft durch geeignete Qualitätssicherungsmaßnahmen verhindern. In dem Aspekt ist dieser Fehler besonders augenöffnend, weil seine Fehlerkategorie nach industrie-üblichen Standards als besonders gering gilt. Hier ist offensichtlich eine Überarbeitung der Standards nötig.
OpenSSL ist ein Open-Source-Projekt und verfügt damit nicht über die Droh- und Lockmittel eines kommerziellen Softwarehauses, da hier keiner der Entwickler bezahlt wird oder mit Kündigung bedroht werden könnte. Trotzdem hat OpenSSL vergleichsweise hohe Qualitätssicherungsstandards. Auch der Code mit diesem Fehler musste erst durch eine Begutachtung durch einen anderen Entwickler, der das Problem aber auch nicht gesehen und den Code durchgewunken hat.
Wir werden uns jetzt mit der Frage beschäftigen müssen, wie wir in Zukunft verhindern, dass Code mit solchen Lücken überhaupt geschrieben wird; und wenn er geschrieben wurde, wie wir verhindern, dass er an so wichtiger Stelle in ein so zentrales Projekt einfließen kann; und wie wir in sicher stellen wollen, dass solche Probleme frühzeitiger erkannt werden. Dieser Fehler wurde von Google bei einer gezielten Sicherheitsüberprüfung entdeckt. Das muss auch ohne Google gehen.