Der kleine OpenSSL-Wegweiser
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.
- Christiane Rütten
- Jürgen Schmidt
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.
SSH
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 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).
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.
Weitere Dienste
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.
