[Debian] Krypto-Keys unsicher (update)

elias5000

elias5000

Site Reliability Engineer
Wie schon im Beitrag beschrieben, gab es da dieses OpenSSL-Issue in Debian und allen davon erbenden Distris.

Jetzt ist erwiesen, dass als einziger Input für den Seed die PID des Prozesses eingeflossen ist. Demnach gibt es pro Key-Size/-Type/Achitektur-Tripel nur maximal 32,768 verschiedene Schlüssel.

Unter Debian OpenSSL Predictable PRNG Toys lässt sich das nachlesen - auch wie der Autor die Schlüssellisten innerhalb weniger Stunden für jede Kombination erzeugen kann.

Jeder, der irgendeinen der betroffenen Schlüssel im Einsatz hat, sollte (nein, muss) sofort _alle_ Schlüssel durch neue ersetzen, die nach einem Update der betroffenen Programme erzeugt wurden.

Die Leute, die sich eine komplette CA damit aufgezogen haben tun mir jetzt echt leid.
 
Jo ich bin noch dabei meine CA neu aufzubauen.
Zum Glück ist die nicht sehr groß. Mit 6 Zertifikaten wohl eher noch winzig. :)

OpenSSH Keys sollte man im übrigen auch neugenieren. ;)
 
Ja. Alle Schlüssel, die das betrifft, sollten neu generiert werden. Auch SSH-Host-Keys u.s.w.
GnuPG ist nicht betroffen. Aber alles andere kann man wohl geschlossen auf die ToDo-List setzen.

Nach der Sache bin ich mal wieder extremst froh, Debian nicht gut zu finden und deshalb nicht in der Fraktion derer zu sein, die das betrifft. (SCNR)

Mich würde mal interessieren, welchen volkswirtschaftlichen Schaden das verursacht. Debian ist ja nicht gerade eine Nischen-Distri...
 
Ich bin gespannt wieviele User dann hier in der nächsten Zeit aufschlagen, weil sie die Keys nicht neugenieriert haben und jammern, dass da einer Spams und Warez verteilt. ;)

Edit:
Kann man eigentlich nur hoffen, dass die großen Zertifizierungsstellen nicht auf Debian setzen. :D
 
Last edited by a moderator:
Unter dem URL, den ich gepostet habe, kann man Key-Listen herunterladen und diese mit den eigenen Keys vergleichen um herauszufinden, ob man ein entsprechend unsicheres Zertifikat besitzt.

Außerdem gibts da einen SSH-Remote-Hostkey-Scanner, mit dem man Hosts auf die Verwendung von unsicheren Host-Keys checken kann. (Login auf einem solchen System sollte aber trotzdem safe sein, wenn man den SSH-Key des Users auf einem non-Debian-System erzeugt hat.)

Update: Ein kurzes Howto wie man die Host-Keys erneuert, ist hier zu finden: http://www.ende-der-vernunft.org/20...l-schwachstelle-nicht-die-ssh-keys-vergessen/
 
Last edited by a moderator:
Debian liefert in der aktuellen SSH Package Version das Tool ssh-vulnkey + Keylisten mit.
Darüber kann ebenfalls geprüft werden ob sich infizierte Keys auf dem System befinden.

Weiterhin gebe ich zu bedenken, dass Debian nicht in jedem Fall von Upgrade die Host Keys in /etc/ssh/ neu erzeugt.
Ich hatte bisher ein System auf dem hat er es von selbst nach einem apt-get dist-upgrade gemacht und ein System bei dem er es nicht gemacht hat. Ursache bisher unbekannt.

Weiterhin habe ich festgestellt das nicht alle Keys von ssh-vulnkey erkannt werden oder nicht alle Keys betroffen sind. Wie auch immer.
Jeden Falls wurden Keys aus dem Jahre 2007 die definitiv auf einem Debian System erzeugt wurden von diesem Tool als ungefährlich gemeldet.
Ich rate trotzdem dazu, alle Keys egal was dieses Tool sagt zu ersetzen.
 
Das Update auf meinem vServer hat definitiv nicht die Keys neu erzeugt. Das musste ich (wie unter dem von mir geposteten URL beschrieben) manuell machen.
Das Verhalten halte ich für plausibel, da sonst u.U. für den Admin unklar ist, wieso eine Maschine plötzlich einen anderen SSH-Fingerprint hat.
 
Seltsam, meine Kiste hatte nach einem apt-get upgrade einen neuen Fingerprint...

Ahja, auch wenn die Frage dumm klingen mag, ist das für mich nur interessant wenn ich mich per Key auf dem Server einlogge, oder auch noch an anderen Stellen, wie z.B. Apache Zertifikaten?
 
Last edited by a moderator:
An allen Stellen wo SSH und SSL zum Einsatz kommt.

Bei der Maschine die bei einem Upgrade die Keys im /etc/ssh (nicht die Keys der User!) neu erzeugt hat, brachte auch so ein nettes blaues "Fenster" mit entsprechenden Hinweisen auf den Bug.
 
Alle Keys, die unter Verwendung des PRNG von OpenSSL erzeugt wurden, sind betroffen.

Also neben den SSH-Host-Keys deine SSH-User-Keys, OpenSSH-Certs (für Apache, und alles, was per SSL/TLS läuft), Certs für S/MIME. GnuPG-Keys sind zum Glück nicht betroffen. Das hätte den GAU perfekt gemacht...

Am schlimmsten dürfe die Sache mit den SSH-User-Keys sein. Nur 16k mögliche Schlüssel je Architektur und Schlüssellänge sind verdammt wenig. Da ist selbst ein mittelmäßiges Passwort schwerer zu knacken...

Deshalb bin ich auch schon gespannt, wie viele Kisten in nächster Zeit geknackt werden, weil die SSH-Keys nicht ausgetauscht wurden...
 
Code: 
 Konfiguriere openssh-server 

Vulnerable host keys will be regenerated
 Some of the OpenSSH server host keys on this system were generated with a version of OpenSSL that had a broken random number generator. As a result, these host keys are from a well-known set, are subject to brute-force attacks, and must be regenerated. 

Users of this system should be informed of this change, as they will be prompted about the host key change the next time they log in. Use 'ssh-keygen -l -f HOST_KEY_FILE' after the upgrade has changed to print the fingerprints of the new host keys.

The affected host keys are: /etc/ssh/ssh_host_rsa_key /etc/ssh/ssh_host_dsa_key

Machte bei mir das apt-get dist-upgrade.
 
Last edited by a moderator:
Hallo,

Firewire2002 said:
weil sie die Keys nicht neugenieriert haben und jammern, dass da einer Spams und Warez verteilt.
Click to expand...

wenn man sich am Server per Key authentifiziert ist die Sache natürlich hochkritisch.

Viele (und wohl insbesondere die User die das Problem nicht mitbekommen oder ernstnehmen oder damit überfordert sind) authentifizieren sich per Passwort. Dann ermöglicht der unsichere Schlüssel keinen direkten Einbruch sondern lediglich das Ausspähen bei Mitlauschen des Datenverkehrs. Dazu muß der Angreifer aber erstmal die Möglichkeit zum Mitlauschen haben und wissen, wo es etwas zu hören gibt.

Selbstverständlich finde ich es korrekt und wichtig, daß SSH verschlüsselt überträgt, trotzdem: um über einen Server Spam zu versenden genügt es i.d.R. ein Mailpasswort abzufangen und die werden bei den meisten Servern unverschlüsselt übertragen, trotzdem ist das kein häufiger Mißbrauchsweg der Spammer.
 
Natürlich gibt es viele Wege die unterschiedlich stark genutzt werden.
Ob dieses Sicherheitsleck nun letzendlich für Spam, Warez oder irgendwas anderes missbraucht wird ist an dieser Steller doch vollkommen irrelevant und bedarf keiner Diskussion, oder?

Fakt ist, es besteht ein gravierendes Problem mit der Sicherheit von SSL Zertifikaten und SSH Keys.
 
PermitBlacklistedKeys
Specifies whether sshd(8) should allow keys recorded in its blacklist of known-compromised keys (see ssh-vulnkey(1)). If ``yes'',
then attempts to authenticate with compromised keys will be logged but accepted. If ``no'', then attempts to authenticate with
compromised keys will be rejected. The default is ``no''.
Click to expand...
Werden Anmeldeversuche mit verbotenen Schlüssel bei "PermitBlacklistedKeys no" protokoliert? Einerseits würde mich interessieren wie lange es dauert bis die ersten Scans bei mir ankommen, andererseits würde ich ungern auf Dauer bei jedem Scan nach unischeren Schlüsseln tausende Zeilen in /var/log/auth.log haben...
 
Hallo,

Firewire2002 said:
Ob dieses Sicherheitsleck nun letzendlich für Spam, Warez oder irgendwas anderes missbraucht wird ist an dieser Steller doch vollkommen irrelevant
Click to expand...
klar - aber ich halte es für einen wesentlichen Punkt, ob und mit wie großer Wahrscheinlichkeit es genutzt werden kann und welche Server akut gefährdet sind.

Spammer können offensichtlich die unverschlüsselt übertragenen SMTP-Passwörter nicht (oder nur in geringem Umfang) abfischen, sonst würden sie es tun. Also können sie auch keine schwach verschlüsselten SSH-Passwörter abfischen.

Selbige Argumentation für die unverschlüsselten FTP-Passwörter und Warez.

Akutes Risiko besteht natürlich für alle Server bei denen man sich per Key authentifizieren kann. Wer sich über Passwort authentifiziert hat nur ein geringfügig größeres Risiko als vor Entdeckung der Sicherheitslücke. Das Passwort wird durch die Lücke nicht weniger sicher, es besteht lediglich ein geringes Risiko, daß es ausgespäht wird.

Fakt ist, es besteht ein gravierendes Problem mit der Sicherheit von SSL Zertifikaten und SSH Keys.
Click to expand...
Natürlich - aber ein wenig Nachdenken, wer besonders gefährdet ist sollte man schon dürfen.
 
Ich halte bei dieser Problematik nicht wirklich viel von Wahrscheinlichkeitsrechnungen, Schätzungen und sonstigem der Gleichen.
Es ist ein großes Problem, dass von jedem Admin behoben bzw. kontrolliert werden muss. Vollkommen unabhängig von deiner Wahrscheinlichkeitsrechnung.
 
Öhm, dumme Frage, wenn ich meinen Key mit Putty erstelle, ist der dann sicher oder nicht!?!?

Basti
 
You must log in or register to reply here.
Back
Top