Introduction aux attaques contre la chaîne d'approvisionnement

illustrations illustrations illustrations illustrations illustrations illustrations illustrations
post-thumb

Publié le 2 mai 2024 par Andrew Owen (4 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:

  1. Vérifier l’infrastructure informatique parallèle non approuvée.
  2. Disposer d’un inventaire actualisé et efficace des actifs logiciels.
  3. Évaluer le niveau de sécurité des fournisseurs.
  4. Traiter la validation du risque fournisseur comme un processus continu.
  5. Utiliser des outils de protection côté client.
  6. Utiliser des solutions de détection et de réponse des points finaux (EDR).
  7. Déployer des politiques d’intégrité du code rigoureuses afin que seules les applications autorisées puissent être exécutées.
  8. Maintenir une infrastructure de construction et de mise à jour hautement sécurisée.
  9. Créer des outils de mise à jour de logiciels sécurisés dans le cadre du cycle de vie du développement logiciel.
  10. Développer un processus de réponse aux incidents.

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).

Image: Original par Claudio Schwarz.