Katastrophen-Alarm im Internet: Ein 27 Monate alter Fehler hat es ermöglicht, dass bei SSL-Verbindungen, wie wir sie täglich beispielsweise beim Homebanking verwenden, der Speicher der Server ausgelesen werden konnte. Betroffen ist „OpenSSL“, also eine der am häufigsten verwendeten Verschlüsselungs-Implementationen, die von einer unüberschaubaren Menge anderer Software verwendet wird. Gemeint ist damit: Mehr als die Hälfte der Webserver auf der Welt verwenden OpenSSL, Banken, Online-Shops, aber auch im Hintergrund ablaufende automatisierte Prozesse, beispielsweise für Software-Updates.

Der entdeckte und „Heartbleed“ getaufte Fehler ist nicht nur weit verbreitet, sondern auch besonders gefährlich. Er ermöglicht Angreifern, in kleinen Teilen die Arbeitsspeicher der Server auszulesen. In diesen Speichern liegt allerhand. Unter anderem zur Verschlüsselung notwendige Schlüssel, entschlüsselte Dateien und Passwörter. Im Regelfall wird SSL dafür benutzt, Username- und Passwort-Anmeldungen durch Verschlüsselung vor Mitlesern zu schützen. Durch den Fehler in OpenSSL konnte man jetzt die Usernamen und Passwörter der Nutzer einsehen. Schlimmer noch: Man muss davon ausgehen, dass Angreifer auch die geheimen Schlüssel des SSL-Servers sehen konnten. Wer diese hat, kann sich anderen gegenüber als diese Server ausgeben – genau das sollte SSL eigentlich verhindern.

Die Server gaben alle Geheimnisse preis

Gravierend an dem Fehler ist, dass wir nachträglich nicht sehen können, welche Daten unsere Systeme tatsächlich verlassen haben. Wir müssen davon ausgehen, dass wir alle verlierbaren Daten auch tatsächlich verloren haben. Das heißt, alle betroffenen Websites müssen ihre alten Schlüssel für ungültig erklären und neue beantragen. Der einzelne Nutzer bemerkt eine solche Umstellung eigentlich nicht. Da neben den Serverzertifikaten allerdings jedes einzelne Passwort betroffen sein kann, müsste nun eigentlich jeder Nutzer seine Passwörter ersetzen. Und da viele Nutzer dasselbe Passwort bei verschiedenen Websites verwenden, müssten alle, auch die nicht direkt betroffenen Passwörter geändert werden.

Als wäre das alles nicht schon apokalyptisch genug, muss man unter anderem davon ausgehen, dass es Angreifern möglich war, mit ausgelesenen Server-Schlüsseln 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 ohnehin nicht. Durch den SSL-Totalschaden sind nur deren Kunden als einzige nicht unsicherer dran als vorher.

In Zeiten des Spähskandals liegt bei einem solchen Vorkommnis die Frage nahe, ob es sich um eine von den Geheimdiensten herbeigeführte Sabotage-Aktion handelt. Wir wissen, dass GCHQ und NSA schwindelerregende Budgets für derartige Projekte haben. Verschlüsselungsstandards weltweit zu schwächen und Opfern Wanzen und Hintertüren unterzuschieben ist das Programm. In diesem Fall kam der Code mit dem Fehler von einem noch keine dreißig Jahre alten Studenten aus Deutschland. Er wurde später von der Telekom-Tochter T-Systems beschäftigt. Dass das Unternehmen mit dem BND technisch zusammenarbeitet, zeigt mindestens ein vor fünf Jahren von Wikileaks veröffentlichtes Dokument.

Fehler oder Hintertür?

Stand der Technik beim Einbau von Hintertüren in Software ist, dass man späteres „plausibles Abstreiten“ ermöglicht. Dafür sollte eine Hintertür wie ein Fehler aussehen. Sicher kann man daher anhand des Codes nicht entscheiden, ob es sich um eine Hintertür oder schlicht einen Fehler handelt. Sagen lässt sich allerdings, dass dieser Fehler die Kriterien für eine nützliche Hintertür erfüllt.

Wichtiger als die Schuldfrage ist, dass derartige Probleme in Zukunft durch geeignete Qualitätssicherungsmaßnahmen verhindert werden. Der Fall sollte allen die Augen öffnen, weil seine Fehlerkategorie nach in der Industrie üblichen Standards als besonders gering gilt. Hier ist also eine Überarbeitung des technischen Standards selbst nötig.

OpenSSL ist ein Open-Source-Projekt, es verfügt dadurch nicht über die Droh- und Lockmittel eines kommerziellen Softwarehauses, keiner der Entwickler wird bezahlt, niemandem könnte mit Kündigung gedroht werden. Dennoch hat OpenSSL vergleichsweise hohe Qualitätssicherungsstandards. Auch der Code mit diesem Fehler musste erst durch eine Begutachtung, durch die er offenbar durchgewunken wurde.

Wir werden uns mit der Frage beschäftigen müssen, wie wir verhindern, dass ein Code mit solchen Lücken überhaupt geschrieben wird. Und wenn er geschrieben wurde, gilt es zu verhindern, dass er an so wichtiger Stelle in ein so zentrales Projekt einfließen kann. Wir werden sicherstellen müssen, dass solche Probleme früher erkannt werden. Dieser Fehler wurde von Google bei einer gezielten Sicherheitsüberprüfung entdeckt. Es muss aber auch ohne Google gelingen.