La découverte de la porte dérobée XZ révèle une attaque de la chaîne logistique Linux

Chronologie des faits

Selon de nombreux fournisseurs de cybersécurité et analystes des menaces, la porte dérobée a été créée à la suite d'une attaque d'ingénierie sociale élaborée et étalée sur plusieurs années. L'utilisateur GitHub JiaT75, également connu sous le nom de Jia Tan, était au centre de l'opération. Ce développeur a contribué à la bibliothèque XZ pendant deux ans, a gagné la confiance de la communauté des développeurs et a fini par obtenir des privilèges pour maintenir le dépôt XZ et fusionner les commits.

Selon une chronologie créée par le programmeur Evan Boehs, Tan a créé son compte GitHub en novembre 2021 et a créé une demande d'extraction dans libarchive qui a remplacé un morceau de code par une variante moins sûre sous couvert d'une modification du texte d'erreur. En avril 2022, Jia Tan a soumis un correctif à XZ via une liste de diffusion et un autre utilisateur, « Jigar Kumar » - peut-être un alias ou un co-conspirateur - a fait pression sur les responsables pour que le correctif soit fusionné.

Jigar Kumar a alors fait pression sur un mainteneur du projet XZ pour qu'il ajoute un autre mainteneur afin qu'il puisse librement faire des commits. Jia Tan a commencé à apporter des contributions régulières au projet à ce moment-là, et a apparemment gagné suffisamment de confiance pour fusionner son propre code au début du mois de janvier 2023. Jia Tan a ensuite, au fil des mois et jusqu'au début de l'année 2024, pris des mesures pour renforcer sa propre influence au sein du projet et construire l'infrastructure de la porte dérobée.

La porte dérobée a été finalisée au début de cette année avant d'être découverte en mars.

Référence CVE attribuée

La porte dérobée XZ s'est vue attribuer une référence CVE et figure dans la base de données des vulnérabilités du NIST, ce qui n'est pas habituel pour les logiciels malveillants.

« Grâce à une série de maquillages complexes, le processus de construction de liblzma extrait un fichier objet préconstruit d'un fichier test déguisé existant dans le code source, qui est ensuite utilisé pour modifier des fonctions spécifiques dans le code liblzma », peut-on lire dans la liste du NIST. « Il en résulte une bibliothèque liblzma modifiée qui peut être utilisée par n'importe quel logiciel lié à cette bibliothèque, interceptant et modifiant l'interaction des données avec cette bibliothèque ».

Bien qu'il s'agisse d'un incident complexe qui fait encore l'objet de recherches, Michael Skelton, vice-président de Bugcrowd chargé des opérations de sécurité et de la réussite des hackers, a qualifié l'attribution d'un CVE d'approche proactive et de précaution.

« Il est important de préciser que les CVE ne sont pas attribuées aux logiciels malveillants ou aux portes dérobées eux-mêmes, mais plutôt aux vulnérabilités que ces entités malveillantes pourraient exploiter », souligne-t-il. Dès lors, « en attribuant une CVE à une vulnérabilité suspectée mais non prouvée, la communauté reconnaît le potentiel d'exploitation et donne la priorité à la sécurité de l'écosystème, en veillant à ce que des précautions soient prises même en l'absence de preuve immédiate d'exploitabilité ».

Scott Caveza, ingénieur de recherche chez Tenable, a reconnu que la publication d'une CVE est moins habituelle dans ce cas, mais a déclaré que le choix de Red Hat d'en publier une « rend l'identification des systèmes affectés beaucoup plus facile ». Car « chaque distribution Linux, affectée ou non, peut répondre à ses clients avec un identifiant commun pour désigner cette porte dérobée, et les parties concernées n'ont pas à chercher dans une multitude de phrases possibles. Elles peuvent au contraire se référer à cette situation avec un identifiant CVE ».

Conséquences sur la sécurité des logiciels libres

Dans un billet de blog de Bugcrowd sur la porte dérobée, Michael Skelton a souligné les répercussions de la découverte et les retombées potentielles pour d'autres projets open source.

« L'une des conséquences de cette découverte est que Jia Tan a contribué non seulement à cette bibliothèque, mais aussi à d'autres, ce qui nécessite un effort d'examen plus important pour déterminer si d'autres composants peuvent également se trouver dans un état de vulnérabilité actuel », écrit-il. Mais ce n'est pas tout : « au-delà, la question est de savoir comment éviter ces problèmes dans la chaîne logistique - ou s'il est possible de les éviter. Les logiciels libres constituent l'épine dorsale de nombreux services et entreprises sur lesquels nous comptons, et tout ne peut pas être examiné de près au niveau de détail nécessaire pour éviter ces attaques ».

Pour Omkhar Arasaratnam, directeur général de l'Open Source Software Foundation, la nature des logiciels libres a permis de découvrir, de signaler et de traiter rapidement la porte dérobée, et que le nombre de systèmes affectés par la porte dérobée est « relativement bas ». Selon lui, « des situations comme celle-ci nous rappellent à tous que nous devons rester vigilants au sein de l'écosystème des logiciels libres ». Car « l'open source, ce sont des personnes bien intentionnées qui donnent de leur temps et de leurs talents pour aider à résoudre des problèmes, et malheureusement, cela peut être compromis ».

John Bambenek, président de la société de conseil en sécurité Bambenek Consulting, déplore pour sa part que « nous ne disposons pas d'outils performants pour traiter les vecteurs d'attaque introduits dans les logiciels libres couramment utilisés ». Toutefois, «  nous parvenons de mieux en mieux à détecter les activités malveillantes dans la nature, et comme ce problème a touché un grand nombre d'organisations à la fois, nous avons pu rapidement contenir la menace ». Il n'en reste pas moins qu'il y a  « des limites à ce que nous pouvons faire pour les logiciels maintenus par des bénévoles, et il est clair que nous devons trouver des moyens de nous améliorer rapidement, sinon cela se produira à nouveau ».