zurück zum Artikel

Der kleine OpenSSL-Wegweiser

Christiane Rütten, Jürgen Schmidt

Debians Debakel mit den unsicheren OpenSSL-Schlüsseln zieht Kreise. So können auch SuSE, Red Hat oder sogar Windows gefährdet sein. Erschwerend hinzu kommt, dass die Test-Tools nicht zuverlässig funktionieren und sich mancher beim Update selber aussperrt.

Zunächst zum Risikopotential: Gefährdet sind alle Systeme, die mit Schlüsseln arbeiten, die OpenSSL erstellen kann egal unter welchem Betriebssystem. Dazu gehören insbesondere SSH-, OpenVPN-, IPsec- und Mail- beziehungsweise Web-Server mit SSL (https) sowie DNS-Server mit DNSSEC/DK. Obwohl nur Debian-Derivate unsichere Schlüssel erzeugen, sind auch Systeme anderer Hersteller angreifbar, wenn beispielsweise ein Debian-User dort einen Schlüssel von seinem Debian-System für den Login freigegeben hat. Ist etwa auf einem Suse-Linux-Server in der Datei ~/.ssh/authorized_keys ein verwundbarer Schlüssel aufgelistet, hat der Suse-Admin ein Problem.

Akut gefährdet sind vor allem SSH-Server. HD Moore hat mit einigen Tricks alle verwundbaren SSH-Schlüssel generiert und stellt diese zum Download bereit. Damit sind Brute-Force-Angriffe auf SSH-Zugänge möglich, die wahrscheinlich auch bereits angelaufen sind. Zum Glück ist dazu doch ein gewisser Aufwand erforderlich. Zwar kann man mit Tools wie openssl-vulnkey einen Server mit einem verwundbaren Host-Key aufspüren. Doch das bedeutet zum Glück noch nicht, dass man sich dann auf diesem System einloggen könnte, sondern "nur", dass ein Angreifer verschlüsselten Netzwerkverkehr, den er abgefangen hat, dekodieren kann. Das geht dann allerdings auch im Nachhinein.

Um richtig Zugriff auf einen SSH-Server zu erlangen, muss ein Angreifer versuchen, sich via Public-Key-Authentifizierung etwa als "root" anzumelden. Hat der Admin dort einen unsicheren Schlüssel freigegeben, ist es möglich, diesen durch Durchprobieren herauszufinden. Dazu muss der Angreifer zwar typischerweise mehrere tausend Schlüssel testen, nichstdestotrotz stellt das ein durchaus realistisches Angriffsszenario dar.

Deshalb sollte unbedingt jeder Admin eines SSH-Servers egal auf welchem Betriebssystem sofort mit dem Tool dowkd.pl [1] via

# perl dowkd.pl user

überprüfen, ob einer der Anwender einen verwundbaren Schlüssel freigegeben hat und diesen vorsichtshalber sperren. Leider ist ein negativer Bescheid noch lange kein Grund zum Jubeln, denn die bisher verfügbaren Listen umfassen längst nicht alle kritischen Schlüssel, und das Tool mindestens einen blinden Fleck (siehe auch die Übersicht zu den Tools [2]).

Wer einen Debian-Server betreibt, sollte das fällige Update am besten via 

aptitude update
aptitude dist-upgrade

einspielen, um sicherzugehen, dass alle relevanten Pakete installiert werden. Es genügt nämlich keineswegs nur das Paket openssl zu aktualisieren. Das Update dichtet auch gleich den Server ab, indem es über eine schwarze Liste den Login mit verwundbaren Schlüsseln sperrt. Gescheiterte Login-Versuche protokolliert der SSH-Server dann in /var/log/auth.log:

sshd[26085]: Public key a3:80:be:45:83:71:38:dd:7f:06:77:70:c9:83:29:7a blacklisted (see ssh-vulnkey(1))

Doch Achtung: Wer sein System so eingerichtet hat, dass er sich nur mit einem dieser Schlüssel anmelden kann, sperrt sich durch das Update unter Umständen aus. Also unbedingt vorher Schlüssel prüfen und eventuell austauschen.

Etwas weniger akut ist die Gefahrenlage bei den anderen Diensten, die SSL-Zertifikate beziehungsweise Schlüssel verwenden. Hier gibt es bislang zumindest keine öffentlich verfügbaren Schlüsselsammlungen. Dafür ist es teilweise sehr schwierig bis unmöglich, verwundbare Zertifikate zu lokalisieren und gezielt zu sperren. So liefert zwar beispielsweise Ubuntu mit dem Paket openvpn-blacklist das Tool openvpn-vulnkey mit -- doch das kann nur statische Pre Shared Keys testen. Dummerweise testet es noch nicht einmal, ob es einen solchen vor sich hat, sondern erteilt etwa bei einem RSA-Key aus einem X509-Zertifikat kurzerhand einen Freifahrtschein:

$ openvpn-vulnkey ju-key.pem
Not blacklisted: 82857... ju-key.pem

X509-Zertifikate beziehungsweise die zugehörigen Schlüssel kann bislang beispielsweise das Tool openssl-vulnkey testen. Doch dazu muss erstens der (RSA-)Schlüssel in Form einer PEM-Datei vorliegen und zweitens muss man über das erforderliche Passwort verfügen, ihn auszupacken. Und selbst dann umfassen die aktuellen Listen nur Schlüssel mit 1024 und 2048 Bit. Das PKI-Tool TinyCA zum Beispiel erstellt jedoch in der Voreinstellung bereits Schlüssel mit 4096 Bit, die zwar durchaus auch verwundbar sind, wenn eine die kritische OpenSSL-Bibliothek aus dem Debian-Paket zum Einsatz kam, aber bislang nicht gefunden werden.

Um verwundbare Schlüssel aufzuspüren, gibt es inzwischen ein Sammelsurium von Tools und Blacklists. Das Problem ist jedoch, dass derzeit kein Programm alle verwundbaren Schlüssel aufstöbern kann. Blacklists existieren bislang nur für ausgewählte Schlüsseltypen und Längen, vornehmlich die der Standard-Einstellungen. Man kann sich also auf die darauf beruhenden Sicherheitssperren nicht verlassen und die Scanvorgänge müssen regelmäßig mit aktualisierten, erweiterten Listen wiederholt werden. Nachfolgend ist der Stand vom 2. Juni zusammengefasst. Wir werden versuchen, die aktuellen Entwicklungen auch in den kommenden Tagen nachzutragen, können dies jedoch nicht garantieren.

Das wichtigste Testprogramm ist das offizielle Debian-Perl-Skript zum Aufspüren von verwundbaren SSH-Schlüsseln namens dowkd.pl [3]. Es kann sowohl einzelne Dateien analysieren als auch die User-Verzeichnisse durchsuchen und SSH-Server übers Netz prüfen. Inzwischen unterstützt es zwar die authorized_keys2-Datei, doch einen Blinden Flecken hat es noch: Es berücksichtigt nur die beiden Default-Schlüssellängen RSA-2048 und DSA-1024.

Das Skript lässt sich aber erweitern. Auf einer privaten Website [4] stehen zusätzliche Listen bereit, die sich nach dem Entpacken an das Skript anhängen lassen, etwa mit bzip2 -cd rsa-4096-le.blacklist.bz2 >> dowkd.pl. Zusätzlich ist aber auch das Perl-Skript in Zeile 126 so anzupassen, dass es die zusätzlichen Bitlängen nicht von vornherein ausschließt. Zum Testen anderer Schlüsseltypen eignet sich dowkd.pl jedoch nicht, weil seine Blacklists auf SSH-Schlüssel zugeschnitten sind.

Für Debian-basierte Systeme gibt es die Pakete openssh-blacklist, openvpn-blacklist und openssl-blacklist. Die Pakete für openvpn und openssl enthalten auch die zugehörigen Testprogramme openvpn-vulnkey beziehungsweise openssl-vulnkey zum Prüfen lokaler Schlüsseldateien. Das Testprogramm ssh-vulnkey für SSH-Schlüssel befindet sich im aktualisierten openssh-client-Paket. Bis auf die Möglichkeit, SSH-Server übers Netz zu testen, ist ssh-vulnkey vom Funktionsumfang her mit dowkd.pl vergleichbar. Das openssl-blacklist-Paket gibt es allerdings bislang nur im Ubuntu-Repository. Für Debian-Admins gibt es jedoch eine speziell angepasste Version [5].

Die Blacklists umfassen jeweils unterschiedliche Schlüsseltypen und -längen. Für OpenSSL-Schlüssel gibt es Listen für RSA-1024 und RSA-2048; die Liste für OpenVPN-Schlüssel (Preshared Keys) deckt lediglich das Default-Format RSA-2048 ab. Die SSH-Blacklists eignen sich für Schlüssel in den Formaten DSA-1024 sowie RSA-2048. Den Test-Tools für OpenSSL und OpenVPN ist gemein, dass sie nur einzelne lokale Dateien prüfen können. Skripte, die mit ihnen ein System nach verwundbaren Schlüsseln durchforsten und dergleichen müssen sich Anwender selber basteln.

Wer die Erkennungsleistung für SSH-Schlüssel verbessern möchte, kann zusätzliche Blacklist-Dateien – etwa für Schlüssel mit 4096 Bit oder für auf Big-Endian- und 64-Bit-Prozessoren erzeugte Schlüssel – aus einem erweiterten openssh-blacklist-Paket [6] installieren. Mit ihnen erkennt ssh-vulnkey und damit der SSH-Server auch die zusätzlichen Schlüssel-Varianten.

Die neuen Blacklists müssen jedoch noch in das richtige Format gebracht werden. Die folgenden Befehle erledigen die Nachrüstung:

# cd /etc/ssh
# wget http://love.hole.fi/atte/openssh-blacklist/openssh-blacklist_0.3.tar.gz
# tar zxf open*gz
# cp black* open*/
# cd open*
# cat *DSA-1024* | sed -e 's/.*\(....................\)$/\1/g'	\
	| grep -v ^\# | sort -u >../blacklist.DSA-1024
# cat *RSA-1024* | sed -e 's/.*\(....................\)$/\1/g'	\
	| grep -v ^\# | sort -u >../blacklist.RSA-1024
# cat *RSA-2048* | sed -e 's/.*\(....................\)$/\1/g'	\
	| grep -v ^\# | sort -u >../blacklist.RSA-2048
# cat *RSA-4096* | sed -e 's/.*\(....................\)$/\1/g'	\
	| grep -v ^\# | sort -u >../blacklist.RSA-4096

Somit kann man verantwortungsbewussten Admins eigentlich nur raten, alle Zertifikate, die auf Debian-Varianten im fraglichen Zeitraum von September 2006 bis Mai 2008 erstellt wurden, so schnell wie möglich zu widerrufen und neue auszustellen. Wieviel Zeit dazu noch bleibt, ist sehr schwer einzuschätzen. Bislang sind uns keine öffentlich verfügbaren Tools für Angriffe auf OpenVPN, IPSec und Co bekannt. Man darf aber getrost davon ausgehen, dass bereits daran gearbeitet wird.

Bei SSH-Servern hingegen besteht sofortiger Handlungsbedarf – und zwar sofort im Sinne von "jetzt gleich", denn die Angriffe laufen bereits. Jeder, der einen SSH-Server in Betrieb hat, bei dem er nicht absolut sicher sein kann, dass niemand einen Debian-Key dort eingetragen hat, sollte unverzüglich nach den bereits in Listen erfassten Schlüsseln suchen und diese sperren.

Tickende Zeitbomben sind aufgezeichnete Verbindungen, über die verschlüsselt vertrauliche Daten übertragen wurden. Mit den richtigen Tools, die in Hackerkreisen sicher bald verfügbar sind, kann ein Angreifer, dem beispielsweise eine PCAP-Datei mit einer kompletten SSH-Sitzung in die Hand fällt, unter Umständen das Passwort herausfischen – oder aus einer mitgeschnittenen https-Verbindung die Online-Banking-PIN.

Siehe dazu auch:

(ju [9])

URL dieses Artikels:
https://www.heise.de/-270076

Links in diesem Artikel:
[1] http://security.debian.org/project/extra/dowkd/dowkd.pl.gz
[2] #tools-u1
[3] http://security.debian.org/project/extra/dowkd/dowkd.pl.gz
[4] http://www.red-bean.com/~maxb/
[5] http://wiki.debian.org/SSLkeys?action=AttachFile&do=get&target=openssl-blacklist_0.1-0%7Edebian-1_all.deb
[6] http://love.hole.fi/atte/openssh-blacklist/openssh-blacklist_0.3.tar.gz
[7] https://www.heise.de/hintergrund/Gute-Zahlen-schlechte-Zahlen-270078.html
[8] http://wiki.debian.org/SSLkeys
[9] mailto:ju@ct.de

Copyright © 2008 Heise Medien