Un codeur anonyme a failli pirater une grande partie d’Internet. À quel point devrions-nous nous inquiéter ?

En dehors du monde des logiciels open source, peu de gens auraient probablement entendu parler de XZ Utils, un outil petit mais largement utilisé pour la compression de données dans les systèmes Linux. Mais à la fin de la semaine dernière, des experts en sécurité ont découvert une faille grave et délibérée qui pourrait rendre les ordinateurs Linux en réseau vulnérables aux attaques malveillantes.

La faille a depuis été confirmée comme étant un problème critique qui pourrait permettre à un pirate informatique averti de prendre le contrôle des systèmes Linux vulnérables. Étant donné que Linux est utilisé dans le monde entier sur les serveurs de messagerie et Web et sur les plates-formes d’applications, cette vulnérabilité aurait pu donner à l’attaquant un accès silencieux à des informations vitales conservées sur des ordinateurs à travers le monde, y compris potentiellement l’appareil que vous utilisez actuellement pour lire ceci.

Les vulnérabilités logicielles majeures, telles que le hack SolarWinds et le bug Heartbleed, ne sont pas nouvelles, mais celle-ci est très différente.

La tentative de piratage de XZ Utils a profité de la manière dont fonctionne souvent le développement de logiciels open source. Comme de nombreux projets open source, XZ Utils est un outil crucial et largement utilisé et il est maintenu en grande partie par un seul bénévole, travaillant pendant son temps libre. Ce système a généré d’énormes bénéfices pour le monde sous la forme de logiciels libres, mais il comporte également des risques uniques.

Open source et utilitaires XZ

Tout d’abord, un bref rappel sur les logiciels open source. La plupart des logiciels commerciaux, tels que le système d’exploitation Windows ou l’application Instagram, sont à code source fermé, ce qui signifie que personne, à l’exception de leurs créateurs, ne peut lire ou modifier le code source. En revanche, avec les logiciels open source, le code source est librement disponible et les utilisateurs sont libres d’en faire ce qu’ils veulent.

Les logiciels open source sont très courants, en particulier dans les détails des logiciels que les consommateurs ne voient pas, et extrêmement précieux. Une étude récente a estimé la valeur totale des logiciels open source utilisés aujourd’hui à 8 800 milliards de dollars américains.

Jusqu’à il y a environ deux ans, le projet XZ Utils était maintenu par un développeur appelé Lasse Collin. À cette époque, un compte utilisant le nom de Jia Tan a soumis une amélioration au logiciel.

Lire la suite : Du botnet aux malware : un guide pour décoder les mots à la mode en matière de cybersécurité

Peu de temps après, des comptes jusqu’alors inconnus sont apparus pour signaler des bugs et soumettre des demandes de fonctionnalités à Collin, le mettant ainsi sous pression pour qu’il engage un assistant pour maintenir le projet. Jia Tan était le candidat logique.

Au cours des deux années suivantes, Jia Tan s’implique de plus en plus et, on le sait désormais, introduit une arme soigneusement cachée dans le code source du logiciel.

Le code révisé modifie secrètement un autre logiciel, un outil de sécurité réseau omniprésent appelé OpenSSH, afin qu’il transmette le code malveillant à un système cible. En conséquence, un intrus spécifique pourra exécuter n’importe quel code de son choix sur la machine cible.

La dernière version de XZ Utils, contenant la porte dérobée, devait être incluse dans les distributions Linux populaires et déployée dans le monde entier. Cependant, il a été détecté juste à temps lorsqu’un ingénieur de Microsoft a enquêté sur quelques irrégularités mineures de mémoire sur son système.

Une réponse rapide

Que signifie cet incident pour les logiciels open source ? Eh bien, malgré les premières apparences, cela ne signifie pas que les logiciels open source ne sont pas sécurisés, peu fiables ou dignes de confiance.

Étant donné que tout le code est accessible au public, les développeurs du monde entier pourraient rapidement commencer à analyser la porte dérobée et l’historique de sa mise en œuvre. Ces efforts pourraient être documentés, distribués et partagés, et les fragments de code malveillant spécifiques pourraient être identifiés et supprimés.

Une réponse à cette échelle n’aurait pas été possible avec un logiciel à code source fermé.

Un attaquant devrait adopter une approche quelque peu différente pour cibler un outil à source fermée, peut-être en se faisant passer pour un employé de l’entreprise pendant une longue période et en exploitant les faiblesses du système de production de logiciels à source fermée (telles que la bureaucratie, la hiérarchie, le manque de clarté des rapports). lignes et mauvais partage des connaissances).

Cependant, s’ils parvenaient à créer une telle porte dérobée dans un logiciel propriétaire, il n’y aurait aucune chance d’auditer le code distribué à grande échelle.

Leçons à tirer

Ce cas est une occasion précieuse d’en apprendre davantage sur les faiblesses et les vulnérabilités d’un autre type.

Premièrement, cela démontre la facilité avec laquelle les relations en ligne entre utilisateurs anonymes et développeurs peuvent devenir toxiques. En fait, l’attaque dépendait de la normalisation de ces interactions toxiques.

La partie ingénierie sociale de l’attaque semble avoir utilisé des comptes anonymes pour culpabiliser et contraindre émotionnellement le responsable principal à accepter des ajouts de code mineurs, apparemment inoffensifs, sur une période de plusieurs années, le poussant ainsi à céder le contrôle du développement à Jia Tan.

Un compte utilisateur s’est plaint :

Vous ignorez les nombreux correctifs qui pourrissent sur cette liste de diffusion. En ce moment, vous étouffez votre repo.

Lorsque le développeur a déclaré avoir des problèmes de santé mentale, un autre compte a réprimandé :

Je suis désolé pour vos problèmes de santé mentale, mais il est important d’être conscient de vos propres limites.

Individuellement, de tels commentaires peuvent paraître inoffensifs, mais pris ensemble, ils peuvent devenir une foule.

Nous devons aider les développeurs et les responsables à mieux comprendre les aspects humains du codage et les relations sociales qui affectent, sous-tendent ou dictent la manière dont le code distribué est produit. Il y a beaucoup de travail à faire, notamment pour améliorer la reconnaissance de l’importance de la santé mentale.

Une deuxième leçon est l’importance de reconnaître l’obscurcissement, un processus souvent utilisé par les pirates informatiques pour rendre le code et les processus logiciels difficiles à comprendre ou à faire de l’ingénierie inverse. De nombreuses universités n’enseignent pas cela dans le cadre d’un cours standard de génie logiciel.

Troisièmement, certains systèmes peuvent encore exécuter les versions dangereuses de XZ Utils. De nombreux appareils intelligents populaires (tels que les réfrigérateurs, les appareils portables et les outils domotiques) fonctionnent sous Linux. Ces appareils atteignent souvent un âge auquel il n’est plus financièrement viable pour leurs fabricants de mettre à jour leurs logiciels, ce qui signifie qu’ils ne reçoivent pas de correctifs pour les failles de sécurité nouvellement découvertes.

Enfin, quel que soit l’auteur de l’attaque, certains ont émis l’hypothèse qu’il pourrait s’agir d’un acteur étatique qui a eu libre accès à diverses bases de code sur une période de deux ans, perpétrant une tromperie minutieuse et patiente. Même maintenant, cet adversaire apprendra de la façon dont les administrateurs système, les producteurs de distribution Linux et les responsables de la maintenance du code réagissent à l’attaque.

Où aller à partir d’ici ?

Les responsables de la maintenance du code du monde entier réfléchissent désormais à leurs vulnérabilités à un niveau stratégique et tactique. Ce n’est pas seulement leur code lui-même qui les préoccupera, mais aussi leurs mécanismes de distribution de code et leurs processus d’assemblage de logiciels.

Mon collègue David Lacey, qui dirige l’organisation à but non lucratif de cybersécurité IDCARE, me rappelle souvent que la situation à laquelle sont confrontés les professionnels de la cybersécurité est bien décrite dans une déclaration de l’IRA. À la suite de l’attentat à la bombe contre le Brighton Grand Hotel en 1984, l’organisation terroriste a affirmé avec froideur :

Aujourd’hui, nous n’avons pas eu de chance, mais n’oubliez pas que nous ne devons avoir de chance qu’une seule fois. Il faudra toujours avoir de la chance.