Face au renforcement des mesures de sécurité, les hackers utilisent de nouvelles portes d’entrée moins protégées par les entreprises : la chaîne d’approvisionnement logicielle. Ces attaques sont aussi dangereuses que difficiles à détecter. Vu la hausse de 600 % l’an passé, comment se prémunir de ces attaques qui touchent 90 % des entreprises ? Romain Testu, Sales Engineering Manager chez Lacework, nous livre son analyse.
Romain Testu Sales Engineering Manager chez Lacework
Le 20 juin 2023, les dirigeants de SolarWinds, dont le RSSI, ont été convoqués par le gendarme boursier américain pour « violation de données mobilières ». Une semonce qui intervient deux ans après la cyberattaque Sunburst. Pour mémoire, en 2020 des pirates ont compromis une mise à jour de la plate-forme de gestion informatique Orion de l’entreprise, leur donnant un accès à distance aux ordinateurs infectés via le désormais fameux Log4J.
Une attaque perpétrée, selon le gouvernement américain par l’agence de renseignement russe SVR. Résultat de cette attaque : de grandes entreprises comme Intel, Microsoft, VMWare, mais aussi de nombreuses agences et institutions américaines et leurs 18 000 clients ont été volés et infectés, avec une ramification de dégâts sur le long terme.
A lire aussi : « Indispensable mais obscur », le cyber-rating s’installe dans le paysage
Avec Sunburst, l’univers IT découvrait les attaques par chaîne d’approvisionnement logicielle. Une attaque qui consiste à infecter un logiciel massivement déployé au sein des organisations. Ce type d’attaque a augmenté de plus de 600 % durant l’année passée et plus de 90 % des organisations ont déjà été impactés par une attaque visant leur chaîne d’approvisionnement logicielle.
Chaîne d’approvisionnement logicielle : une définition
Concrètement, la chaîne d’approvisionnement logicielle ressemble à la chaîne d’approvisionnement logistique traditionnelle. Ce sont des process et des personnes qui produisent des applications et interagissent tout au long de la chaîne de développement. Les développeurs produisent des applications et les déposent dans des répertoires qui donnent lieu à plusieurs manipulations avant d’être déployés dans des environnements d’exécution, le plus souvent Kubernetes.
Attaquer l’environnement d’exécution d’une application n’est pas nouveau. Dans les années 80, l’informaticien Kenneth Thomson a été le premier à introduire une backdoor dans un compilateur C. Son idée était d’y introduire un hack de la fonction login pour s’introduire dans tous ces systèmes. Depuis lors, cette technique a fait florès et constitue l’axe central de nombreuses attaques.
Pourquoi une inflation d’attaques ?
Ce regain de compromission liée à la chaîne d’approvisionnement repose essentiellement sur deux facteurs :
– L’interconnexion et l’hyperconnexion sont toujours plus répandues via les API insérées dans la chaîne logicielle. Entrer via ces APIs offre une surface d’attaque plus simple pour les attaquants, mais surtout leur donne l’occasion de se déplacer d’un système à l’autre ;
– Les évolutions des politiques de sécurité, particulièrement les MFA ou outils EDR, qui incitent les hackers à trouver de nouvelles portes d’entrée.
C’est compter sans le fait que nombre d’attaques sont opportunistes et s’appuient le plus souvent sur des fournisseurs tiers pour viser une cible finale. Dans le cas du serveur compromis d’Orion qui a été compromis, des attaquants ont introduit une backdoor dans les artefacts Solarwinds qui sont ensuite déployés chez les clients finals. Une fois activé, ces malwares exfiltrent de la donnée chez ces centaines de clients d’Orion.
A lire aussi : Quels sont les coûts pour une organisation cyberattaquée en France ?
Pourquoi est-ce si difficile à sécuriser ?
La chaîne d’approvisionnement est complexe. Beaucoup d’outils et d’interactions sont présents tout au long de la chaîne. À ce titre, dans une application d’entreprise, il n’est pas rare de recenser de nombreuses bibliothèques open source, 500 en moyenne. Ces bibliothèques, souvent un agglomérat de codes divers, sont autant de vecteurs d’attaques. Selon RUN-Throughs Cybersecurity Proving Ground, 81 % des bases ont au moins une vulnérabilité open source. Vulnérabilité qui a été là aussi le vecteur pour l’attaque SolarWinds.
Comme pour les autres types d’attaques, l’usurpation d’identité est le premier vecteur de compromission. Si un développeur se fait voler son identité, muni de son login, le hacker peut uploader des données ou un package compromis, exfiltrer des mots de passe, etc. Pire, les vulnérabilités au sein des conteneurs sont nombreuses : les secrets, les identifiants positionnés dans le registre, etc. Muni du login, un hacker pourra se déplacer aisément, identifier les images, les bibliothèques utilisées entre autres manœuvres frauduleuses.
Encore plus permissif, le token donnera des droits en écriture, laissant le hacker positionner les malwares qui seront ensuite déployés dans l’entreprise ou encore faire du typosquatting. Cette dernière technique consiste à identifier un package largement utilisé, le compromettre et le renommer de manière proche du package légitime pour inciter le développeur à l’utiliser. Dans un second temps, le hacker peut aller sur le site stack overflow poser des questions sur ce package afin d’inciter les développeurs à aller le découvrir.
Enfin, un autre vecteur courant : l’entreprise. Si votre chaîne d’approvisionnement est compromise, vous pouvez être un vecteur d’attaque pour vos propres clients.
Quels sont les risques ?
Les risques de ces attaques associées à la chaîne d’approvisionnement sont nombreux et dépendent surtout des motivations de l’attaquant : vol de données, destruction, risque d’image. Si vous fournissez des solutions logicielles, le principal risque est celui de l’image et donc financier. À titre d’exemple, Solarwinds a perdu 40 % de sa valorisation à la suite de l’attaque via Orion.
Comment se prémunir des attaques via la chaîne d’approvisionnement logicielle
On le voit, sécuriser la chaîne d’approvisionnement est critique pour l’entreprise. Parer ce type d’attaque nécessite d’avoir une approche par outil, mais aussi par une politique de sécurité plus contraignante.
Sur le versant des outils, la priorité est de déployer un système d’intrusion qui analyse les anomalies comportementales. Par exemple, pour analyser les bibliothèques open source dont nous avons vu qu’elles présentaient un risque majeur, il faut utiliser un outil SBOM pour dresser l’inventaire de vos applications et détecter les anomalies.
Pour la gestion des identités, outre les outils MFA, mettre en œuvre une stratégie « least privilege » est conseillé. L’objectif est d’être très regardant en créant les tokens vis-à-vis des permissions et limiter autant que possible le périmètre de privilège accordé pour limiter le champ d’action en cas d’attaque.
Pour éviter un nouveau Log4J, il est indispensable de mettre en place un outil de scan et de l’utiliser sur l’ensemble de la chaîne pour détecter une menace liée à une intrusion ou un comportement anormal. Un seul élément vulnérable non détecté peut être une porte ouverte à une nouvelle attaque.