Kritische PuTTY-Schwachstelle CVE-2024-31497 verrät private Schlüssel

Sicherheit (Pexels, allgemeine Nutzung)[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.

PuTTY vulnerability CVE-2024-31497

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.


Anzeige

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.

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.


Anzeige

Dieser Beitrag wurde unter Sicherheit, Software abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

21 Antworten zu Kritische PuTTY-Schwachstelle CVE-2024-31497 verrät private Schlüssel

  1. McAlex777 sagt:

    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?

    • Robert sagt:

      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" ;)

      • McAlex777 sagt:

        Und wie sehe ich ob ich einen "ecdsa-sha2-nistp521" Schlüssel habe?

        • Anonym sagt:

          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."

      • McAlex777 sagt:

        und wie stelle ich am SSH-Server fest ob solche Schlüssel hinterlegt sind?

        • Fritz sagt:

          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.

        • Ralph D. Kärner sagt:

          Warum, meinst Du, wäre die Abfrage auf dem Server eine andere als auf dem Client?

          • Fritz sagt:

            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.

  2. 1ST1 sagt:

    "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.

    • CryptoFox sagt:

      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.

      • CryptoFox sagt:

        Um das nochmal zu verdeutlichen:
        Die nonce hat nichts mit dem eigentlichen Schlüssel zu tun, die nonce soll den Schlüssel schützen.

        • 1ST1 sagt:

          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.

  3. Robert Glöckner sagt:

    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…

  4. Pau1 sagt:

    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?

    • M.D. sagt:

      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.

  5. mw sagt:

    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.

  6. Patrick sagt:

    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

  7. speedy75 sagt:

    Wenn man die portable Version nutzt ist man dann auch ganz schön gekniffen, die steht aktuell immer noch bei Version 0.78.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.

Du findest den Blog gut, hast aber Werbung geblockt? Du kannst diesen Blog auch durch eine Spende unterstützen.