La menace silencieuse du piratage de la chaîne d’approvisionnement logicielle

Il existe un réseau complexe d’interdépendances nécessaires à l’approvisionnement, au traitement, à la fabrication et au transport des marchandises qui doivent se produire avant qu’un véhicule ne soit disponible sur le terrain d’un concessionnaire, qu’un produit se trouve sur l’étagère de Target ou que le livreur d’Amazon se présente à votre porte. Il en va de même pour les logiciels d’aujourd’hui. Il existe une chaîne d’approvisionnement de code logiciel impliquée dans la livraison d’une application ou d’un service et les attaquants profitent de ses faiblesses.

Comprendre la chaîne d’approvisionnement

La chaîne d’approvisionnement est l’une de ces choses qui a toujours été là, mais la plupart des gens ne le savaient pas et n’y ont jamais pensé. Nous achetons, achetons et consommons sans comprendre ou tenir compte des nombreuses pièces mobiles qui doivent s’aligner pour produire des biens.

Une pomme pousse sur un arbre. C’est relativement simple. Cependant, acheminer la pomme de l’arbre à la section des produits de votre épicerie nécessite des efforts pour planter, faire pousser, récolter, trier, nettoyer et transporter les pommes. De nombreux facteurs tels que les conditions météorologiques extrêmes, les prix du carburant, les compétences et la disponibilité des travailleurs, etc., ont tous un impact sur la chaîne d’approvisionnement.

Risque lié à la chaîne d’approvisionnement

Il y a un effet d’entraînement sur la chaîne d’approvisionnement, qui est responsable d’un certain nombre de problèmes mondiaux à l’heure actuelle. Des événements apparemment sans rapport au début de la chaîne d’approvisionnement peuvent se répercuter et s’amplifier en d’énormes défis de production à l’autre extrémité. La pandémie de Covid, le changement climatique et d’autres facteurs continuent de perturber les régions et les industries d’une manière qui a un impact sur tout le monde dans le monde.

Il existe également un risque croissant de la chaîne d’approvisionnement pour la cybersécurité. Attaquer avec succès des milliers de cibles est une tâche herculéenne. Les acteurs de la menace ont reconnu qu’ils pouvaient compromettre une cible plus en amont dans la chaîne d’approvisionnement et en tirer parti pour accéder aux milliers d’entreprises ou d’individus qui dépendent de cette cible.

Chaîne d’approvisionnement open source

Un article de blog de Checkmarx explique, Les attaquants d’aujourd’hui se rendent compte qu’en infectant la chaîne d’approvisionnement des bibliothèques open source, des packages, des composants, des modules, etc., dans le contexte des référentiels open source, une toute nouvelle boîte de Pandore peut être ouverte. Et comme nous le savons tous, une fois que vous avez ouvert cette boîte, il est presque impossible de la fermer.

L’attaque contre SolarWinds fin 2020 était une attaque de la chaîne d’approvisionnement. Les entreprises et les agences gouvernementales du monde entier utilisent le logiciel SolarWinds. Les acteurs de la menace ont pu compromettre le logiciel SolarWinds et intégrer un code malveillant qui a ensuite été téléchargé et exécuté par les clients.

Les chercheurs ont discuté de ces questions lors de la RSA Security Conference 2022 en juin. Erez Yalon, vice-président de la recherche en sécurité chez Checkmarx, et Jossef Harush Kadouri, responsable de l’ingénierie pour la sécurité de la chaîne d’approvisionnement chez Checkmarx, ont présenté la session, intitulée The Simple, Yet Lethal, Anatomy of a Software Supply Chain Attack, ont révélé des recherches perspicaces et fourni un point de vue des attaquants sur les flux et les failles open source et sur la manière dont les pirates peuvent tirer parti des faiblesses de la chaîne d’approvisionnement logicielle.

Jacking de la chaîne d’approvisionnement logicielle

Les cyberattaques des États-nations et les cybercriminels recherchent généralement la voie de la moindre résistance, c’est pourquoi le piratage de la chaîne d’approvisionnement logicielle est une menace croissante. J’ai parlé avec Erez et Tzachi (Zack) Zornstain, responsable de la chaîne d’approvisionnement logicielle chez Checkmarx, de l’augmentation du risque.

Zack a noté que la façon dont les développeurs écrivent du code et créent des logiciels a évolué. Le passage de Waterfall à Agile et maintenant aux principes DevOps a accéléré et fondamentalement changé le processus. Il y a eu une énorme augmentation de la vitesse et de la vélocité du changement au cours des cinq dernières années. Nous nous dirigeons vers un futur ou même un présent déjà qui a beaucoup plus de pièces mobiles. Soudain, la sécurité des applications ne concerne pas seulement vos codes, mais également les conteneurs, les tiers, l’open source et les API qui communiquent entre elles. Tout ce qui se trouve là-bas est en quelque sorte connecté dans tous ces petits blocs de construction, et ce que nous voyons, c’est que les attaquants se dirigent vers cela.

Une partie de ce changement a été une utilisation et une dépendance accrues du code open source. 80% des lignes de code proviennent de l’open source, a partagé Erez. Donc, ce n’est pas une petite partie du code. La plupart du code des applications modernes provient de l’open source.

Tirer parti du code open source a du sens. Il est plus opportun d’incorporer un code open source qui remplit la fonction requise. Il est également inutile de dupliquer les efforts et de réinventer la roue si le code existe déjà. Cependant, les développeurs et les organisations qui utilisent ces applications doivent être conscients des implications de ces choix.

La chose à propos des logiciels open source est que n’importe qui peut contribuer ou modifier le code, et personne n’est désigné comme responsable de la résolution des vulnérabilités ou de la validation de sa sécurité. C’est un effort communautaire. La croyance est que l’exposer au public le rend plus sûr car il est ouvert à quiconque de voir le code et de résoudre les problèmes.

Mais il existe des milliers et des milliers de projets open source, et beaucoup d’entre eux sont plus ou moins abandonnés. Ils sont activement utilisés, mais pas nécessairement activement entretenus. Les développeurs originaux ont des vies et des emplois quotidiens. Le code open source est fourni gratuitement, il n’y a donc guère d’incitation à investir des efforts continus dans sa surveillance et sa mise à jour.

Erez et Zack ont ​​​​partagé avec moi quelques exemples de composants de code open source très populaires modifiés de manière à compromettre des millions d’appareils exécutant des applications qui exploitent le code open source. L’un était un exemple d’attaquants détournant le compte d’un développeur de code open source largement utilisé et y incorporant du code malveillant. Le code a été utilisé et approuvé pendant des années, et le développeur avait une réputation établie, il n’est donc venu à personne de remettre en question ou de se méfier du code.

C’était une prise de contrôle malveillante. L’autre exemple illustre comment le détournement de la chaîne d’approvisionnement logicielle peut également constituer une menace lorsqu’il est intentionnel. Erez et Zack m’ont parlé d’un développeur d’un élément open source populaire qui a modifié son code pour soutenir l’Ukraine à la suite de l’invasion russe. Le code a été modifié pour bloquer ou effacer efficacement les ordinateurs en Russie. Il n’a pas caché la mise à jour, le changement a été rendu public et il a été clair sur ses motivations. Cependant, peu d’organisations en Russie qui s’appuient sur son code sont réellement conscientes qu’elles utilisent son code, et encore moins auraient une raison de lire ses messages ou de surveiller les changements sur Github.

Le détournement de la chaîne d’approvisionnement des logiciels et les problèmes liés à la chaîne d’approvisionnement des logiciels en général continueront d’exposer les organisations à des risques. Erez a résumé, Fondamentalement, la question est de savoir qui est responsable ? Nous pensons que parce que c’est notre logiciel, c’est notre responsabilité.

Les organisations ne peuvent pas se permettre de supposer que le code open source exécuté dans leurs environnements est sécurisé. Ils ne peuvent pas non plus supposer que, simplement parce que le développeur a une solide réputation, que le code open source a d’excellentes critiques et que le code a été utilisé en toute sécurité pendant des années, il peut être intrinsèquement fiable. Erez a ajouté : « C’est notre travail de nous assurer que les choses fonctionnent réellement comme prévu.