Die Autoren dieses Artikels sprechen sich gegen die Standardschlüsselverschlüsselungsmechanismen in OpenSSH aus.Angreifer haben kürzlich das npm-Paket eslint-scope verwendet, um npm-Token aus Benutzer-Home-Verzeichnissen zu stehlen. Angesichts dieses Ereignisses haben wir begonnen, andere ähnliche Schwachstellen zu überprüfen und darüber nachzudenken, wie die Risiken und Folgen solcher Vorfälle verringert werden können.
Die meisten von uns haben einen RSA-SSH-Schlüssel zur Hand. Dieser Schlüssel bietet dem Eigentümer verschiedene Berechtigungen: In der Regel wird er für den Zugriff auf die Produktionsumgebung oder in GitHub verwendet. Im Gegensatz zu nmp-Token werden SSH-Schlüssel verschlüsselt. Daher wird allgemein angenommen, dass nichts Schlimmes passiert, selbst wenn sie in die falschen Hände geraten. Aber ist es wirklich so? Lass es uns herausfinden.
user@work /tmp $ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): mykey
...
user@work /tmp $ head -n 5 mykey
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,CB973D5520E952B8D5A6B86716C6223F
+5ZVNE65kl8kwZ808e4+Y7Pr8IFstgoArpZJ/bkOs7rB9eAfYrx2CLBqLATk1RT/
Dieser Schlüssel ist verschlüsselt, wie in einer der ersten Zeilen der Datei angegeben. Außerdem wird zu Beginn kein MII-Base64-Codierungsschlüssel in RSA verwendet. Und natürlich fällt AES auf! Es ist gut, oder? Und CBC auf den ersten Blick mit einem zufälligen Initialisierungsvektor. Es gibt keinen Authentifizierungscode (MAC). Na dann wird es keinen Polster-Orakelangriff geben, oder?
Es ist nicht so einfach herauszufinden, was der Inhalt von DEK-Info wirklich bedeutet. Eine Suche nach dem Schlüsselwort "DEK-Info" im openssh-portable Repository zeigt nur Beispiele für Schlüssel. Der Punkt hier ist jedoch, dass der AES-Schlüssel nichts anderes als ein einfacher MD5-Hash ist (Passwort || Initialisierungsvektor [: 8]). Und das ist schlecht, weil Best Practices zum Speichern von Passwörtern besagen, dass Passwörter in ihrer reinen Form aufgrund ihrer geringen Entropie schlechtes Verschlüsselungsmaterial sind. Und um es besser zu machen, benötigen Sie eine teure Funktion wie Argon2. Im Gegensatz zu letzterem ist MD5 jedoch leicht zu berechnen.
Der einzige positive Punkt in diesem Schema ist, dass das Salz nach dem Passwort platziert wird. Daher funktioniert es nicht, den Zwischenzustand MD5 (IV [8:]) zu berechnen und die darauf basierenden Passwörter zu finden. Dies ist jedoch kein Trost, insbesondere in einer Zeit, in der uns Maschinen zur Verfügung stehen, die Milliarden von MD5-Anrufen pro Sekunde tätigen - mehr als nur Passwörter.
Sie fragen sich vielleicht, wie OpenSSH dies erlebt hat. Leider ist die Antwort einfach: Das OpenSSL-Befehlszeilentool verwendete dieses Schema ursprünglich standardmäßig und es wurde einfach zur Norm.
Am Ende stellt sich heraus, dass die standardmäßigen, kennwortverschlüsselten Schlüssel nicht besser sind als normale unverschlüsselte Schlüssel, nur weil der Verschlüsselungsmechanismus unwirksam ist. Wir würden jedoch noch mutiger sprechen - sie sind schlimmer. Und es ist leicht zu streiten.
Es ist unwahrscheinlich, dass viele Benutzer einen Kennwortmanager verwenden, um das Kennwort für den SSH-Schlüssel zu speichern. Vielmehr wird sich der Benutzer einfach daran erinnern. Und da dies eine der gespeicherten Kombinationen ist, ist es wahrscheinlich, dass der Benutzer sie bereits an anderer Stelle verwendet hat. Möglicherweise stimmt es sogar mit dem Benutzerkennwort des Geräts überein. Es ist durchaus möglich, es zu erraten (seine formative Funktion ist zu unzuverlässig), und wenn das Passwort bekannt wird, können Sie es wahrscheinlich mit dem öffentlichen Schlüssel überprüfen.
Es gibt keine Beschwerden über das RSA-Schlüsselpaar selbst: Die einzige Frage sind die Methoden zur symmetrischen Verschlüsselung des privaten Schlüssels. Es ist unmöglich, den oben beschriebenen Angriff auszuführen, wenn nur der öffentliche Schlüssel bekannt ist.
Wie kann ich die Situation beheben?
OpenSSH bietet ein neues Schlüsselformat. Mit neu ist die Einführung im Jahr 2013 gemeint. Dieses Format verwendet bcrypt_pbkdf, eine im Wesentlichen nach dem PBKDF2-Standard implementierte bcrypt mit fester Komplexität.
Praktischerweise erhalten Sie beim Generieren von Ed25519-Schlüsseln automatisch einen Schlüssel in einem neuen Format, da das alte SSH-Schlüsselformat neuere Schlüsseltypen nicht unterstützt. Dies ist ziemlich seltsam, da wir das Schlüsselformat nicht wirklich benötigen, um zu bestimmen, wie die Ed25519-Serialisierung funktioniert, da der Ed25519 selbst die Serialisierungsarbeit festlegt. Aber wenn Sie wirklich eine gute prägende Funktion brauchen, können Sie sich nicht mit solchen Kleinigkeiten beschäftigen. Daher lautet eine der Antworten
ssh-keygen -t ed25519 .
Wenn Sie aus Kompatibilitätsgründen RSA einhalten müssen, können Sie ssh-keygen -o verwenden. Somit kann auch für alte Schlüsseltypen ein neues Format erhalten werden. Sie können alte Schlüssel mit dem Befehl
ssh-keygen -p -o -f Schlüsselname aktualisieren. Wenn Ihre Schlüssel auf Yubikey- oder Smartcards gespeichert sind, wurden diese Änderungen bereits berücksichtigt.
Auf die eine oder andere Weise streben wir einen optimaleren Ausgang an. Einerseits gibt es ein gutes Beispiel für aws-vault, bei dem Anmeldeinformationen von der Festplatte auf Schlüsselanhänger verschoben wurden. Es gibt einen anderen Ansatz: Verlagerung der Entwicklung in gemeinsam genutzte Umgebungen. Schließlich sollten die meisten Startups in Betracht ziehen, die Langzeitspeicherung von SSH-Schlüsseln aufzugeben und in ein SSH-Zertifizierungszentrum mit einer begrenzten Schlüsselspeicherzeit in Verbindung mit einem Single Sign-On-System zu wechseln. Leider ist dieser Ansatz bei GitHub nicht möglich.
PS Es ist schwierig, diese Informationen in einer autorisierenden Quelle zu überprüfen, aber wenn der Speicher uns gute Dienste leistet, wirkt sich der versionierte Parameter in den privaten Schlüsseln des OpenSSH PEM-Formats nur auf die Verschlüsselungsmethode aus. Dies spielt jedoch keine Rolle: Das Problem ist die Schlüsselbildungsfunktion, und wir glauben, dass dies ein weiteres Argument gegen die teilweise Erörterung der Protokolle ist. Es wird einen separaten Beitrag zu diesem Thema in unserem Blog geben.
Und schließlich - ein
Link zum vollständigen Schlüssel. Dies ist für den Fall, dass Sie heute etwas hacken wollen.
