Introduction aux attaques contre la chaîne d'approvisionnement
Publié le 2 mai 2024 par Andrew Owen (6 minutes)
Le 28 mars, Andres Freund a découvert un code malveillant dans le paquet XZ Utils qui aurait pu compromettre la sécurité d’environ la moitié des serveurs sur l’internet. L’attaque était audacieuse par sa portée, sa planification et son calendrier, ce qui a conduit de nombreuses personnes à supposer qu’elle avait été menée par une agence d’État. Ce qui est vraiment terrifiant, c’est qu’elle a été découverte par accident par un développeur de bases de données. Les chercheurs en sécurité ne l’ont pas repérée.
Il s’agit peut-être de l’attaque de la chaîne d’approvisionnement la mieux exécutée que nous ayons vue décrite au grand jour, et c’est un scénario cauchemardesque : une personne malveillante, compétente et autorisée en amont dans une bibliothèque largement utilisée" —Filippo Valsorda
Qu’est-ce qu’une attaque de la chaîne d’approvisionnement? Il s’agit de la compromission d’un fournisseur ou d’un partenaire extérieur de confiance dans le but d’accéder à vos systèmes et à vos données. Les attaquants ciblent à la fois les logiciels commerciaux et les logiciels libres. On craint également que les logiciels provenant de certains pays contiennent des codes malveillants imposés par le gouvernement.
L’attaque XZ Utils visait les variantes Linux x86-64 dérivées de Red Hat et de Debian (y compris Ubuntu). Étant donné qu’il a été ajouté aux binaires publiés et qu’il n’était pas présent dans le code source, les architectures 32 bits et non Intel n’ont pas été touchées. Il est important de noter que les versions de Linux qui n’ont pas élevé les privilèges de XZ Utils en le liant à OpenSSH n’ont pas non plus été affectées. Dans la pratique, seules quelques distributions ont été touchées avant d’être repérées. Le code restait inactif jusqu’à ce qu’une clé de chiffrement spécifique soit utilisée, ce qui permettait de compromettre complètement le système. Pour les curieux, Ars Technica propose une description plus détaillée.
Mais la raison pour laquelle il est allé aussi loin est que XZ avait un seul mainteneur non rémunéré qui se désintéressait du projet. Une campagne coordonnée d’ingénierie sociale menée sur plusieurs années a permis de gagner la confiance du mainteneur et d’ajouter un faux compte en tant que second mainteneur, qui a fini par prendre la place du mainteneur initial. Après l’ajout de l’exploit, d’autres faux comptes ont été utilisés pour faire pression afin que le code compromis soit inclus dans la prochaine version de diverses distributions Linux.
Cela devrait souligner ce que les chercheurs en sécurité ont toujours su: les gens sont le maillon le plus faible. Comme l’a écrit Thom Holwerda: “Si nous disposons d’un certain nombre de moyens pour prévenir, découvrir, atténuer et corriger les failles de sécurité involontaires, il semble que nous n’ayons pratiquement rien mis en place pour empêcher les portes dérobées intentionnelles placées par des mainteneurs de confiance. Il s’agit là d’un véritable problème. La solution qu’il propose est la création d’une fondation dédiée à l’aide, au conseil et éventuellement à l’assistance financière et médicale des mainteneurs confrontés à des problèmes non liés au code.
Plus de dix ans se sont écoulés depuis la découverte du bogue de sécurité Heartbleed dans OpenSSL. L’industrie a réagi en créant la Core Infrastructure Initiative dans le cadre de la Fondation Linux pour financer les projets à risque. En août 2020, elle a été remplacée par la Open Source Security Foundation. Mais l’accent est mis sur les composants de sécurité comme OpenSSH. Depuis 2018, nous avons assisté à des attaques de la chaîne d’approvisionnement telles que Event-stream, ASUS, SolarWinds et Mimecast. Si elle avait réussi, XZ les aurait toutes éclipsées.
Lorsque j’étais dans l’industrie de la sécurité, j’ai vu un pivot de la prévention des intrusions vers la détection des intrusions. Si XZ n’avait pas été détecté, les systèmes de surveillance auraient joué un rôle crucial dans l’atténuation de ses effets. Fortinet, l’un des fournisseurs de ce type de logiciel, recommande ces mesures préventives:
J’ajouterais à cela: adopter un modèle de sécurité zéro confiance et mettre en place des sauvegardes redondantes et sécurisées (et effectuer régulièrement des tests de restauration).
Le 19 juillet 2024, CrowdStrike a démontré la faille de cette approche. Si une société de sécurité logicielle tierce de confiance diffuse une mise à jour qui met hors service l’infrastructure informatique et nécessite une récupération manuelle, il en résulte la plus grande panne informatique de l’histoire. Un fichier de 41 kilo-octets transmis aux systèmes utilisant Falcon Sensor sous Windows a affecté les compagnies aériennes, les aéroports, les banques, les diffuseurs, les services gouvernementaux, les hôpitaux, les hôtels, l’industrie manufacturière, les sociétés de logiciels (y compris Microsoft) et les marchés boursiers.
Lorsque l’objet même de la protection produit l’effet inverse, l’abus de confiance peut entraîner la disparition de l’entreprise, comme ce fut le cas pour le fabricant d’airbags Takata Corporation. Si CrowdStrike survit, c’est parce que personne n’est mort dans cet incident. Les criminels et les agences gouvernementales ont pris note de ce vecteur d’attaque potentiel. Il convient de rappeler que la Chine et la Russie n’ont pas été touchées, car elles dépendent beaucoup moins de Windows que la plupart des autres pays. Bien entendu, dans la foulée, des attaques par hameçonnage sont rapidement apparues pour tenter d’exploiter la situation.
En matière de sécurité informatique, l’acronyme CIA signifie Confidentialité, Intégrité et Accessibilité. C’est la troisième partie qui est généralement négligée. Si vous ne pouvez pas accéder à votre système, les deux autres n’ont pas d’importance. Cet événement soulèvera des questions sur la sagesse d’exécuter une infrastructure logicielle majeure sur des systèmes d’exploitation qui sont si vulnérables qu’ils risquent d’être rendus inopérants. Cette fois, c’est Windows qui a été touché, mais Linux et macOS ne sont pas à l’abri. Il y a une raison pour laquelle les systèmes de contrôle du trafic aérien fonctionnent plutôt sur des systèmes d’exploitation en temps réel.
Certains observateurs se sont interrogés sur la sagesse d’un déploiement un vendredi, mais lorsqu’il s’agit d’exploits de type “zero-day”, il faut être capable de se déployer en toute sécurité à n’importe quel moment et n’importe quel jour de la semaine. Certains commentateurs ont cherché à blâmer des individus, mais en fin de compte, il s’agit d’une défaillance de gestion de la part de CrowdStrike et de ses clients. Dans le cas de CrowdStrike, il semblerait qu’il s’agisse d’une défaillance du processus d’assurance qualité. Dans le cas des clients, il s’agit d’un manquement à l’obligation d’ajouter de la redondance aux systèmes critiques. Je crois me souvenir que l’aéroport de Bruxelles a été relativement épargné (jusqu’à ce que les avions commencent à reculer au mauvais endroit) parce qu’il disposait d’un système redondant sur lequel il pouvait basculer lorsque le système principal tombait en panne.
La leçon à tirer est simple : ne faites pas aveuglément confiance à vos fournisseurs et à votre réseau:
11. Ayez un plan de reprise ou de basculement validé pour vos systèmes critiques.
Image: Original par Claudio Schwarz.