Heartbleed

Internet-Sicherheit und OpenSSLs Heartbleed (Keine Werbeanzeige)

Leave a Comment

Keine Werbeanzeige und vom Original in der FAZ, Handelsblatt und ZEIT deutlich abweichend:

Mein Name ist Klaus… Mein Name ist Patrick Sauer. Ich bin Master of Science in Security Management, Diplom-Wirtschaftsinformatiker (FH), zertifizierter Sicherheitsspezialist (z.B. CISSP & OSCP) und werde dieses Jahr 30. Ich habe vor über 10 Jahren während meiner Gymnasialzeit privat als Hobby C gelernt. Ich bin auch Geschäftsführer eines kleinen Beratungsunternehmens.

Ich habe mir den problematischen Source Code von Heartbleed ange­sehen. Ein Angreifer kann zufälligen Speicher auslesen, z.B. Passwörter oder private kryptographische Schlüssel zu Zertifikaten. Eine Denial-of-Service Attacke über Heartbleed halte ich für eher unwahrscheinlich und eine eventuelle DoS-Attacke ist nicht das eigentliche Problem, sondern der weitgehend unerkannte Abzug der kryptographischen Schlüssel. Dadurch ist es einem Angreifer möglich den verschlüsselten Datenverkehr zu entschlüsseln, sofern keine Perfect Forward Secrecy eingesetzt wurde.

Es gibt den Grundsatz: Alles was der Benutzer eingibt, muss sorgfältig geprüft werden. Das sollten eigentlich alle Entwickler wissen. Das trifft natürlich auch für Entwickler von Webseiten zu, nur haben Entwickler von Webseiten und Entwickler von OpenSSL nichts miteinander zu tun. Eingabevalidierung ist natürlich auch vom öffentlichen Netzwerk wichtig. Dem Entwickler von OpenSSL, der Heartbleed geschaffen hat, ist das sicherlich bewusst gewesen. Er hat einen Fehler gemacht. Fehler sind menschlich. Der Entwickler hat mittlerweile an einer deutschen Hochschule promoviert und man kann ihn sicherlich als übermäßig intelligent bezeichnen. Leider begehen auch übermäßig intelligente Menschen Fehler. Das ist die eine Seite.

Wie kommt es, dass ein so hoch qualifizierter Entwickler an hochsensibler Sicherheits-Software arbeiten darf? Das ist ganz einfach zu beantworten. Es handelt sich um ein Open Source Projekt. Auch Unternehmen, die eigene SSL-Implementierungen verkaufen, setzen Open Source ein. Manche sogar auch OpenSSL. Manche Open Source Entwickler betreiben die Entwicklung als Hobby, manche sind minderjährig und andere bereits im Rentenalter. Andere entwickeln an Open Source und werden dafür von Unternehmen bezahlt.

Es gibt hervorragende Open-Source Lösungen. Manche weisen leider keine so hohe Qualität auf. Das gilt genauso für kommerzielle Software und auch für kommerzielle SSL-Implementierungen. Die wenigsten Entwickler sind unqualifizierte Bastler. Oftmals wird Open Source von einem Team geführt und es existieren eigene komplexe Mechanismen zur Qualitätssicherung. Keine Qualitätssicherung ist perfekt, genauso wenig wie es 100%ige Sicherheit gibt. Qualität ist eine andere Sache.

Wenn man Software minderer Qualität einsetzt hat man ein Sicherheitsrisiko. Kann sein, muss aber nicht. Manche kommerzielle Software ist fehlerhaft und verursacht höhere Kosten. Genauso kann es bei Open Source sein.

Manche Internet-Unter­nehmen haben folgendes Geschäftsprinzip. Sie warten darauf, bis es in einem Open Source Projekt ein Sicherheitsproblem existiert, dass in Konkurrenz zu ihrer Software steht. Dann schalten sie in großen deutschen Zeitungen Werbung für ihr Produkt. In dieser Werbung reden sie die Konkurrenz schlecht. Nach diesem Prinzip können Unternehmen vielleicht groß werden, oder sie schrecken von der Nutzung ihrer Produkte ab. Selbst diese Unternehmen sollen OpenSSL einsetzen, ohne irgendwie die Qualität zu prüfen. Unglaublich.

Aus OpenSSL wurde jetzt Heartbleed entfernt. Wer weiß, wie viele Probleme noch in OpenSSL schlummern? Gute Frage. Das gilt übrigens für jede Software. Gerade bei kommerzieller Software, die nicht veröffentlicht wird, ist die Frage extrem schwer zu beantworten. Open Source Programme werden teilweise mit teuren Tools überprüft, deren Einsatz für die Projekte kostenlos ist. Warum? Weil es auch anständige Unternehmer gibt.

Die NSA weiß schon was sicher ist. Die wollen selbst nicht gehackt oder ausspioniert werden. Deswegen arbeitet die NSA an Open Source Projekten wie zum Beispiel SELinux.

Ich rate davon ab, als sicherheitskritische Software wenig verbreitete kommerzielle Software einzusetzen, deren Quelltext man nicht frei beziehen kann. Ich setzte und setze weiterhin OpenSSL ein. Fehler passieren jedem, Entwicklern wie CEOs. Manche entschuldigen sich öffentlich, andere gar nicht.

Der Einsatz von Perfect Forward Secrecy ist alternativlos!

Leave a Comment

Klassisch verschlüsselte Kommunikation über SSL/TLS kann nachträglich mit Zugriff auf den privaten Key vom Zertifikat wieder entschlüsselt werden. Mit dem Netzwerk-Sniffer Wireshark ist das nicht sonderlich schwer und die letzten Jahre hat es die wenigsten gestört. Ein Abzug der privaten Keys setzt gewöhnliche eine Komprimierung des Servers voraus, sodass das Risiko oftmals als nicht sonderlich hoch angesehen wurde. Seit dem Snowden-Zeitalter änderte sich etwas das Risikobewusstsein, nachdem der eventuelle Gegner auch eine NSA sein könnte. Was früher vielleicht noch Paranoia war, sind heute ernstzunehmende Angriffsvektoren. Das Buzzword Advanced Persistent Threats (APT) lässt grüßen. Das Risiko erhöhte sich, aber es war noch nicht kritisch.  Eine massenhafter Schwenk zu Perfect Forward Secrecy wurde dennoch nicht vollzogen, auch wenn es die nachträgliche Entschlüsselung effektiv verhindern würde.

Heartbleed änderte das. Die Sicherheitslücke in OpenSSL erlaubt es, zufällige Speicherbereiche des Servers auszulesen. Nachdem die privaten Schlüssel zu den Zertifikaten notwendigerweise im Speicher gehalten werden, können diese nun ausgelesen werden. Einzige Voraussetzung: Eine verwundbare OpenSSL-Version. Dass der Angriff kaum forensische Spuren hinterlässt, macht ihn noch gefährlicher. Die Keys lassen sich nicht mit 1-2 Anfragen auslesen, aber durch massenhafte Anfragen extrahieren. Das wurde öffentlich nachgeprüft und mittlerweile existiert dafür auch ein Angriffs-Tool.

Die Sicherheitslücke in OpenSSL zeigt uns, dass auch mutmaßlich „sichere“ Software hochkritische Lücken aufweisen kann. Sofern kein Perfect Forward Secrecy eingesetzt wurde, lässt sich der Datenverkehr von einem Angreifer jetzt nachträglich problemlos entschlüsseln. Nun ist der Einsatz von Perfect Forward Secrecy absolut alternativlos; alles andere muss ab sofort als nicht ausreichend sicher angesehen werden.