Il ne se passe pour ainsi dire pas une semaine sans qu’une nouvelle vulnérabilité ne mette en évidence la fragilité des interdépendances logicielles qui composent la chaîne d’approvisionnement logicielle.
Une grande partie du développement logiciel s’appuie sur les avantages des plateformes open source et des fournisseurs tiers pour fournir des résultats dans les délais. De nombreuses personnes et organisations assurent la maintenance de ces bases de code.
Si vous prenez en compte tous les composants dont vous avez besoin pour vos logiciels, vous obtenez une chaîne assez longue, et ces composants ont eux aussi des dépendances. Le moindre maillon faible peut compromettre l’ensemble de la chaîne d’approvisionnement logicielle et mettre votre entreprise en danger. SolarWinds et Kaseya sont deux exemples récents et très médiatisés d’attaques visant la chaîne d’approvisionnement logicielle, et les clients des deux fournisseurs ont été compromis. L’ampleur des dépendances et des risques est vertigineuse.
Des dépendances logicielles complexes
Les applications modernes comptent des centaines de dépendances, dont de nombreux composants open source. En tant que développeurs, nous n’écrivons pas la majeure partie du code utilisé dans nos logiciels et applications. Cela peut créer des risques de sécurité, car vous ne pouvez pas contrôler totalement du code que vous n’avez pas écrit ni maintenu.
Vous êtes en sécurité tant que toutes les dépendances le sont. Malheureusement, les vulnérabilités non corrigées des logiciels sont très courantes et peuvent parfois entraîner des attaques visant la chaîne d’approvisionnement lorsque les hackers les exploitent.
Pire encore, même des fournisseurs sécurisés peuvent devenir vulnérables à la suite de mises à jour défectueuses, ce qui est difficile à détecter. Lors d’attaques visant la chaîne d’approvisionnement, les hackers n’ont pas besoin d’obtenir un accès de validation pour compromettre la base de code. Vos pipelines CI/CD déploieront pour eux les logiciels défectueux du fournisseur en production.
Au bout du compte, peu importe que la vulnérabilité ait été ajoutée intentionnellement pour diffuser une faille de sécurité ou qu’elle soit due à une simple erreur commise par un développeur innocent. Le résultat est le même.
À lire aussi : SBOM : sécuriser la chaîne d’approvisionnement logicielle
Comment les hackers compromettent la chaîne d’approvisionnement
Cette année, Microsoft a publié un livre blanc consacré à une nouvelle technique appelée « confusion des dépendances », également connue sous le nom d’attaque par substitution, qui se concentre sur le processus de création d’applications dans des environnements d’entreprise de confiance.
Un projet peut obtenir ses composants auprès de plusieurs sources. Il existe des dépôts de code privés et publics.
Si les hackers découvrent le nom de l’un des dépôts privés, ils peuvent créer des dépôts publics portant le même nom et y téléverser leur version de ce qui est censé être une bibliothèque interne. Le gestionnaire de paquets peut se perdre parmi les différents flux et télécharger la version publique au lieu de celle du dépôt interne, car le dépôt public possède le numéro de version le plus élevé.
Parfois, vous pouvez obtenir directement ces informations en production, par exemple :
https://website.com/package.json
Le fichier package.json est l’endroit où npm ou yarn stockent les noms et les versions des paquets installés. Il ne devrait pas être accessible sur le Web. Malheureusement, même lorsque ce fichier n’est pas accessible publiquement, les hackers peuvent tout de même obtenir des informations si les développeurs ont oublié de désactiver les fichiers de mappage des sources en production. Ces fichiers .map servent généralement au débogage de JavaScript et contiennent plusieurs références au dossier node_modules.
Les attaquants peuvent utiliser d’autres techniques, comme le typosquatting. Ils publient des paquets publics dont les noms sont proches de ceux de paquets populaires, en attendant que des développeurs mal orthographient une dépendance dans leur package.json ou composer.json.
Une autre technique connue consiste à soumettre des pull requests piégées. Les hackers dissimulent parfois du code malveillant dans des corrections de bugs apparemment légitimes. Les mainteneurs peuvent valider ces modifications et fusionner le code dans la branche principale, ce qui entraîne des déploiements compromis en production.
Quelle que soit la méthode employée, la compromission des mécanismes de mise à jour devient de plus en plus fréquente dans les attaques visant la chaîne d’approvisionnement logicielle.
À lire aussi : Principaux outils de débogage et de sécurité du code
Les attaques SolarWinds et Kaseya
En 2020, des acteurs sophistiqués de la menace ont réussi à compromettre Orion, le produit SolarWinds le plus utilisé, afin de déployer des logiciels malveillants dissimulés dans une mise à jour. L’incident a été rebaptisé SUNBURST.
SolarWinds est un acteur majeur des systèmes de gestion des réseaux et compte des centaines de milliers de clients, dont le département américain de la Défense. Les produits de l’entreprise automatisent de nombreuses activités, comme l’envoi de mises à jour et de correctifs aux utilisateurs. Bien que moins de 100 installations aient finalement été touchées, environ 18 000 étaient potentiellement vulnérables à cette attaque.
En compromettant le canal de mise à jour utilisé par Orion au moyen d’un fichier .DLL signé numériquement et malveillant (SolarWinds.Orion.Core.BusinessLayer.dll), les hackers ont réussi à exfiltrer des documents critiques de différentes agences et entreprises.
Le fichier .DLL est resté dormant pendant plusieurs jours, puis s’est connecté à plusieurs serveurs de commande et de contrôle pour recevoir des instructions supplémentaires, comme le transfert de fichiers et l’énumération du système. Les hackers ont également déployé une version personnalisée de Cobalt Strike sur les machines ciblées.
Le gouvernement américain a attribué cette activité à des acteurs de la menace associés au Service russe de renseignement extérieur (SVR). La Cybersecurity and Infrastructure Security Agency (CISA) des États-Unis a ordonné aux agences fédérales de supprimer les produits SolarWinds et d’enquêter.
Cependant, cette mesure n’a pas complètement éliminé la menace, car les autorités ne pouvaient pas dire si elles avaient ou non éradiqué leurs adversaires, faisant de ces attaquants une menace persistante avancée (APT).
En juillet 2021, des acteurs de la menace ont ciblé Kaseya, qui fournit divers produits informatiques, notamment des outils de gestion des réseaux et des terminaux, des services de conformité et des plateformes d’automatisation. Ses nombreux clients comprennent des fournisseurs de services managés qui servent d’autres entreprises, ce qui place Kaseya au cœur de la chaîne d’approvisionnement.
Le groupe de menace REvil a exploité une vulnérabilité dans une interface Web qui permettait de contourner les processus d’authentification, de téléverser des charges utiles et d’injecter à distance de fausses commandes SQL. Tout client connecté au serveur VSA de confiance exécutait les tâches sans générer d’alerte ni demander d’identifiants. C’est pourquoi les hackers ont ciblé Kaseya.
Le groupe de rançongiciel a demandé l’équivalent de 70 millions de dollars en bitcoins pour fournir un décrypteur et permettre aux entreprises de récupérer leurs fichiers. Kaseya a dû arrêter ses serveurs et avertir ses clients dans le monde entier. L’entreprise a demandé l’aide de la CISA et du FBI, mais le mal était fait.
À lire aussi : Meilleurs outils de gestion des risques liés aux tiers (TPRM)
Comment atténuer les attaques visant la chaîne d’approvisionnement
En raison des dégâts considérables qu’un groupe de la menace peut infliger depuis une seule source, les attaques visant la chaîne d’approvisionnement sont là pour durer, et l’importante chaîne d’interdépendances logicielles et informatiques n’est pas près de changer non plus. Parmi les rares éléments encourageants, un observateur du secteur constate une amélioration des défenses, ce qui pourrait améliorer quelque peu la situation.
Il est impossible d’empêcher totalement une attaque visant la chaîne d’approvisionnement de se produire, mais cela ne signifie pas que vous ne pouvez pas prendre de mesures préventives. Voici plusieurs actions qui peuvent vous aider :
- Adoptez une politique plus stricte à l’égard des fournisseurs. Ne vous approvisionnez pas auprès de plusieurs registres privés lorsqu’un seul suffit.
- Lorsque vous enregistrez un dépôt privé, enregistrez un dépôt public portant le même nom afin d’éviter le typosquatting.
- Maintenez tous les logiciels à jour, même si le processus de mise à jour constitue désormais lui aussi un risque.
- Sécurisez tous les fichiers de configuration et ne les déployez jamais en production ou, à défaut, limitez-en l’accès.
- Soyez extrêmement vigilant avec les interfaces de gestion informatique. Les comptes privilégiés disposant d’un niveau d’accès très élevé doivent être peu nombreux.
- Mettez en place plusieurs niveaux de défense et utilisez des outils de supervision tels que SIEM ou SOAR pour détecter rapidement les comportements suspects.
- Segmentez vos réseaux. Ne laissez pas une compromission à un niveau inférieur exposer l’ensemble du système.
À lire ensuite : Principaux outils de gestion des actifs informatiques pour la sécurité