[English]Verwendet jemand den SSH- und Telnet-Client PuTTY? Mit der freien Software PuTTY lassen sich Verbindungen über Secure Shell, Telnet, Remote login oder serielle Schnittstellen herstellen. Der PuTTY-Client stellt die Verbindung mit dem betreffenden Server her. Allerdings gibt es in der betreffenden Software eine kritische Schwachstelle (CVE-2024-31497), über die sich private SSH-Schlüssel rekonstruieren lassen. Betroffen sind die PuTTY Versionen 0.68 bis 0.80 sowie weitere Produkte (FileZilla zum Beispiel). Es reicht aber nicht, die Produkte auf eine gepatchte Version zu aktualisieren, da die Schlüssel bereits rekonstruiert sein können.
Anzeige
PuTTY ist eine freie Software zum Herstellen von Verbindungen über Secure Shell (SSH), Telnet, Remote login oder serielle Schnittstellen. Dabei dient PuTTY als Client und stellt die Verbindung zu einem Server her. Beim Verbindungsaufbau wird die Identität des Benutzers mittels einer der bereitgestellten Methoden zur Authentifizierung überprüft. PuTTY ist für Windows und Linux verfügbar. In der so bereitgestellten textorientierten Terminalsitzung können direkt Befehle abgesetzt werden, die auf dem Remote-System ausgeführt werden. Eine grafische Ausgabe ist nicht möglich, jedoch kann ein X-Server genutzt werden, der auf dem Client-Rechner läuft. Zudem wird IPv6 ab der Version 0.58 und die serielle Schnittstelle ab der Version 0.59 unterstützt.
PuTTY-Schwachstelle CVE-2024-31497
In PuTTY (Versionen 0.68 bis 0.80) gibt es die kritische Schwachstelle CVE-2024-31497, die einem Angreifer ermöglicht, den privaten NIST P-521-Schlüssel über etwa 60 Signaturen zu rekonstruieren. Die Schwachstelle wurde von Fabian Bäumer und Marcus Brinkmann (Ruhr Universität Bochum) entdeckt.
Das Problem ist, dass der PuTTY-Client und alle zugehörigen Komponenten stark mit einem BIAS versehene ECDSA-Nonces im Fall von NIST P-521 erzeugen. Die Entdecker geben an, dass die ersten 9 Bits jeder ECDSA-Nonce Null sind. Dies ermöglicht einen vollständigen geheimen privaten Schlüssel in rund 60 Signaturen unter Einsatz modernster Techniken zu rekonstruieren. Die dazu benötigten Signaturen können entweder von einem böswilligen Server erfasst werden (Man-in-the-Middle-Angriffe sind nicht möglich) oder aus einer anderen Quelle, z.B. signierte Git-Commits über weitergeleitete Agenten.
Mit anderen Worten: Ein Angreifer verfügt möglicherweise bereits über genügend Signaturinformationen, um den privaten Schlüssel eines Opfers zu kompromittieren. Dies gilt selbst dann, wenn anfällige PuTTY-Versionen nicht weiter verwendet werden. Nach einer Schlüsselkompromittierung kann ein Angreifer möglicherweise Supply-Chain-Angriffe auf in Git verwaltete Software durchführen.
Ein zweites, unabhängiges Szenario besteht laut NIST darin, dass der Angreifer ein Betreiber eines SSH-Servers ist, bei dem sich das Opfer (für die Remote-Anmeldung oder das Kopieren von Dateien) authentifiziert, obwohl das Opfer diesem Server nicht vollständig vertraut und das Opfer denselben privaten Schlüssel für SSH-Verbindungen zu anderen Diensten, die von anderen Unternehmen betrieben werden, verwendet. Hier kann der betrügerische Serverbetreiber (der andernfalls keine Möglichkeit hätte, den privaten Schlüssel des Opfers zu ermitteln) den privaten Schlüssel des Opfers ableiten und ihn dann für den unbefugten Zugriff auf diese anderen Dienste verwenden.
Wenn die anderen Dienste Git-Dienste umfassen, ist es wiederum möglich, Supply-Chain-Angriffe auf in Git verwaltete Software durchzuführen. Dies betrifft beispielsweise auch FileZilla vor 3.67.0, WinSCP vor 6.3.3, TortoiseGit vor 2.15.0.1 und TortoiseSVN bis 1.14.6.
Es gibt Fixes, das ist zu tun
Diese Schwachstelle wurde in PuTTY 0.81 sowie FileZilla 3.67.0 behoben. Das Gleiche gilt für WinSCP 6.3.3 und TortoiseGit 2.15.0.1. Benutzern von TortoiseSVN wird empfohlen, die Software beim Zugriff auf ein SVN-Repository über SSH für die Verwendung von Plink aus der neuesten PuTTY 0.81-Version zu konfigurieren, bis ein Patch verfügbar ist.
Anzeige
ECDSA NIST-P521-Schlüssel, die mit allen anfälligen Produkten/Komponenten verwendet wurden, gelten als kompromittiert und werden demzufolge widerrufen (indem sie entfernt werden). PuTTY hat dieses Advisory zur Problematik herausgegeben. Ein deutschsprachiger Beitrag findet sich beispielsweise bei Golem.
2015
Ich verstehe die genauen Auswirkungen nicht.
Heist das, das alle via PuttyGen generierten Schlüssel die an SSH-Servern hinterlegt wurden, sollten unabhängig vom Patchen der Putty-Version erneuert werden?
Hat nichts mit PuttyGen zu tun.
Wenn Du einen ecdsa-sha2-nistp521 Schlüssel hast, egal mit welcher Software dieser generiert wurde, UND Du eines der folgenden Programme mit diesem Schlüssel verwendet hattest…
– PuTTY – Version 0.68 – 0.80
– FileZilla 3.24.1 – 3.66.5
– WinSCP 5.9.5 – 6.3.2
– TortoiseGit 2.4.0.2 – 2.15.0
– TortoiseSVN 1.10.0 – 1.14.6
…sollte dieser Schlüssel als kompromittiert betrachtet werden.
Ein NEUER Schlüssel darf natürlich nicht mit den o.g. Versionen benutzt werden.
Also ZUERST diese Programme auf diese neueste fehlerbereinigte Version updaten und erst dann den neuen Schlüssel benutzen. Sonst ist der neue Schlüssel ja gleich wieder "verbrannt" ;)
Und wie sehe ich ob ich einen "ecdsa-sha2-nistp521" Schlüssel habe?
Von chatopenai.de generiert (Auszug):
"To detect the type of an SSH key, you can use the following command in your terminal:
ssh-keygen -lf /path/to/your/key
This command will display the type of the SSH key (RSA, DSA, ECDSA, or ED25519) and the fingerprint."
und wie stelle ich am SSH-Server fest ob solche Schlüssel hinterlegt sind?
Das ist vom SSH-Server abhängig.
Ein typischer Fall dürfte Linux mit einem OpenSSH sein, da gibt es im Homedirectory des Nutzers (also des Accounts, mit dem Du Dich einloggen willst) im versteckten Unterordner ".ssh" eine Datei "authorized_keys", in der der Typ des Keys (z.B. "ssh-rsa"), der (öffentliche Teil des) Schlüssel und noch ein Kommentarfeld, oft vorbelegt mit dem Namen des Nutzers enthalten sind.
Bei OpenSSH auf Windows befindet sich der ".ssh"-Ordner direkt im Benutzerprofil des Users.
"ssh-rsa" ist dabei unbedenklich oder?
Warum, meinst Du, wäre die Abfrage auf dem Server eine andere als auf dem Client?
Weil es sich um asymmetrische Kommunikation (PKI) handelt.
Der SSH-Server (ich beziehe mich jetzt auf das Kommunikationsmodell und nicht auf irgendeine Rechnerbezeichnung) "kennt" nur den öffentlichen Teil des Schlüssels und kann damit den Clienten ausreichend sicher identifizieren.
Den privaten Teil des Schlüssels kennt nur der SSH-Client und kann damit seine Anfragen signieren.
Wesen der Sicherheitslücke ist ja gerade, daß sich dieser private Teil unerwartet einfach von außen rekonstruieren läßt.
"und werden demzufolge widerrufen" Bedeutet: Wer selbst SSH/SFTP-Server betreibt, muss diese nach ECDSA NIST-P521-Schlüsseln durchsuchen und löschen. Aber erst, nachdem die entsprechenden Benutzer ihre Tools aktualisiert haben. Denn die alten Tools erzeugen weiterhin rekonstruierbare Schlüssel.
Falsch, hast die nonce leakage nicht verstanden!
Es ist egal woher der Schlüssel kommt. Bitte lese dich mal in ECDSA ein. Der Schlüssel wird rekonstruiert, weil die nonce (Zufallszahl) beim Herstellen der verbindung nicht zufällig genug ist.
ECDSA ist genial aber empfindlich, schon 1 bit "schlechter" Zufall reicht aus um den Privaten Schlüssel byte für byte zu leaken. Deswegen auch 13 Handshakes oder so.
Viele hier verstehen leider das Problem in der Anfälligkeit gar nicht. Schade.
Um das nochmal zu verdeutlichen:
Die nonce hat nichts mit dem eigentlichen Schlüssel zu tun, die nonce soll den Schlüssel schützen.
Dann wärs ja nicht so schlimm, wie es von diversen Portalen, auch hier aufgebauscht wird… Bei Hackernews, Bleeping usw. ließt sich das aber anders. Für mich sieht das nach dem feuchten Traum aller Geheimdienste aus.
WinSCP vom gleichen Autor wurde wg des gleichen Fehlers auch aktualisiert.
https://winscp.net/eng/news.php#winscp_6_3_3_released
netterweise kriegt man das über einige Kanäle aktualisiert, incl. Winget. Problematisch sind aber die Versionen, die verschiedener Software beiliegen und dort in deren Programmpfad abgelegt werden – Spontan fällt mir Veeam ein, das eine Version 0.76 dabei hat – es aber keine Updates oder Hotfixes gibt. So gammeln da teilweise Uraltversionen herum…
Putty in Veeam wurde im Januar mit Version 12.1.1.56 auf 0.80 aktualisiert:
https://www.veeam.com/kb4510
Die aktuelle 0.81 ist noch nicht als Patch verfügbar, aber es ist auch fraglich, ob das spezielle Problem für Veeam tatsächlich relevant ist.
Wann/wer hat denn den Schlüsseltyp 521-Bit ECDSA (ecdsa-sha2-nistp521) verwendet?
Nur der ist betroffen. und nicht "alle".
Ist der einfache ssh/winscp User überhaupt betroffen?
Wenn man diesen privaten Schlüssel verwendet hat (schon das Wort NIST sollte zögern auslösen..) muss man jetzt auf allen öffentlichen Stellen, auf denen damit erzeugte Signaturen liegen neu signieren?
Oder was genau soll man machen?
Ein hart gekochtes Ei bekommt man ja nicht wieder in die Tube zurück, oder war das Zahnpasta?
Natürlich sollte man die neueste Version nehmen.
Aber wo sieht der Wald und Wiesen User überhaupt, welchen Schlüssel Typ er eingestellt hat?
In PuTTYgen kann man sich den Schlüsseltyp ansehen, wenn man nicht sicher sein sollte. Standardmäßig wird dieser Schlüsseltyp wohl kaum irgendwo erstellt.
Ich denke, das ist eher ein akademisches als praktisches Problem. Generell haben NIST Kurven ein "Gschmäckle" und sind eher selten in Verwendung. Man kann mit puttygen den privaten Schlüssel laden und sieht dann, auf welchem Algorithmus dieser basiert. Ist natürlich blöd, wenn man P521 verwendet hat, aber nicht weiß, wo überall man diesen key verwendet hat. Sinnvollerweise verwendet man sowieso für jeden Server ein anderes Keypaar.
Zumindest lt. cert.at müssen ein paar Kriterien gegeben sein, damit die Lücke wirklich so ausgenutzt werden kann. Für die meisten User wird das daher eher nicht recht releveant sein.
https://cert.at/de/aktuelles/2024/4/schwere-sicherheitslucke-in-putty-cve-2024-31497
Wenn man die portable Version nutzt ist man dann auch ganz schön gekniffen, die steht aktuell immer noch bei Version 0.78.
Das kann ich nicht bestätigen. Gestern nur die exe selbst geladen (nicht den msi Installer). Hatte Version 0.81.