Die OpenSSL-Bibliothek in Debian und daraus abgeleiteten Linux-Distributionen hat seit 2006 schwache Kryptografische Schlüssel erzeugt. Welche Auswirkungen das hat und was es für Sie bedeutet, erfahren Sie hier. Mit den Hintergründen und den Folgerungen daraus beschäftigt sich der "Standpunkt Sicherheit" vom 19. Mai.
Was ist passiert?
Luciano Bello hat herausgefunden, dass die von OpenSSL erzeugten Zufallszahlen und dadurch die damit erzeugten Schlüssel vorhersagbar sind. Auslöser der Misere ist ein Patch, der mit der Version 0.9.8c-1 vom 17. September 2006 eingeführt wurde. Die Test-Tools Valgrind und Purify fanden Code-Zeilen, die für potenzielle Speicherlecks gehalten wurden. Um diese möglichen Schwachstellen zu beheben, sollten die beiden Zeilen auskommentiert werden. Bevor der Patch freigegeben wurde, wurde auf der OpenSSL-Developer-Mailingliste nachgefragt, was es damit auf sich hat und ob die Zeilen entfernt werden können. Da es keinen Widerspruch gab, wurden die Zeilen dann letztendlich auskommentiert und der Patch in die Debian-Portierung von OpenSSL eingepflegt. Das Problem dabei: Diese Zugriffe auf unbelegte Speicherbereiche dienten dazu, zufällige Ausgangswerte für die Erzeugung der Zufallszahlen zu erhalten.
Was hat das für Folgen?
Der Patch führte dazu, das die Funktion, die für das Sammeln der notwendigen Ausgangswerte für den Zufallszahlengenerator zuständig ist, nicht mehr funktionierte. Dadurch wurden überhaupt keine zufälligen Ausgangswerte erfasst und für die Bildung der Zufallszahlen nur noch die Linux-Prozess-ID verwendet. Die ist 16 Bit lang, und damit stehen pro gegebener Architektur, Schlüsseltyp- und -länge nur 32.767 mögliche Werte zur Verfügung. Mit anderen Worte: Wurde z.B. für OpenSSH auf einen x86-System ein RSA-Schlüssel mit 2048 Bit Länge erzeugt, gibt es nur 32.767 mögliche Ergebnisse. H D Moore hat verschiedene Kombinationen für SSH bereits durchgerechnet und stellt die Ergebnisse samt verwendeten Tools im Rahmen des Metasploit-Projekts bereit. Auf der Seite sind auch Scanner verlinkt, die entfernte Rechner auf zu schwache Schlüssel untersuchen. Auf Milw0rm wurden ein Perl- und ein Ruby- Skript veröffentlicht, die die erzeugten Daten für einen Brute-Force-Angriff auf einen SSH-Server nutzen.
Wer ist gefährdet?
Alle zwischen September 2006 und der Installation der am 13. Mai veröffentlichten Updates auf einem betroffenen Debian-System erzeugten Schlüssel für z.B. SSH, OpenVPN, DNSSEC und X.509 Zertifikate (z.B. für S/MIME, IPSec und SSL/TLS) sind leicht vorhersagbar. Die mit betroffenen X.509-Zertifikaten erzeugten Schlüsseltexte und Signaturen müssen ebenfalls als gebrochen betrachtet werden.
Außer Debian selbst sind auch die von Debian abgeleiteten Distributionen wie Ubuntu und Knoppix betroffen. Netzwerk-Appliances können eine betroffene Distribution verwenden, ohne dass das auf den ersten Blick ersichtlich ist.
Andere Systeme enthalten zwar nicht die Schwachstelle, jedoch können auf einem betroffenen System erzeugte schwache Schlüssel dort installiert worden sein.
Was kann passieren?
Besonders gefährdet sind zur Zeit SSH-Server, da dafür die fertig
berechneten Schlüsselsammlungen zur Verfügung stehen. Angreifbar
sind nicht nur Debian und daraus abgeleitete Systeme, sondern alle -
lediglich die betroffenen Schlüssel müssen auf einen
anfälligen System erzeugt worden sein. Falls also z.B. ein Benutzer
auf seinem betroffenen Debian-System einen Schlüssel erzeugt hat, und
den auf einem eigentlich nicht betroffenen Solaris-System in seine
authorized_keys-Datei eingetragen hat, ist auch das
Solaris-System gefährdet. Typisch sind folgende zwei Angriffe:
- Wenn in der
authorized_keys-Datei eines Benutzers ein betroffener Schlüssel enthalten ist, kann ein Angreifer sich mit den oben erwähnten Skripts Zugangs zum System verschaffen. Das Skript probiert einfach alle möglichen Schlüssel durch, bis es den richtigen gefunden hat. Ist eine gültige Benutzerkennung bekannt, die einen schwachen Schlüssel verwendet, müssen maximal 32.767 Schlüssel durchprobiert werden, im Mittel deutlich weniger.
Da jeder Angreifer danach trachtet, einen root-Zugriff zu erlangen, wird im Allgemeinen zuerst dieser Benutzername ausprobiert. Es ist daher ratsam, den SSH-Zugang für root zu deaktivieren. Der ist sowieso in den seltensten Fällen notwendig, ein Administrator kann sich auch über ein normales Benutzerkonto mit dem System verbinden und sich die entsprechenden Rechte danach bei Bedarf mit Hilfe vonsudoodersubeschaffen.
Systeme, die gegen Brute-Force-Angriffe abgesichert sind, z.B. indem die Anzahl möglicher Loginversuche beschränkt ist, bremsen einen Angriff damit zwar aus, können ihn aber nicht restlos verhindern. - Wurde der SSH-Hostkey auf einem betroffenen System erstellt, kann
der Angreifer den Fingerprint des Hostkeys abfragen und darüber
den passenden Schlüssel auswählen. Danach kann er
aufgezeichneten SSH-Verkehr entschlüsseln und/oder sich als
Man-in-the-Middle in die Verbindung zwischen Benutzer und Server
einschleichen.
Da der Angreifer aufgezeichneten Netzwerkverkehr auch noch später entschlüsseln kann, müssen alle über eine so geschützte Verbindung übertragenen Zugangsdaten etc. als kompromittiert betrachtet und ausgetauscht werden.
Andere Anwendungen, die betroffene Schlüssel oder Zertifikate nutzen, sind zur Zeit weniger gefährdet, da (noch) keine Angriffstools und Schlüsselsammlungen veröffentlicht wurden. Es wird aber erfahrungsgemäß nicht lange dauern, bis auch dafür erste Angriffe bekannt werden.
Eine besondere Gefahr sind dabei aufgezeichnete Verbindungen: Angreifer können später jederzeit mit dann verfügbaren Tools eine jetzt aufgezeichnete Verbindung entschlüsseln und darin nach Zugangsdaten und anderen vertraulichen Daten suchen. Die in einer aufgezeichneten Online-Banking-Sitzung enthaltenen TANs sind dann zwar schon ungültig, nicht aber die PIN. Ebenso sieht es mit den Zugangsdaten zu Mailkonten usw. usf. aus. Anbieter, die schwache Schlüssel verwendet haben, sollten daher nach dem Austausch der Schlüssel ihre Benutzer zur Änderung von damit geschützten Passwörtern, PINs usw. auffordern.
Was ist zu tun?
Auf Debian und davon abgeleiteten Systemen müssen zuerst die Updates installiert werden. Prüfen Sie aber vorher ihre SSH-Konfiguration: Es muss mindestens ein nicht betroffener Schlüssel freigegeben sein. Das Update für OpenSSH installiert eine Blacklist, mit der alle Verbindungsversuche abgeglichen werden. Verbindungsversuche mit betroffenen Schlüsseln werden abgewiesen. Sollten Sie nur betroffene Schlüssel freigeschaltet haben, sperren Sie sich also mit der Installation des Updates aus.
Danach müssen alle erzeugten schwachen Schlüssel und Zertifikate zurückgezogen und durch neu erzeugte ersetzt werden. Von Debian wurde eine entsprechende Anleitung für verschiedene Programme veröffentlicht. Weitere Informationen sowie Anleitungen zum Testen vorhandener Schlüssel hält ein Beitrag im Debian-Wiki bereit.
Auf allen Systemen müssen alle Schlüssel daraufhin
geprüft werden, ob es sich um schwache Schlüssel handelt.
Dafür wurde von den Debian-Entwicklern ein Perl-Skript (.gz-Datei) bereit gestellt, mit dem OpenSSH-Host- und
-Benutzerschlüssel sowie Shared Secrets von OpenVPN auf die
Schwäche geprüft werden können. Ein Patch (.gz-Datei) erlaubt auch das Prüfen der sonst
übergangenen Dateien authorized_keys2 und
known_hosts. Mit dem Aufruf
# perl dowkd.pl user
können Sie prüfen, ob ein Benutzer einen schwachen Schlüssel
für OpenSSH freigegeben hat. Voraussetzung dafür ist, das die
Default-Schlüssellängen verwendet wurden, da die verwendeten
Blacklists nur RSA-2048- und DSA-1024-Schlüssel enthalten. Erweiterte
Listen sind im Beitrag im Debian-Wiki aufgeführt, ebenso Tools
zum Prüfen anderer Schlüssel und Zertifikate.
Leider sind die verschiedenen Tools nicht unbedingt zuverlässig, da sie die Schlüssel nur mit vorliegenden Blacklists vergleichen. Werden Schlüssel mit z.B. ungewöhnlichen Schlüssellängen verwendet oder wurden Schlüssel auf ungewöhnlichen Systemen erzeugt, werden sie nicht erkannt. Ein negatives Ergebnis bedeutet also noch lange nicht, das kein schwacher Schlüssel vorhanden ist. Im Laufe der Zeit werden hoffentlich zuverlässigere Lösungen veröffentlicht. Erste Anlaufstelle für Informationen ist dabei der bereits erwähnte Beitrag im Debian-Wiki.
Fazit
Erste Angriffe auf SSH-Server wurden bereits gemeldet. Entsprechend ist für SSH-Server Eile geboten - installieren Sie auf Debian und davon abgeleiteten Systemen sofort die Updates. Auf allen SSH-Servern muss nach zu schwachen Schlüsseln gesucht werden. Darauf können Sie nur verzichten, wenn Sie absolut sicher sind, das keine auf einem betroffenen Debian-System erzeugten Schlüssel verwendet werden.
Für andere Programme wie OpenVPN, IPSec und SSL/TLS sind noch keine Angriffstools bekannt, aber damit ist eher früher als später zu rechnen. Prüfen Sie also auch dort die verwendeten Schlüssel.
Wenn es neue Entwicklungen gibt, wird der Eintrag im Bereich Security aktuell aktualisiert.
Carsten Eilers
