Au cours des dernières années, nous avons constaté une augmentation massive des attaques de type supply chain. Comment se définit une attaque de ce type ? Comment s’en prémunir ? Le point.
Une attaque de la supply chain logicielle est un type d'attaque de cybersécurité où des acteurs malveillants introduisent du code ou des composants dans un logiciel ou un matériel jugé de confiance. L'objectif d'une telle attaque est de pouvoir infiltrer des organisations situées en aval, c'est-à-dire utilisatrices du composant affecté. Jusqu’à très récemment, les attaques de supply chain se concentraient sur le matériel, mais dorénavant, avec un certain nombre d'incidents très médiatisés, nous avons vu le problème se déplacer vers les logiciels.
Cet article examine spécifiquement les attaques supply chain liées aux logiciels et s'appuie sur des exemples récents pour montrer ce que les entreprises peuvent faire pour se protéger de telles attaques.
Pour comprendre ce type d'attaque, nous devons nous familiariser avec l’idée que les applications actuelles ne sont pas des monolithes. Elles sont constituées de centaines de blocs, de bibliothèques et de paquets open source, d'outils SaaS, de systèmes de déploiement, d'infrastructures cloud, etc. La situation se complique encore davantage, car chacun de ces éléments est également construit à partir d'éléments différents.
Si vous réfléchissez en termes de couches, un logiciel peut avoir des centaines de couches, chaque composant dépendant du précédent jusqu'au set d'instructions du CPU. Selon Eric Doerr, "Le monde est de plus en plus interconnecté chaque jour, mais en matière de sécurité, nous n'agissons pas comme s'il était interconnecté" (Black Hat 2019). Ce qui rend le risque d’attaque de supply chain si préoccupant, c'est que les organisations qui sont impactées par celle-ci sont souvent impuissantes à l'empêcher.
Vous avez le contrôle de votre code source, un certain contrôle sur les composants et les outils que vous choisissez d'utiliser, mais presque aucun contrôle sur les composants et les outils que ces même composants ont choisi.
Cependant, vous pouvez réduire le risque et dans cet article, nous allons examiner six mesures que vous pouvez prendre pour limiter à la fois l’exposition et les dommages potentiels d'une telle attaque.
Voici une illustration des multiples surfaces d'attaque :
"Nous comptons tous sur le fait que la supply chain logicielle soit totalement immunisée, mais la réalité est qu'elle ne l'est pas" explique Jeff Moss toujours dans Black Hat 2021.
Il existe de nombreux types d'attaques de supply chain qui ciblent différents composants pour rentrer dans une organisation. Nous allons examiner trois exemples récents de ces types d'attaques.
1. SolarWinds : attaque via un système de confiance avec accès privilégié
On ne peut pas écrire un article sur les attaques de supply chain logicielle sans évoquer l'attaque de SolarWinds. Elle est devenue en quelque sorte iconique pour ce genre d’attaques. Dans le cas de SolarWinds, l'attaque a ciblé un service d’infrastructure (SolarWinds Orion) disposant de privilèges élevés d’accès au réseau au sein des systèmes clients. Cette attaque est l'un des pires scénarios dans lequel le système compromis était non seulement utilisé par des dizaines de milliers de clients, tels que l'armée et d'autres secteurs du gouvernement, mais aussi parce que le logiciel avait un accès de niveau administrateur sur les réseaux sur lesquels il était installé.
Le logiciel Orion a été compromis dès septembre 2019. Les premières traces de code utilisées par les attaquants pour tester l'intrusion ont été injectées dans le code en octobre 2019. Ce n'est qu'en février 2020 que le code malveillant, connu sous le nom de Sunburst, a été injecté avant d’être déployé auprès de ses 18000 utilisateurs un mois plus tard.
L'attaque Sunburst a permis aux attaquants d'accéder aux clients de SolarWinds. Parmi les clients touchés, citons les ministères de la Sécurité Intérieure, du commerce et du Trésor américains, FireEye, Microsoft, Intel, Cisco et Deloitte, pour n'en citer que quelques-uns.
En ciblant le logiciel SolarWinds et en exploitant une faille de sécurité (qui fait encore débat), les attaquants ont pu accéder à certaines des organisations les mieux protégées au monde. Nombre de ces organisations étaient considérées comme "inviolables" (bien que tout professionnel de la sécurité digne de ce nom vous dira que c'est impossible), ou du moins disposaient de protections de sécurité de pointe. Mais ces protections ont été contournées en exploitant une partie de leur de supply chain logicielle qui disposait d'un accès privilégié ; elles ont pu pénétrer dans ces organisations inviolables et rester non détectées pendant une longue période.
2. Codecov : attaque par le biais d'outils de déploiement et de test
Ensuite, nous allons examiner une attaque dans les outils de déploiement de logiciels, plus précisément dans l'environnement CI/CD. Si vous n'êtes pas familier avec le pipeline CI/CD (continuous integration / continuous deployment), il s'agit d'un processus par lequel un logiciel peut être testé automatiquement avant d'être automatiquement déployé. C'est devenu un élément fondamental de la de supply chain logicielle et les organisations utilisent un certain nombre d'outils différents pour tester leurs logiciels, ce qui se produit généralement chaque fois qu'un nouveau fragment de code est poussé vers la branche de production d'un dépôt.
L'un de ces outils, encore une fois utilisé par des dizaines de milliers de clients, est Codecov, un outil de couverture de code qui permet aux utilisateurs de savoir quelle partie de leur application a été testée dans leur environnement de CI. Comme cet outil se trouvait dans l'environnement de CI, il avait accès aux secrets (ou informations d'identification) que l'application utilisait lorsqu'elle était testée. Par exemple, il devait avoir accès aux bases de données, aux services tiers et aux dépôts de code pour pouvoir tester l'application.
Dans l'exemple de Codecov, les attaquants ont d'abord pu accéder au dépôt de code privé de Codecov et injecter du code malveillant dans son code source. Ce code malveillant ne comportait qu'une ligne et faisait quelque chose de très simple : Il prenait les secrets de l'environnement de CI (tels que les tokens git) et les envoyait au serveur distant de l'attaquant. Autrement dit, il exfiltrait les informations d'identification utilisées pour construire et tester une application vers un serveur externe.
L'attaquant a ainsi pu accéder aux dépôts de code privés de nombreux clients de Codecov, dont Twilio Rapid7, HashiCorp et Monday.com, pour n'en citer que quelques-uns. Les dépôts de code privé sont devenus des cibles privilégiées pour les attaquants car ils contiennent souvent des informations sensibles, y compris des secrets. Dans certains cas, avec le bon accès, les attaquants peuvent même injecter du code malveillant en utilisant ces tokens.
3. Eventstream : attaque par le biais des dépendances logicielles
Pour notre dernier exemple, nous allons nous intéresser aux dépendances des logiciels open source. Presque toutes les applications logicielles modernes utilisent des dépendances open source. La faille Log4J vient encore de nous montrer à quel point l’emploi de ces dernières était répandu, et même largement majoritaire par rapport au code propriétaire, dans l’ensemble des logiciels et services du web.
Une étude de Synopsys montre que 91% des applications modernes contiennent du code open source. Pouvoir utiliser ce code open source est incroyablement utile car cela signifie que les ingénieurs n'ont pas besoin de reconcevoir les composants pour chaque application qu'ils construisent et peuvent plutôt se concentrer sur les composants innovants.
Si un attaquant peut compromettre une dépendance, il peut atteindre l'étape critique appelée accès initial. Le cas d'EventStream en est un bon exemple.
Ce code était une boîte à outils pour faciliter l'implémentation des streams dans Node.js, il était incroyablement populaire et était utilisé par des millions d'applications. Cependant, cet EventStream lui-même avait des dépendances, notamment un module appelé FlatMap. Dans ce cas, un attaquant s'est fait passer pour un mainteneur de FlatMap et a fini par s'approprier le module open source. L'attaquant a ensuite injecté du code malveillant dans le module, le transformant en une arme pour cibler les utilisateurs en aval. Cela lui a également donné une porte dérobée vers EventStream et, finalement, vers les utilisateurs d'EventStream. L'attaquant a donc pu accéder à des cibles en compromettant une dépendance d'une dépendance.
Maintenant que nous comprenons les différentes façons dont une attaque de supply chain logicielle peut se produire, voyons comment nous pouvons la renforcer et nous protéger contre les attaques. La difficulté de ce type d'attaque est que, même si vous pouvez prendre des mesures pour vous protéger, vous n'êtes souvent qu'un simple passager.
1. N'utilisez que des dépendances de confiance dans votre application
Lorsque vous choisissez les dépendances et les modules à utiliser dans votre application, vous devez vous assurer que vous utilisez des logiciels qui :
3. Analysez les logiciels open source à la recherche de vulnérabilités connues
Les logiciels d'analyse des logiciels open sources, ou logiciels OSS, comme Snyk ou WhiteSource sont essentiels pour renforcer la supply chain logicielle. Ces logiciels recherchent les dépendances que votre code utilise et les comparent à leurs vastes bases de données de code et de versions vulnérables pour voir si votre application présente des vulnérabilités connues. Si une dépendance présente une vulnérabilité connue, en particulier si elle est classée comme critique, ces logiciels peuvent même, dans de nombreux cas, la mettre automatiquement à jour vers la dernière version sûre. Si toutefois aucune mise à jour n'est disponible, il est extrêmement important que vous utilisiez un module ou du code différent, car c'est un signe que ce logiciel n'est plus maintenu.
3. Patchez intelligemment (régulièrement et non instantanément)
Si vous avez déjà lu des articles sur la sécurité, vous y trouverez généralement une note vous demandant de mettre à jour ou de patcher vos systèmes régulièrement. C'est bien sûr logique, vous voulez la dernière version afin d'être sûr que les vulnérabilités découvertes ne sont plus des menaces.
Si cela est vrai, cela ne signifie pas que vous devez mettre à jour immédiatement. Cela peut sembler contre-intuitif, mais si nous examinons tous les exemples présentés dans cet article, la seule similitude entre eux est que si les utilisateurs n'avaient pas mis à jour immédiatement, ils n'auraient pas été affectés.
Avant que vous ne criiez au scandale, je ne préconise pas de ne pas appliquer de correctifs, ou de le faire de manière irrégulière, mais vous devez y réfléchir. Liran Tal, developer advocate chez Snyk, a déclaré qu'il faut environ 60 jours pour que les vulnérabilités soient découvertes, signalées et corrigées. Cela correspond aux exemples donnés dans cet article. En gardant cela à l'esprit, vous devez créer une politique de correction intelligente qui vous permettra de passer immédiatement à la dernière version si des failles de sécurité ont été identifiées dans des systèmes dépendants et, sinon, de respecter une période d'attente initiale.
Les logiciels OSS peuvent vraiment vous aider dans cette démarche, ils vous informent immédiatement des vulnérabilités dans les dépendances et si un correctif est disponible, ce qui signifie que vous pouvez maintenir une bonne sécurité sans mettre automatiquement tout à jour dès que possible.
4. Segmentez votre réseau
Si un attaquant peut accéder à votre organisation par le biais d'une attaque de supply chain logicielle, il voudra se déplacer rapidement dans différentes zones de votre réseau. La segmentation du réseau est un moyen efficace de limiter le rayon d'action en cas d'attaque.
Elle consiste à diviser un grand réseau en petits sous-réseaux dont l'interconnexion est limitée. En contrôlant les flux de trafic entre les différents sous-réseaux et en limitant les mouvements latéraux des attaquants, la segmentation du réseau empêche les utilisateurs non autorisés d'accéder aux données de l'entreprise.
Voici quelques méthodes courantes de segmentation d'un réseau :
5. Mettez en œuvre une authentification avancée et une approche de moindre privilège
Il existe un concept de sécurité appelé confiance zéro. Il signifie que même si une personne possède des informations d'authentification, nous ne lui faisons pas confiance. Il s'agit par exemple d'utiliser l'authentification multifactorielle et de limiter les adresses IP qui peuvent accéder aux systèmes. Dans le cas d'une attaque de supply chain logicielle, nous voulons limiter la confiance donnée à l’attaquant, mettre en œuvre une authentification forte en utilisant les principes de confiance zéro qui peuvent arrêter un attaquant dans son élan.
Il est également important de s'assurer que nous utilisons le principe du moindre accès, ce qui signifie que les utilisateurs et les services n'ont qu'un accès minimal à des données et services supplémentaires. Comme un attaquant peut lancer une attaque à partir d'un système de confiance, souvent même en utilisant les principes de confiance zéro, nous ne pouvons pas le détecter et le bloquer, mais nous pouvons limiter la quantité d'informations auxquelles il a accès.
5. Assurez-vous que vos dépôts de code sont exempts de secrets
C'est devenu un classique pour les attaquants de cibler les dépôts de code et les serveurs de sauvegarde par ce type d'attaques. C'est exactement ce qui s'est passé dans le cas de Codecov où les attaquants ont ciblé les dépôts git. En effet, ces derniers constituent le point d'accès initial idéal pour trouver les informations d'identification permettant à l'attaquant de s'authentifier et de s'introduire plus profondément dans une organisation.
Nous devons nous assurer que ces systèmes sont exempts d'informations sensibles pouvant être utilisées par les attaquants. Il s'agit notamment de secrets tels que les clés API et les informations d'identification des bases de données. Le "Secret Sprawl", la distribution non désirée de ces secrets, est un problème majeur dans les applications modernes et les attaquants s'en servent pour se déplacer latéralement, élever leurs privilèges et accéder à des données sensibles.
En réalité, même si nous prenons toutes les précautions et mettons en œuvre les meilleures pratiques, nous ne pouvons pas toujours empêcher une attaque de supply chain logicielle, nous devons donc nous assurer que nous ne laissons aucun cadeau aux attaquants.
Vous pouvez lire ici pourquoi les secrets dans Git sont un si gros problème. L'utilisation d'outils d'analyse des secrets est essentielle, ils effectueront une analyse historique complète des dépôts, y compris leur historique, et continueront à les analyser en temps réel pour s'assurer qu’ils ne contiennent jamais de secrets.
Il est également fondamental de déployer une solution de gestion des secrets pour vous aider à stocker, distribuer et faire votre rotation de secrets en toute sécurité. On peut considérer ceci comme une préoccupation de grande entreprise, mais quelle que soit l'échelle, il est fondamental de mettre en place une telle solution.
Les attaques de supply chain logicielles ont augmenté de façon spectaculaire et personne n'est à l'abri de ces attaques. L'architecture distribuée que nous utilisons pour construire des applications offre aux attaquants l'occasion idéale de cibler des centaines, voire des milliers d'organisations en même temps.
Cette évolution a complètement changé la situation économique des attaquants, qui peuvent désormais affecter beaucoup plus de ressources via la supply chain logicielle qu'en ciblant une seule entreprise.
Bien qu'il soit impossible de ne jamais être victime d'une telle attaque, nous pouvons mettre en œuvre certaines bonnes pratiques pour réduire le risque et les dommages potentiels causés.
Une attaque de la supply chain logicielle est un type d'attaque de cybersécurité où des acteurs malveillants introduisent du code ou des composants dans un logiciel ou un matériel jugé de confiance. L'objectif d'une telle attaque est de…
Je gère mes abonnements push
Les informations recueillies sont destinées à CCM Benchmark Group pour vous assurer l’envoi de votre newsletter.
Elles seront également utilisées sous réserve des options souscrites, par CCM Benchmark Group à des fins de ciblage publicitaire et prospection commerciale au sein du Groupe Le Figaro, ainsi qu’avec nos partenaires commerciaux.
Le traitement de votre email à des fins de publicité et de contenus personnalisés est réalisé lors de votre inscription sur ce formulaire. Toutefois, vous pouvez vous y opposer à tout moment
Plus généralement, vous bénéficiez d’un droit d’accès et de rectification de vos données personnelles, ainsi que celui d’en demander l’effacement dans les limites prévues par la loi.
Vous pouvez également à tout moment revoir vos options en matière de prospection commerciale et ciblage. En savoir plus sur notre politique de confidentialité ou notre politique Cookies.