Les auteurs de cet article s'opposent aux mécanismes de cryptage de clé standard dans OpenSSH.Les attaquants ont récemment utilisé le package npm eslint-scope pour voler des jetons npm dans les répertoires personnels des utilisateurs. À la lumière de cet événement, nous avons commencé à vérifier d'autres vulnérabilités similaires et réfléchi à la manière de réduire les risques et les conséquences de tels incidents.
La plupart d'entre nous ont une clé RSA SSH sous la main. Cette clé donne au propriétaire une variété de privilèges: en règle générale, elle est utilisée pour accéder à l'environnement de production ou dans GitHub. Contrairement aux jetons nmp, les clés SSH sont cryptées, et il est donc généralement admis que rien de mauvais ne se produira, même si elles tombent entre de mauvaises mains. Mais est-ce vraiment le cas? Voyons.
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/
Cette clé est cryptée, comme indiqué par l'une des premières lignes du fichier. De plus, au début, il n'y a pas de clé de codage MII - base64 utilisée dans RSA. Et, bien sûr, AES attire votre attention! C'est bon, non? Et CBC, à première vue, avec un vecteur d'initialisation aléatoire. Il n'y a pas de code d'authentification (MAC). Eh bien, il n'y aura pas d'attaque oracle de rembourrage, non?
Découvrir ce que signifie réellement le contenu de DEK-Info n'est pas si simple. Une recherche du mot-clé «DEK-Info» dans le référentiel openssh-portable ne montre que des exemples de clés. Mais le fait est que la clé AES n'est rien d'autre qu'un simple hachage MD5 (mot de passe || vecteur d'initialisation [: 8]). Et c'est mauvais, car les meilleures pratiques pour le stockage des mots de passe disent que les mots de passe sous leur forme pure, en raison de leur faible entropie, sont de mauvais supports de chiffrement. Et pour le rendre meilleur, vous avez besoin d'une fonction coûteuse comme Argon2. Mais MD5, contrairement à ce dernier, est facile à calculer.
Le seul point positif de ce schéma est que le sel est placé après le mot de passe, par conséquent, il ne fonctionnera pas pour calculer l'état intermédiaire MD5 (IV [8:]) et trouver les mots de passe en fonction de celui-ci. Mais ce n'est pas une grande consolation, en particulier à une époque où des machines qui effectuent des milliards d'appels MD5 par seconde sont à notre disposition - plus que des mots de passe ne peuvent arriver.
Vous vous demandez peut-être comment OpenSSH a vécu pour voir cela. Hélas, la réponse est simple: l'outil de ligne de commande OpenSSL utilisait initialement ce schéma par défaut, et il est simplement devenu la norme.
En fin de compte, il devient vrai que les clés standard cryptées par mot de passe ne valent pas mieux que les clés ordinaires non cryptées simplement parce que le mécanisme de cryptage est inefficace. Cependant, nous parlerions encore plus audacieux - ils sont pires. Et c'est facile de discuter.
Il est peu probable que de nombreuses personnes utilisent un gestionnaire de mots de passe pour stocker le mot de passe de la clé SSH. Au contraire, l'utilisateur s'en souviendra simplement. Et, comme il s'agit de l'une des combinaisons mémorisées, il est probable que l'utilisateur l'ait déjà utilisée ailleurs. Peut-être qu'il correspond même au mot de passe utilisateur de l'appareil. Il est tout à fait possible de le deviner (sa fonction formatrice est trop peu fiable), et si le mot de passe est connu, vous pouvez probablement le vérifier avec la clé publique.
Il n'y a rien à redire sur la paire de clés RSA elles-mêmes: la seule question est les méthodes de cryptage symétrique de la clé privée. Il est impossible de réaliser l'attaque décrite ci-dessus, en ne connaissant que la clé publique.
Comment puis-je régler la situation?
OpenSSH fournit un nouveau format de clé à utiliser. Par nouveau, on entend introduit en 2013. Ce format utilise bcrypt_pbkdf, qui est essentiellement un bcrypt à complexité fixe implémenté sous la norme PBKDF2.
De manière pratique, vous recevez automatiquement une clé dans un nouveau format lors de la génération de clés Ed25519, car l'ancien format de clé SSH ne prend pas en charge les nouveaux types de clés. C'est assez étrange, car en fait, nous n'avons pas vraiment besoin du format de clé pour déterminer comment fonctionne la sérialisation Ed25519, car l'Ed25519 lui-même définit le travail de sérialisation. Mais si vous avez vraiment besoin d'une bonne fonction formatrice, vous ne pouvez pas vous embêter avec de telles bagatelles. Par conséquent, l'une des réponses est
ssh-keygen -t ed25519 .
Si, pour des raisons de compatibilité, vous devez adhérer à RSA, vous pouvez utiliser ssh-keygen -o. Ainsi, un nouveau format peut être obtenu même pour les anciens types de clés. Vous pouvez mettre à jour les anciennes clés avec la commande
ssh-keygen -p -o -f key name . Si vos clés vivent sur Yubikey ou sur des cartes à puce, ces modifications ont déjà été prises en compte.
D'une manière ou d'une autre, nous visons une sortie plus optimale. D'une part, il existe un bon exemple d'aws-vault, dans lequel les informations d'identification ont été déplacées du disque vers les trousseaux. Il existe une autre approche: déplacer le développement vers des environnements partagés. Enfin, la plupart des startups devraient envisager d'abandonner le stockage à long terme des clés SSH et de passer à un centre de certification SSH avec un temps de stockage des clés limité couplé à un système d'authentification unique. Malheureusement, dans le cas de GitHub, cette approche n'est pas possible.
PS Il est difficile de vérifier ces informations dans une source faisant autorité, mais si la mémoire nous sert bien, le paramètre versionné dans les clés privées du format OpenSSH PEM affecte uniquement la méthode de cryptage. Cependant, cela ne joue aucun rôle: le problème est la fonction de formation des clés, et nous pensons que c'est un autre argument contre la discussion des protocoles en plusieurs parties. Il y aura un article séparé sur ce sujet dans notre blog.
Et enfin - un
lien vers la clé complète. C'est au cas où vous êtes prêt à pirater quoi que ce soit aujourd'hui.
