SolarWinds : ce qu’on sait une semaine après les révélations

Comment du code malveillant a-t-il pu parvenir dans des mises à jour d’Orion ? La question reste en suspens huit jours après que SolarWinds, à l’origine de cette suite logicielle de gestion informatique, a officialisé l’incident.

L’éditeur avait synchronisé sa communication avec FireEye, Microsoft et le gouvernement américain… tous trois victimes à divers degrés.
Leurs analyses respectives concordent partiellement. Dans les grandes lignes, elles concluent à une campagne d’espionnage étatique. Avec, à la source, une porte dérobée ouverte par détournement d’une bibliothèque (DLL).

SolarWinds estime que cette DLL est parvenue à quelque 18 000 de ses clients. Soit plus de la moitié de ceux qui ont disposé d’un contrat de maintenance actif entre février 2020 et la date de l’incident. La diffusion s’est faite via des canaux officiels de mise à jour d’Orion. Ce qui laisse supposer la compromission des systèmes de développement et/ou de distribution de l’éditeur.

L’activation de la backdoor – que FireEye nomme SunBurst, quand Microsoft l’appelle Solarigate – repose sur quelques lignes de code. Celles-ci se sont glissées dans une fonction régulièrement invoquée (RefreshInternal) et liée à une classe qui planifie l’exécution de tâches.

Domaines personnalisés

Le principal serveur de commande et de contrôle (C2) dont on a connaissance est hébergé à l’adresse avsvmcloud[.]com. La backdoor se connecte plus précisément à un sous-domaine propre à chaque cible. Une partie du nom dépend en l’occurrence de trois éléments :

• Adresse de l’interface réseau physique
• Nom du domaine de la machine
• Contenu de la valeur MachineGuide dans la clé de registre HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography

La backdoor accepte des commandes qui lui permettent, entre autres, de gérer les tâches, les fichiers et les clés de registre. À partir de là, c’est une affaire d’élévation de privilèges et de latéralisation. Idéalement jusqu’à obtenir les droits d’administrateur au plus haut niveau de l’organisation visée. Voire récupérer le certificat qui sert à signer les jetons SAML du serveur de fédération Active Directory. Et pouvoir ainsi usurper des comptes, qu’il s’agisse d’utilisateurs ou d’applications.

Des tests « à vide »

Pour maintenir une présence sur les systèmes infectés, plusieurs techniques. L’une d’entre elles consiste à modifier les paramètres de domaines fédérés ou à en ajouter. Une autre implique l’injection d’identifiants – mots de passe ou clés x509 – dans des applications OAuth.
Volexity fait état d’une offensive de ce type, également basée sur SolarWinds. Il dit l’avoir repérée en juillet dernier. Auteur présumé : un collectif présenté sous le nom Dark Halo. Victime : un think tank américain déjà ciblé plusieurs fois auparavant avec d’autres méthodes. Butin : des e-mails exfiltrés depuis des boîtes Exchange.

Le détournement de la DLL Orion semble avoir fait l’objet d’expérimentations dès octobre 2019. À l’époque, sans y déposer de charge malveillante (ajout de classes vides). La démarche a finalement affecté trois versions de la suite logicielle : 2019.4 HF 5, 2020.2 et 2020.2 HF 1.

SolarWinds en appelle à installer la 2020.2.1 HF 1, qui élimine la DLL problématique. Ou, encore mieux, la 2020.2.1 HF 2, qui ajoute des mesures de sécurité. Autre possibilité : passer à la 2019.4 HF 6. De manière générale, explique l’éditeur, on réinitialisera tout serveur qui a hébergé une version vulnérable et qui bénéficiait à ce moment-là d’un accès à Internet.

SolarWinds : incident maîtrisé ?

FireEye a relevé au moins un cas de déploiement d’un dropper inconnu. Fonctionnant exclusivement en mémoire, il s’appuie sur un fichier jpeg à l’en-tête probablement corrompu pour installer l’exploit Cobalt Strike. Du côté de Microsoft, l’antivirus Defender bloque depuis cinq jours tout binaire SolarWinds compromis. Sauf à mettre en place des stratégies de groupe (GPO) ou des règles SCCM qui, dans tous les cas, devront n’être que provisoires.

En association avec l’hébergeur GoDaddy, les deux firmes ont créé un kill switch. Elles ont pris le contrôle du domaine avsvmcloud[.]com et fait en sorte qu’il résolve sur une IP qui figure sur la liste noire de la backdoor. Celle-ci cesse aussitôt de s’exécuter. Mais peut-être en existe-t-il d’autres qui se connectent à d’autres serveurs…

Quant à connaître les victimes, on se tournera par exemple vers le décodage des noms de domaines « personnalisés ». Apparaissent des entreprises comme Cisco, qui a effectivement reconnu s’être fait piéger.

Illustration principale © Rawpixel.com – Adobe Stock