Comme exemple d’une attaque à la fois simple et sophistiquée, SolarWinds/Sunburst est un modèle. Elle met en évidence des compétences techniques avancées et une bonne connaissance des processus de certification et de la chaine d’approvisionnement des applications dans les entreprises.
La tempête SolarWinds n’a pas fini de faire couler de l’encre tant ses ramifications sont étendues (18 000 clients affectés dont Microsoft, des organismes gouvernementaux américains dont la National Nuclear Security Administration et une multitude d’entreprises). Les hackers ont réussi à s’infiltrer dans la chaine d’approvisionnement logiciel et insérer leur code malveillant dans des outils logiciels légitimes.
Depuis, les équipes de sécurité à travers le monde déploient de gros efforts pour déterminer si elles étaient compromises par l’attaque Sunburst, et chaque jour de nouvelles entreprises compromises s’ajoutent à la liste des victimes. « Furtive et sophistiquée, cette attaque a été particulièrement complexe à détecter ce qui a grandement favorisé sa dissémination. L’incertitude autour de la date de la première infection n’ayant pas été levée, les entreprises et autres entités sont contraintes de passer au crible l’ensemble de leurs fichiers – y compris leurs archives, pour y déceler d’éventuelles traces de compromissions », explique un porte-parole de BlackBerry.
Quelques lignes de code apparemment bénignes
Il faut dire que les mises à jour contaminées du logiciel Orion de SolarWinds ont été distribuées pendant des mois avant d’être débusquées presque par hasard. D’après la Microsoft 365 Defender Research Team, « L’ajout de quelques lignes de code d’apparence bénigne dans un seul fichier DLL représentait une menace sérieuse pour les organisations utilisant le produit concerné […]. Les codes malveillants discrets insérés dans la DLL appelaient une porte dérobée composée de près de 4 000 lignes de code, qui permettait à l’acteur de la menace derrière l’attaque d’opérer sans entraves dans les réseaux compromis ».
Dans nombre de leurs actions, les agresseurs ont pris des mesures pour rester discrets. Ils ont ensuite réduit et isolé l’activité malveillante de la DLL afin qu’elle n’apparaisse pas dans les fichiers journaux et ne provoque pas d’alertes. Les attaquants ont pu ainsi profiter pendant de longs mois des privilèges administratifs obtenus et établir des accès réseau à long terme. Libres de leurs mouvements latéraux, ils ont eu tout le temps de compromettre profondément les SI infectés.
Une DLL compromise, mais quand même signée numériquement
Les mécanismes grâce auxquels ils ont pu passer inaperçus valent le détour. Toujours selon l’analyse de la Research Team de Microsoft 365, le fait que le fichier compromis soit signé numériquement suggère que les attaquants ont pu accéder au pipeline de développement ou de distribution de logiciels de la société. Par conséquent, cette signature numérique de la DLL contenant le code malveillant améliore sa capacité à exécuter des actions privilégiées et à garder un profil bas.
« Les preuves suggèrent que dès octobre 2019, ces attaquants ont testé leur capacité à insérer du code en ajoutant des classes vides. Par conséquent, l’insertion de code malveillant dans le fichier SolarWinds.Orion.Core.BusinessLayer.dll s’est probablement produite à un stade précoce, avant les dernières étapes de la construction du logiciel, qui comprendrait la signature numérique du code compilé », concluent les rédacteurs de l’article.
Une fois qu’ils ont réussi à faire signer numériquement la DLL infectée, les attaquants devaient ensuite lui éviter d’être repérée. D’abord, le code malveillant est réduit à sa plus simple expression, donc empreinte réduite et activité simplifiée. Il n’exécute qu’une seule tâche : ajouter le code malveillant de la porte dérobée dans un fil de discussion parallèle, de sorte que les opérations normales de la DLL ne soient pas altérées ou interrompues. « Cette méthode fait partie d’une classe, que les attaquants ont nommée OrionImprovementBusinessLayer pour se fondre dans le reste du code. La classe contient toutes les capacités de la porte dérobée, comprenant 13 sous-classes et 16 méthodes, avec des chaines de caractères obscurcies pour dissimuler davantage le code malveillant », explique l’article.
Une porte dérobée ouverte sur les SI des victimes
Une fois chargé, le maliciel ouvre une porte dérobée et entreprend une longue liste de vérifications pour s’assurer qu’il fonctionne dans un véritable réseau d’entreprise et non dans un bac à sable ou sur les machines d’un analyste. Il contacte ensuite un serveur de commande et de contrôle (C&C) en utilisant un sous-domaine généré en partie à partir des informations recueillies sur l’appareil infecté, c’est-à-dire un sous-domaine unique pour chaque domaine concerné. C’est une autre façon pour les attaquants d’essayer d’échapper à la détection. Depuis, Microsoft et une coalition d’entreprises technologiques ont réussi à saisir et « enterrer » le serveur C&C de Sunburst.
Grâce à une longue liste de fonctions et de capacités, cette porte dérobée permet aux attaquants d’effectuer un large éventail d’actions. « Comme nous l’avons vu dans les attaques humaines passées, une fois qu’ils opèrent à l’intérieur d’un réseau, les adversaires peuvent effectuer une reconnaissance sur le réseau, augmenter les privilèges et se déplacer latéralement. Les attaquants se déplacent progressivement à travers le réseau jusqu’à ce qu’ils puissent atteindre leur objectif, qu’il s’agisse de cyberespionnage ou de gain financier », affirment les auteurs de l’article.
Il n’y a pas d’alertes de routine en cybersécurité
D’après nos confrères du Wall Street Journal, la compromission par Sunburst a été découverte presque par hasard. « L’attaque de SolarWinds a tellement échappé aux mesures de sécurité américaine qu’elle a été découverte non pas par les services de renseignement, mais, presque accidentellement, grâce à une alerte de sécurité automatisée envoyée ces dernières semaines à un employé de FireEye, qui avait lui-même été discrètement compromis », écrivait notre confrère dans un article du 17 décembre dernier.
L’alerte reçue par l’employé a également été envoyée à l’équipe de sécurité de FireEye. Elle avertissait qu’un accès au réseau privé virtuel de l’entreprise, avec des authentifiants d’un employé légitime, avait été effectué à partir d’un appareil qui n’était pas reconnu. Une simple alerte de routine qui serait passée inaperçue et aurait permis aux attaquants de mieux s’ancrer dans les SI infecté et d’en infecter davantage. Ce genre d’alertes est très souvent ignoré par les services de sécurité, ce qui pose une fois encore le problème des faux-positifs. Si l’on devait tirer une leçon de cette affaire, c’est qu’en cybersécurité, il n’y a pas d’alertes de routine.
