En cybersécurité, qui n’a pas entendu parler de l’OWASP (Open Web Application Security Project) ? Chaque année, cette organisation à but non lucratif travaillant sur la sécurité des applications Web, publie son Top 10, à savoir la liste des dix risques de sécurité les plus critiques affectant les applications web. En 2021, les défaillances liées à la cryptographie (ou son absence) sont passées en seconde position.
En effet, la cryptographie est devenue un élément essentiel pour assurer la protection des données. Des erreurs commises dans ce domaine peuvent avoir des conséquences désastreuses.
Alors à quoi sont dues les failles cryptographiques découvertes dans la pratique ? Aux algorithmes eux-mêmes ? Aux bibliothèques qui les implémentent ? Ou encore à une mauvaise utilisation de ces bibliothèques par les développeurs ?
Cryptanalyse, une moindre menace ?
Comme l’ont étudié Paterson et al., il existe un fossé entre la manière dont la cryptographie est étudiée en théorie, la manière dont les normes sont définies, la manière dont les développeurs mettent en œuvre les logiciels et la manière dont les utilisateurs les consomment.
Du point de vue d’un développeur, les attaques issues de travaux de cryptanalyse ne semblent exister que sur le papier.
Si je vous demande de citer une faille cryptographique connue, vous allez peut-être penser à la vulnérabilité dans le paquet Debian OpenSSL découverte en 2008, dans laquelle la génération de clés cryptographiques avait une entropie limitée, ce qui a eu pour conséquence de réduire l’espace des clés possibles à plusieurs centaines de milliers. Vous penserez peut-être à la vulnérabilité Goto Fail de 2014 qui était due à une instruction goto mal placée entrainant le contournement de toutes les vérifications de certificats pour les connexions SSL/TLS dans les appareils iOS et Mac ; ou encore à Heartbleed, découverte la même année et qui permet de lire à distance la mémoire protégée de serveurs alimentés par OpenSSL.
Toutes ces vulnérabilités sont issues de problèmes d’implémentation. L’attention s’est donc déplacée de la cryptographie théorique à sa mise en œuvre.
D’ailleurs, afin d’écarter les menaces liées à la cryptanalyse, des autorités telles que l’ANSSI ou le NIST recommandent d’utiliser des algorithmes cryptographiques qui sont approuvés, faisant l’objet d’une analyse de sécurité approfondie et périodiquement réévaluée afin de maintenir leur efficacité.
Mauvaise utilisation des bibliothèques cryptographiques
Une des études pertinentes concernant les vulnérabilités et utilisations incorrectes de la cryptographie dans le monde réel est celle de Lazar et al. Les chercheurs ont étudié 269 vulnérabilités cryptographiques, c’est-à-dire tagguées "CWE-310 – Cryptographic Issue", rapportées dans la base de données CVE entre 2011 et 2014. Seulement 17 % des vulnérabilités étudiées provenaient du code source des bibliothèques cryptographiques, la majorité étant due à une mauvaise utilisation de ces bibliothèques.
Lazar et al ne sont pas les seuls à avoir identifié que de nombreuses vulnérabilités de sécurité sont dues à une mauvaise utilisation des API de cryptographie. Egele et al. ont analysé de manière statique 11 748 applications Android issues du Google Playstore pour détecter une mauvaise utilisation des API et ont constaté que 88 % de ces applications violent en fait au moins une des six règles de base de la cryptographie.
De même, Fahl et al. ont également constaté que l’utilisation abusive de l’API SSL rendait de nombreuses applications Android et iOS vulnérables aux attaques Man-in-the-Middle. Georgiev et al. montrent que même les principales applications web utilisent mal les bibliothèques de validation des certificats SSL/TLS, ce qui permet aux auteurs d’extraire des informations sensibles telles que les numéros de carte de crédit.
Une étude menée par Hazhirpasand et Ghafari sur la plateforme de bug bounty HackerOne montre que les questions soulevées par Lazar et al sont toujours pertinentes sept ans plus tard.
Trop complexe pour les développeurs
S’il est bien recommandé en matière de cryptographie de privilégier l’existant, force est de constater que cela n’est pas suffisant. Les bibliothèques cryptographiques restent difficiles à appréhender et utiliser par des non-spécialistes.
Kruger et al., Acar et al., 2017, Nadi et al., 2016 ont ainsi soulevé que les outils logiciels et la documentation de ces bibliothèques sont opaques et que les développeurs ont, dans leur grande majorité, du mal à les utiliser correctement.
Les développeurs déplorent une documentation encore trop pauvre, manquant d’exemples de code sûrs et faciles à utiliser, ainsi que le manque de fonctionnalités auxiliaires liées notamment à la gestion des clés (stockage, etc.).
Bien que la majorité des études porte sur les API Java et C/C++, d’autres analyses telles que celles de Wickert et al. montrent que les langages de plus haut niveau tel que Python ne sont pas épargnés. Les conclusions rejoignent celles des études précédentes : les API dont la sécurité est axée sur la facilité d’utilisation produisent un code beaucoup plus sûr.
Des vulnérabilités non cryptographiques
En 2021, Blessing et al ont analysé 8 des bibliothèques cryptographiques développées en C/C++ les plus utilisées et les failles les affectant entre 2010 et 2020 ; constituant ainsi un ensemble de 312 CVEs.
Contrairement à Lazar et al, cette étude fait ressortir l’importance de distinguer les logiciels de cryptographie et les vulnérabilités cryptographiques. En effet, les logiciels de cryptographie produisent une classe plus large de vulnérabilités qui ne sont pas uniquement de nature cryptographique. Heartbleed, par exemple, était une vulnérabilité au niveau des systèmes causée par une vérification des limites manquante. Lazar et al n’ont étudié que les vulnérabilités cryptographiques et ont donc exclu Heartbleed et un pourcentage significatif de vulnérabilités présentes dans les logiciels cryptographiques.
Ainsi, l’un de nos résultats les plus intéressants de l’étude de Blessing et al est que seulement 27,2 % des vulnérabilités dans les bibliothèques cryptographiques sont des problèmes cryptographiques, tels que définis par la NVD, tandis que 37,2 % des vulnérabilités sont des problèmes de sécurité de la mémoire, ce qui indique que les bogues au niveau des systèmes constituent une plus grande préoccupation de sécurité que les procédures cryptographiques réelles.
Ces recherches ont démontré, par une analyse empirique des bases de code critiques pour la sécurité, que la complexité est effectivement l’ennemi de la sécurité. Les bibliothèques cryptographiques étudiées ont produit des vulnérabilités à des taux allant jusqu’à une CVE pour chaque millier de lignes de code ajoutées, soit un taux environ trois fois supérieur à celui des logiciels non cryptographiques.
Conclusion
La cryptographie est un outil puissant, mais fragile : une petite erreur logicielle ou un mauvais usage de celle-ci peut compromettre la sécurité de l’ensemble d’un système.
Alors comment éviter que les mêmes erreurs se reproduisent ? L’effort doit être collectif : moins de complexité du côté des éditeurs de bibliothèques cryptographiques, un apprentissage et des automatismes du côté des développeurs, pourquoi pas sur la base d’un outillage.
Plusieurs des travaux cités dans cet article ont conduit à la publication d’outils d’analyse statique ou dynamique de code dédiés à la détection de mauvaises pratiques cryptographiques : cryptoguard, CogniCrypt, LICMA, CRYscanner, CryptoREX, MASC Framework, etc. Sans se reposer entièrement sur ces derniers, ils peuvent être une piste intéressante dans un processus de développement sécurisé.