L’édito de MISC HS n°21 !

La complexité est l’ennemi de…

… de celui qui développe une preuve de concept ! S’il y a un dénominateur commun à quelques-unes des vulnérabilités importantes de ce début d’année 2020, c’est la simplicité de leur exploitation. Pour au moins deux d’entre elles en tout cas : la CVE-2019-19781, une exécution de code arbitraire qui affecte une solution largement déployée en entreprise (NetScaler ADC/Gateway), élégamment nommée « shitrix » par la communauté. La preuve de concept se résume à quelques lignes de bash/curl, deux requêtes suffisent, et à l’heure où ces lignes sont écrites un exploit est déjà arrivé dans metasploit. On peut imaginer que les attaquants sont en train d’adapter leurs outils pour faire de la post-exploitation au sein d’un système FreeBSD (l’OS utilisé derrière NetScaler). Une seconde vulnérabilité critique, dont le POC est également simple, affecte l’API crypto de Windows. Attardons-nous quelques lignes sur cette dernière.

La CVE-2020-0601, que l’on pourra retrouver sous différents noms (CurveBall, Chain of Fools, Who’s Curve, on ne remerciera jamais assez la créativité du département marketing pour nous simplifier la vie), a été découverte par la NSA, et patchée dans le Patch Tuesday du 14 janvier 2020. Il s’agit d’un problème dans la validation des certificats à base de courbes elliptiques utilisant des paramètres personnalisés. Mais de quoi s’agit-il au juste ? Tout le monde va de sa petite analogie pour expliquer les courbes elliptiques, mais faisons simple et court : une courbe, en plus d’une équation, est composée de paramètres (des constantes), ces derniers étant choisis selon des critères typiquement liés à la sécurité (problème du logarithme discret difficile) et aux performances (optimisation existante pour certaines opérations mathématiques). Le choix des courbes à utiliser a été notamment l’objet d’un long débat lors de la phase de normalisation de TLS 1.2. Il est malgré tout possible de spécifier ses propres paramètres de courbe à utiliser dans un certificat X.509 lorsque l’on utilise TLS, et c’est quelque part ici que se trouve la vulnérabilité dans l’API crypto de Windows. En essayant de simplifier un peu, il est possible de charger un certificat dont on maîtrise la clef privée, grâce à une astuce sur les paramètres, à la place d’un certificat racine valide présent dans la banque de certificats (qui utilise les courbes elliptiques), car les paramètres ne sont pas vérifiés afin de voir s’ils correspondent bien à ceux du standard. On peut alors générer des certificats valides pour à peu près ce que l’on veut, vu que l’on maîtrise une root CA ! Si vous souhaitez plus de détails, nous vous invitons à lire le billet de Yolan Romailler sur le blog de kudelski, preuve de concept à l’appui [0]. Pour ce qui est de l’impact sur Windows Update, vous pouvez mettre à jour sans vous inquiéter, car il utilise RSA avec du pinning.

Mais quelle est l’origine réelle du problème, un simple « missing check » ? Comme l’ont déjà relevé de nombreux experts en cryptographie, la complexité. A-t-on réellement besoin de pouvoir spécifier ses propres paramètres ? Est-ce vraiment utilisé ? C’est bien l’excès de souplesse du standard qui a ajouté une complexité dans son implémentation, et produit cette faille de sécurité.

Enfin, si vous cherchez un bon sujet de discussion pour la prochaine soirée lors d’un évènement sécurité, je vous laisse mélanger les courbes du NIST (provenant de la NSA, et dont on ne savait trop comment elles avaient générées), l’affaire Dual_EC_DRBG (un générateur avec une porte dérobée, élaboré par la NSA), l’abandon de la suite B (ensemble de recommandations de la NSA uniquement à base d’ECC) et CurveBall. Voilà qui produira certainement de belles théories !

[0] https://research.kudelskisecurity.com/2020/01/15/cve-2020-0601-the-chainoffools-attack-explained-with-poc/

Émilien GASPAR / gapz / eg@miscmag.com


 Retrouvez MISC HS n°21 :