Des chercheurs ont décrit une méthode que des acteurs malveillants pourraient utiliser pour introduire dans du code source des vulnérabilités invisibles aux yeux des examinateurs humains.
Dans un article publié cette semaine, deux chercheurs de l’université de Cambridge, au Royaume-Uni, ont écrit que cette méthode — qu’ils ont baptisée « Trojan Source » — pouvait essentiellement être exploitée contre la quasi-totalité des langages de programmation utilisés aujourd’hui et pourrait être efficace dans des attaques contre la chaîne d’approvisionnement similaires à celle lancée contre SolarWinds l’an dernier.
« Comme ces puissantes attaques contre la chaîne d’approvisionnement peuvent être facilement lancées à l’aide de ces techniques, il est essentiel que les organisations qui participent à une chaîne d’approvisionnement logicielle mettent en place des défenses », ont écrit Nicholas Boucher et Ross Anderson dans leur article. « Nous avons examiné des contre-mesures applicables à différents niveaux de la chaîne d’outils de développement logiciel : les spécifications du langage, le compilateur, l’éditeur de texte, le dépôt de code et le pipeline de compilation. »
Sur un site web, ils ont écrit que « si un adversaire parvient à introduire des vulnérabilités ciblées dans du code open source en trompant les examinateurs humains, les logiciels en aval hériteront vraisemblablement de la vulnérabilité ».
Les solutions à long terme viendront des compilateurs, dont la plupart se défendent déjà contre une attaque apparentée, ont-ils écrit.
Unicode est la clé
La clé consiste à utiliser des caractères de contrôle Unicode pour réordonner les jetons du code source au niveau de l’encodage, ont-ils écrit. Ces jetons réordonnés visuellement peuvent afficher une logique sémantiquement correcte, mais différente de celle présentée par l’ordre logique des jetons du code source.
Cependant, « les compilateurs et les interpréteurs respectent l’ordre logique du code source, et non son ordre visuel », ont-ils écrit.
La méthode Trojan Source permet aux cybercriminels de créer du code interprété d’une manière par les compilateurs et d’une autre par les examinateurs humains. Cela met en péril l’ensemble du code source, ont déclaré les chercheurs, précisant qu’ils disposaient de preuves de concept fonctionnelles pour des attaques dans un éventail de langages de programmation : C, C++, C#, JavaScript, Java, Rust, Go et Python. Ils ont ajouté que la même méthode fonctionnerait probablement avec d’autres langages modernes.
À lire également : Les meilleurs outils de débogage et de sécurité du code
Exploiter les jetons réordonnés
Les chercheurs ont également décrit un certain nombre de techniques permettant d’exploiter le réordonnancement visuel des jetons du code source, notamment les « retours précoces », qui « court-circuitent une fonction en exécutant une instruction return apparaissant visuellement à l’intérieur d’un commentaire », ont-ils écrit.
La « mise en commentaire » fait apparaître visuellement un commentaire comme du code, lequel n’est pas exécuté. Avec les « chaînes étirées », certaines parties de littéraux de chaîne apparaissent visuellement comme du code, ce qui produit le même effet que la mise en commentaire et entraîne l’échec des comparaisons de chaînes.
« L’attaque consiste à utiliser des caractères de contrôle intégrés dans des commentaires et des chaînes pour réordonner les caractères du code source d’une manière qui en modifie la logique », ont-ils écrit.
Cela peut se faire de deux façons. La première consiste à attaquer l’algorithme Unicode bidirectionnel (BiDi), qui est suivi sous le nom de CVD-2021-42574. L’algorithme détermine l’ordre d’affichage du texte. Il prend en charge les langues qui s’écrivent de gauche à droite, comme l’anglais et le russe, ainsi que celles qui s’écrivent de droite à gauche, comme l’arabe et l’hébreu.
« Les substitutions Bidi permettent même à des caractères appartenant à un seul système d’écriture d’être affichés dans un ordre différent de leur encodage logique », ont écrit Boucher et Anderson. « Ce fait a déjà été exploité pour dissimuler les extensions de fichiers de logiciels malveillants diffusés par e-mail et pour élaborer des exemples adverses destinés aux pipelines d’apprentissage automatique du traitement automatique du langage naturel [NLP]. »
Les chercheurs ont placé leurs travaux sous embargo pendant 99 jours … dans le cadre d’un vaste effort de divulgation coordonnée
Une autre attaque utilise des homoglyphe, c’est-à-dire des caractères visuellement presque identiques. Elle est suivie sous le nom de CVE-2021-42694.
Les chercheurs ont placé leurs travaux sous embargo pendant 99 jours afin de laisser le temps aux compilateurs, aux interpréteurs, aux éditeurs de code et aux dépôts de mettre en place des défenses dans le cadre d’un vaste effort de divulgation coordonnée.
Les attaques contre la chaîne d’approvisionnement
Les travaux des chercheurs pourraient déboucher sur de nouvelles attaques contre la chaîne d’approvisionnement, de plus en plus utilisées par les cybercriminels, comme l’a illustré l’attaque contre SolarWinds, au cours de laquelle un groupe basé en Russie a injecté du code malveillant dans un paquet de mise à jour du logiciel de surveillance et de gestion à distance Orion de l’entreprise, utilisé par ses clients. Kaseya et ses clients ont subi une attaque similaire.
Avec Trojan Source, « en injectant des caractères de substitution Unicode Bidi dans des commentaires et des chaînes, un adversaire peut produire du code source syntaxiquement valide dans la plupart des langages modernes, dans lequel l’ordre d’affichage des caractères présente une logique divergente de la logique réelle », ont écrit les chercheurs. « En pratique, nous transformons par anagramme le programme A en programme B. Une telle attaque pourrait être difficile à détecter pour un examinateur humain, car le code source affiché semble parfaitement acceptable. Si la modification de la logique est suffisamment subtile pour passer inaperçue lors des tests ultérieurs, un adversaire pourrait introduire des vulnérabilités ciblées sans être détecté. »
Mesures de protection du code
Jon Gaines, consultant senior en sécurité des applications chez nVisium, a déclaré à eSecurity Planet que Trojan Source révélait une surface d’attaque intéressante, ajoutant que les preuves de concept présentées par les chercheurs n’étaient pas réellement malveillantes.
« Cependant, entre les mains d’un attaquant ou d’un groupe sophistiqué capable de l’armer concrètement, nous aurions certainement affaire à une situation dangereuse », a déclaré Gaines. « Ce scénario démontre l’importance d’examiner le code source de manière proactive et il serait recommandé, en attendant, de ne pas copier-coller du code. Il vaut toujours mieux le réécrire soi-même ; vous pouvez également configurer votre IDE ou vos éditeurs de texte pour afficher les caractères Unicode. »
Selon Jake Williams, cofondateur et directeur technique de l’entreprise de réponse aux incidents BreachQuest, les problèmes décrits dans l’article sont sérieux, mais doivent être examinés dans leur contexte.
« Pour exploiter cette vulnérabilité, un acteur malveillant devrait pouvoir modifier du code source qui serait ensuite compilé sous forme binaire par une victime », a déclaré Williams à eSecurity Planet. « Cela est déjà grave en soi. Les vulnérabilités en question détournent les algorithmes de traitement Unicode afin de rendre les portes dérobées moins susceptibles d’être découvertes lors de l’examen du code source. Si vous n’examinez pas le code source à la recherche de vulnérabilités et de portes dérobées avant la compilation, cette divulgation de vulnérabilité ne change concrètement rien à votre sécurité. »
Il a également souligné que le traitement Unicode par les compilateurs suscitait déjà des inquiétudes. Cette étude a montré l’ampleur du problème, a-t-il déclaré.
Boucher et Anderson ont recommandé plusieurs mesures que les organisations peuvent prendre, notamment demander aux compilateurs, aux interpréteurs et aux pipelines de compilation prenant en charge Unicode de « générer des erreurs ou des avertissements pour les caractères de contrôle bidirectionnels indéterminés dans les commentaires ou les littéraux de chaîne, ainsi que pour les identifiants comportant des caractères confondables issus de plusieurs systèmes d’écriture ».
Ils ont également déclaré que les spécifications des langages devraient interdire les caractères de contrôle bidirectionnels non terminés dans les commentaires et les littéraux de chaîne, et que les éditeurs de code et les interfaces des dépôts devraient rendre perceptibles les caractères de contrôle bidirectionnels et les caractères confondables issus de plusieurs systèmes d’écriture au moyen de symboles visuels ou d’avertissements.
Alexey Vishnyakov, responsable de la détection des logiciels malveillants au sein de l’Expert Security Center de Positive Technologies, a déclaré que la vulnérabilité était réelle — mais difficile à exploiter.
« Un attaquant doit d’abord assembler une charge utile fonctionnelle à partir de fragments de code réarrangés, ce qui peut prendre des semaines, voire un an, selon la longueur du code du programme », a déclaré Vishnyakov dans un communiqué. « Il doit ensuite construire un gadget capable à la fois de faire fonctionner la charge utile et de la dissimuler — un autre projet qui prend beaucoup de temps.
« Cela concerne absolument tous les logiciels, puisque tout logiciel est écrit dans un langage de programmation. Mais pour le moment, la communauté de la sécurité n’a pas connaissance d’attaques utilisant cette technique. »
Pour aller plus loin : Les meilleurs outils de gestion des vulnérabilités