Qu'est-ce que Trojan Source et comment s'infiltre-t-il dans votre code source ?

Début novembre, l'Université de Cambridge a publié ses recherches intitulées Trojan-Source. Ces travaux se concentrent sur la manière dont des portes dérobées peuvent être dissimulées dans le code source et les commentaires à l'aide de caractères de formatage directionnel. Ceux-ci permettent de concevoir un code dont la logique est interprétée différemment par le compilateur et par un relecteur humain.

Cette vulnérabilité est nouvelle, bien que l'Unicode ait déjà été utilisé à des fins malveillantes par le passé, notamment pour masquer la véritable extension d'un fichier en inversant l'ordre de la dernière partie du nom de fichier. Les recherches récentes ont révélé que de nombreux compilateurs ignorent les caractères Unicode dans le code source sans avertissement, alors que les éditeurs de texte, y compris les éditeurs de code, peuvent réorganiser les lignes contenant des commentaires et du code en fonction de ces caractères. L'éditeur peut donc afficher le code et les commentaires différemment, et dans un ordre différent de celui analysé par le compilateur, allant jusqu'à inverser le code et les commentaires.

Poursuivez votre lecture pour en savoir plus. Ou, si vous souhaitez passer à l'action et tester une simulation de piratage Trojan Source, lancez-vous dans notre mission publique gratuite pour en faire l'expérience par vous-même.

Texte bidirectionnel

L'une de ces attaques Trojan-Source utilise l'algorithme Unicode Bidi (bidirectionnel), qui gère l'assemblage de textes ayant un ordre d'affichage différent, comme l'anglais (de gauche à droite) et l'arabe (de droite à gauche). Des caractères de formatage directionnel peuvent être utilisés pour réorganiser le regroupement et l'ordre d'affichage des caractères.

Le tableau ci-dessus contient certains des caractères de remplacement Bidi pertinents pour cette attaque. Prenons par exemple :

RLI e d o c PDI

L'abréviation RLI signifie Right-to-Left Isolate. Elle isole le texte de son contexte (délimité par PDI, Pop-Directional-Isolate), et le lit de droite à gauche. Ce qui donne :

c o d e

Cependant, les compilateurs et les interpréteurs ne traitent généralement pas les caractères de contrôle de formatage, y compris les remplacements Bidi, avant l'analyse du code source. S'ils ignorent simplement les caractères de formatage directionnel, ils analyseront :

e d o c

Du vieux vin dans de nouvelles bouteilles ?

Bien sûr, il n'y a rien de nouveau sous le soleil. Par le passé, des caractères de formatage directionnel ont été insérés dans des noms de fichiers pour dissimuler leur nature malveillante. Une pièce jointe à un e-mail affichée sous le nom « myspecialexe.doc » pourrait sembler innocente, sans le caractère RLO (Right-to-Left override) présent, qui révèle que le nom réel est « myspecialcod.exe ».

L'attaque Trojan Source insère des caractères de formatage directionnel dans les commentaires et les chaînes de caractères présents dans le code source, car ils ne génèrent aucune erreur de syntaxe ou de compilation. Ces caractères de contrôle modifient l'ordre d'affichage de la logique du code, amenant le compilateur à lire quelque chose de totalement différent de ce qu'un humain lirait.

Par exemple, un fichier contenant les octets suivants dans cet ordre :

sera réordonné comme suit par les caractères de formatage directionnel

ce qui entraîne un rendu du code comme celui-ci si les caractères de formatage directionnel ne sont pas explicitement mis en évidence :

Le caractère RLO inverse l'accolade fermante en accolade ouvrante, et vice versa sur la dernière ligne. L'exécution de ce code afficherait : « You are an admin ». La vérification de l'administrateur était mise en commentaire, mais les caractères de contrôle donnent l'impression qu'elle est toujours active.

(Source : https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)

Quelles pourraient en être les conséquences pour vous ?

De nombreux langages sont vulnérables à cette attaque : C, C++, C#, JavaScript, Java, Rust, Go et Python, et il est probable qu'il y en ait d'autres. Si un développeur expérimenté peut s'étonner de voir des caractères de formatage directionnel dans un code source, un novice pourrait simplement hausser les épaules sans y prêter attention. De plus, la visualisation de ces caractères dépend fortement de l'IDE, il n'est donc jamais garanti qu'ils soient détectés.

Mais comment cette vulnérabilité peut-elle s'introduire dans le code source ? Tout d'abord, cela peut arriver lors de l'utilisation de sources peu fiables, où des contributions malveillantes passent inaperçues. Ensuite, par un simple copier-coller de code trouvé sur Internet, une pratique courante chez les développeurs. La plupart des organisations dépendent de composants logiciels tiers. Cela soulève la question de la confiance que nous pouvons accorder à ce code. Comment détecter les backdoors cachées ?

Qui est responsable ?

D'une part, les compilateurs et les pipelines de build devraient interdire les lignes de code contenant plusieurs directions, sauf si elles sont strictement limitées aux chaînes et aux commentaires. Notez qu'un caractère de formatage directionnel dans un commentaire peut, s'il n'est pas fermé, prolonger un changement de direction jusqu'à la fin de la ligne. En général, les éditeurs de code devraient afficher et mettre en évidence les caractères Unicode suspects, comme les homoglyphes. Depuis novembre, GitHub affiche un avertissement sur chaque ligne contenant du texte bidirectionnel, sans toutefois localiser précisément les caractères. Cela peut laisser passer des changements de direction malveillants.

La sensibilisation des développeurs et des relecteurs de code est essentielle, c'est pourquoi nous avons créé un guide illustrant cette vulnérabilité. Ce guide est actuellement disponible pour Java, C#, Python, Go et PHP.

Pour en savoir plus, essayez notre simulation (missions publiques) de Trojan Source, et consultez les recherches sur Trojan Source.

Simulation en Java

Simulation en C#

Simulation en PHP

Simulation en GO

Simulation en Python