La conséquence la plus évidente, celle qui est mentionnée partout, est la faiblesse des clés générées sur la période de vulnérabilité. On pense tout de suite aux clés RSA et DSA qu'il faudra renouveler au plus vite. Mais ce que pas mal de gens oublient, c'est que dans le cas de DSA, ça va un tout petit peu plus loin que les clés générées sous Debian pendant ces deux dernière années. En fait, cela s'applique à toutes les clés DSA qui ont été utilisées sur une machine Debian pendant la période de vulnérabilité, lesquelles doivent être changées, et ce quelle que soit leur date de génération et quelle que soit leur origine.

Pourquoi ? Parce que si vous prenez les équations de signature DSA, vous noterez qu'elles font intervenir un nombre k aléatoire qui est utilisé dans le calcul du deuxième composant s de la signature. Or, si k est prédictible, alors la signature pourra être utilisée par un attaquant pour remonter à votre clé privée, notée x. Et paf. Donc si vous avez utilisé des clés DSA sur un système Debian ces deux dernières année, vous devez les changer. Point.

Que pourrait-il se passer sinon ? Pleins de choses en fait. Dans la pratique, tout bi-clé dont la partie publique est publiée doit être considéré comme perdu. C'est le cas de tous les serveurs SSH et de tout service SSL[1] Pour eux, le risque est la possibilité pour un attaquant de faire du Man in the Middle sur les clients. Le MiM, c'est un peu oldschool, mais bon, ça marche. Dans des environnements comme des hotspots Wi-Fi, ça risquerait d'être la fête. Si le service n'est accessible qu'à des clés ou certificats spécifiques, l'attaquant pourra essayer de brute forcer ces clés client, en partant des paquets qui traînent sur le net. surveillez donc vos logs... Si on vise un client particulier, le mieux sera d'avoir accès à sa clé publique. Si vous avez laissé vos clés publiques un peu partout, paf. Genre si quelqu'un récupère un des fichiers authorized_keys que vous avez peuplé partout où vous avez un compte... Ou si vous vous authentifiez à un serveur sur lequel un MiM est en cours...

Ah oui, et puis ce n'est parce que vous n'êtes pas sous Debian que vous n'êtes pas touché. On ne cessera pas de le répéter, mais le problème est dans les clés, plus dans OpenSSL[2] ! Et des clés, ça se ballade. Partout. Par exemple, si un de vos utilisateurs s'authentifie sur le SSH de votre box OpenBSD avec sa clé publique générée sous Debian, vous êtes vulnérable. Si vos services sont sous Gentoo, mais que votre PKI tourne sous Debian, vous êtes vulnérable aussi. Etc. Et si vous ne faites pas confiance, il vous suffira d'essayer pour vous en rendre compte. Sur tous les serveurs SSH ou SSL vulnérables que vous allez trouver, une grosse majorité sera certes sous Debian, mais la population de machines tournant sous d'autres distros, voire même d'autres systèmes d'exploitation est loin d'être négligeable. J'ai même trouvé des Windows...


Pour donner un peu de corps à tout ceci, parlons attaque pratique, dans un cas concret. BenjO, sur le blog Plokaned, nous parle des difficultés de renouveler les certificats dans environnement Wi-Fi 802.1x. Ça a l'air bien chiant hein ? Ça l'est, je vous le confirme. Mais vous devez le faire. Et vite. Pourquoi ? C'est ce que je me propose de vous expliquer rapidement. Executive summary : tout simplement parce que la sécurité d'un accès 802.1x repose sur votre capacité à garantir l'authentification mutuelle. Et qu'avec des clés faibles, ça tombe à l'eau.

Commençons par le cas simple d'une authentification 802.1x en PEAP. Le RADIUS présente son certificat, donc sa clé publique. À partir de là, et si le bi-clé a été générée par une Debian pendant la période qui va bien, un attaquant pourra récupérer la clé privée associée. Il se retrouvera donc en position de détourner toutes les authentifications qui vont suivre en se faisant passer pour le serveur RADIUS légitime, et in fine réaliser un MiM. Pour PEAP, ça veut dire voir le contenu du tunnel TLS, donc l'authentification client. Dans la plupart des cas, ce sera un challenge MS-CHAPv2 qu'il pourra brute-forcer, de préférence équipé de ses rainbow tables favorites. Avec un peu de chance, il tombera sur de l'EAP-GTC en deuxième phase, et les éléments d'authentification seront alors directement récupérés et utilisables dans le cadre d'un MiM.

Maintenant, s'il est face à de l'EAP-TLS, l'attaquant mettra en place son MiM comme précédemment pour récupérer le certificat du client, et donc sa clé publique. Dans la mesure où tout ce beau monde a de fortes chances de sortir de la même PKI, le bi-clé associé sera très probablement faible. Rebelotte. Il récupère la clé privée de l'utilisateur. Et paf.

On pourra aussi penser au système S/MIME qui s'appuie sur des certificats également. Là, on parle principalement d'authentification de l'expéditeur et de confidentialité des échanges. L'attaquant n'a plus qu'à consulter l'annuaire pour récupérer les clés publiques de quelques personnes soigneusement choisies. À partir de là, comme précédemment, il récupère la clé privée associée et peut d'une part fabriquer des signatures au nom de n'importe laquelle de ses victimes et d'autre part déchiffrer les messages qui leur sont destinés. Bref, à la clé, si je puis m'exprimer ainsi, c'est usurpation d'identité et perte de confidentialité à gogo. Super...

Enfin, le problème n'est pas limité aux clés, mais à tout ce qui demande de l'aléa à OpenSSL. Truc à la mode par exemple : un gestionnaire de mots de passe. Comme pwsafe par exemple, dont la couche crypto repose sur... OpenSSL bien sûr. Maintenant, qu'est-ce que ça veut dire pour son package Debian ? Une (bonne) idée ? Non ? Allez, je vous aide :

~$ pwsafe --add
[...]
username: test
password [return for random]: 
Generate random password? [y] 
Use z#r6_3u=0rBQ_=6vy-689u=s/XuO3y^SkHBG

Vous voyez mieux maintenant ? Ben oui. Tous les mots de passe générés par pwsafe durant ces deux années de vulnérabilité sont très probablement prédictibles...


Bref, les implications de cette faille sont énormes, et clairement pas limitées aux seules clés générées sous Debian. Vraiment. Nous l'avons vu avec les clés DSA ou encore avec applications comme pwsafe. Tout ce qui utilise le générateur d'aléa d'OpenSSL est touché. Et mettre à jour ses packages n'est malheureusement qu'une infime partie de la solution, même pas la partie émergée de l'iceberg..

Good luck, Jim.

Notes

[1] Avec des clés générées par OpenSSL évidemment.

[2] Puisque le package est corrigé...