Via une mise à jour de software dans le réseau de l’entreprise: des cyber-criminels tentent de s’introduire dans des réseaux d’entreprises bien sécurisés via des applications manipulées appartenant à des fabricants tiers. Ou exploitent les failles des composants, comme avec Log4Shell. Ce vecteur d’attaque par la chaîne d’approvisionnement pose de nouveaux défis aux responsables de la sécurité IT.
Texte: Andreas Heer, Images: AdobeStock,
En décembre 2020, un large public apprenait du jour au lendemain que les cyber-criminels n’attaquaient pas seulement directement l’infrastructure informatique des organisations. Mais qu’ils agissaient aussi par l’intermédiaire des logiciels utilisés par les organisations. Des acteurs prétendument étatiques ont en effet réussi à installer une porte dérobée dans le software de gestion de réseau SolarWinds Orion. La mise à jour compromise et signée du fabricant a ensuite été distribuée à environ 18 000 organisations dont l’infrastructure présentait alors pour les cyber-criminels un accès facilité. Il revient à cette agression intitulée Sunburst l’honneur discutable de compter non seulement parmi les cyberattaques les plus subtiles et les plus graves. Elle est aussi probablement la plus importante attaque à ce jour contre une chaîne d’approvisionnement logicielle.
Mais il y a encore pire. À peine l’univers de la sécurité informatique était-il remis de ce choc qu’une petite bibliothèque Java faisait parler d’elle. Log4j ne se limite pas en effet à sauvegarder les fichiers journaux d’applications. En décembre 2021, elle a exécuté également un code programme quelconque depuis un système distant. Il a suffi pour cela qu’une application transmette à Log4j une chaîne d’URL simple à construire, lors d’un appel. La criticité de cette faille RCE (Remote Code Execution) a obtenu en conséquence la note maximale de 10. La faille elle-même a fait la une en tant que Log4Shell et a été activement exploitée peu après sa divulgation.
Mais ce n’est pas tout. Comme la bibliothèque est intégrée dans des applications, les entreprises ont dû découvrir d’abord si elles étaient elles-mêmes touchées. Partout dans le monde a commencé une recherche effrénée d’applications utilisant Log4j. Ce n’est qu’ensuite qu’a pu être déployée l’update permettant de remédier à cette faille.
Software compromis provenant de sources fiables, failles dans des bibliothèques de software, manque de transparence sur les bibliothèques et frameworks effectivement utilisés: la chaîne d’approvisionnement logicielle apparaît comme le talon d’Achille d’une infrastructure informatique par ailleurs bien protégée. Et le danger est loin d’être écarté: Début 2022, une faille a été découverte dans le framework Spring utilisé par de nombreuses applications Java. La suite est garantie.
Selon Swisscom Cybersecurity Threat Radar, les attaques contre la chaîne d’approvisionnement font partie des points cruciaux que les responsables de la sécurité IT doivent observer plus précisément. Oliver Jäschke, Security Governance Manager chez Swisscom, évalue la situation dans un entretien.
Oliver Jäschke, quelle est l’importance des attaques contre la chaîne d’approvisionnement dans la sécurité IT, comparativement par exemple aux fréquentes attaques de ransomware?
Les attaques contre la chaîne d’approvisionnement, c’est-à-dire contre les livrables, sont encore rares par comparaison. En effet, elles ne revêtent pas l’ampleur que l’on constate aujourd’hui avec les attaques de ransomware. Mais leur découverte est beaucoup plus difficile, car les modifications des livrables sont effectuées par des utilisateurs autorisés et passent souvent inaperçues. À cet égard, il faudrait dans le processus de développement des mesures complémentaires dépassant le principe du double contrôle.
Malgré tout, les attaques contre la chaîne d’approvisionnement ont suscité beaucoup d’attention. Quel est donc la problématique?
Les attaques au sein de la chaîne d’approvisionnement sont très difficiles à découvrir. On fait confiance à son fournisseur pour mettre de l’ordre dans la sécurité. Après tout, on achète un produit pour lequel on paie en règle général. On achète implicitement aussi la sécurité.
On perd souvent de vue le fait que le fournisseur a d’autres fournisseurs de composants partiels ou qu’il se sert aussi de software libres et open source (FOSS). C’est ici au plus tard que la traçabilité est très ardue.
Comment les entreprises peuvent-elles réagir à cette situation?
Bien entendu, les entreprises doivent mettre en place des mesures de sécurité. En outre, elles peuvent exiger que les livrables fassent l’objet de certains contrôles de sécurité. De surcroît, le sujet de la SBOM est brûlant pour le moment. Une telle nomenclature de software, c’est-à-dire une sorte de liste des composants de software utilisés, n’empêche pas en soi les attaques contre la chaîne d’approvisionnement. Mais elle permet d’identifier très rapidement les produits avec des faiblesses correspondantes et de prendre des mesures. Log4Shell aurait été plus simple à maîtriser pour les entreprises si chaque fournisseur avait démontré, au moyen d’une SBOM, qu’il utilisait précisément ce composant spécifique.
Newsletter
Vous souhaitez recevoir régulièrement des articles et Whitepapers passionnants sur des activités TIC actuelles?
En savoir plus sur ce thème: