Les cyberattaques nous sont – malheureusement – devenues familières ; pas un jour où une nouvelle annonce d’une fuite de données ou du blocage d’un service numérique ne fasse la une de l’actualité. Si des spécialistes cherchent en permanence à concevoir des solutions visant à diminuer leur nombre et leur portée, il convient ensuite de les mettre en œuvre dans les systèmes numériques pour les contrer. L’histoire que nous racontent Charles Cuveliez et Jean-Charles Quisquater est édifiante : elle nous explique exactement tout ce qu’il ne faut pas faire ! Pascal Guitton
C’est une plainte en bonne et due forme qu’a déposée la Commission américaine de réglementation et de contrôle des marchés financiers (SEC) contre la société SolarWinds et son Chief Information Security Officer dans le cadre de l’attaque qu’elle a subie. Elle avait fait du bruit car elle a permis à des hackers de diffuser, depuis l’intérieur des systèmes de la société, une version modifiée du logiciel de gestion des réseaux que la compagnie propose à ses clients (Orion). Il faut dire que les dégâts furent considérables puisque les entreprises qui avaient installé la version modifiée permettaient aux hackers d’entrer librement dans leur réseau.
L’enquête de la SEC relatée dans le dépôt de plainte montre l’inimaginable en termes de manque de culture de sûreté, de déficience et de négligence, le tout mâtiné de mauvaise foi.
Absence de cadre de référence de sûreté
SolarWinds a d’abord prétendu et publié qu’il avait implémenté la méthodologie de l’agence chargée du développement de l’économie notamment en développant des normes (NIST, National Institute of Standards and Technology) pour évaluer les pratiques de cybersécurité et pour atténuer les risques organisationnels mais ce n’était pas vrai. Des audits internes ont montré qu’une petite fraction seulement des contrôles de ce cadre de référence était en place (40 %). Les 60% restants n’étaient tout simplement pas implémentés. SolarWinds, dans le cadre de ses évaluations internes, avait identifié trois domaines à la sécurité déficiente : la manière de gérer cette sécurité dans les logiciels tout au long de leur vie commerciale, les mots de passe et les contrôles d’accès aux ressources informatiques.
Un développement sans sécurité
Le logiciel de base qui sert à son produit Orion, faisait partie des développements qui ne suivaient absolument aucun cadre de sécurité. L’enquête a montré en 2018 qu’il y avait eu un début d‘intention pour introduire du développement sûr de logiciel mais qu’il fallait commencer par le début… une formation destinée aux développeurs pour savoir ce qu’est un développement sûr, suivi par des expériences pilotes pour déployer graduellement cette méthodologie, par équipe, sans se presser, sur une base trimestrielle. Entretemps, SolarWinds continuait à prétendre qu’elle pratiquait ses développements en suivant les méthodes de sécurité adéquates.
Mot de passe
La qualité de la politique des mots de passe était elle aussi défaillante : à nouveau, entre ce que SolarWinds prétendait et ce qui était en place, il y avait un fossé. La politique des mots de passe de SolarWinds obligeait à les changer tous les 90 jours, avec une longueur minimum et, comme toujours, imposait des caractères spéciaux, lettres et chiffres. Malheureusement, cette politique n’était pas déployée sur tous les systèmes d’information, applications ou bases de données. La compagnie en était consciente mais les déficiences ont persisté des années durant. Un employé de SolarWinds écrivit même un courriel au nouveau patron de l’informatique que des mots de passe par défaut subsistaient toujours pour certaines applications. Le mot de passe ‘password’ fut même découvert ! Un audit a mis en évidence plusieurs systèmes critiques sur lesquels la politique des mots de passe n’était pas appliquée. Des mots de passe partagés ont été découverts pour accéder à des serveurs SQL. Encore pire : on a trouvé des mots de passe non chiffrés sur un serveur public web, des identifiants sauvés dans des fichiers en clair. C’est via la société Akamai qui possède des serveurs un peu partout dans le monde et qui duplique le contenu d’internet notamment (les CDN, Content Distribution Networks) que SolarWinds distribuait ses mises à jour. Un chercheur fit remarquer à SolarWinds que le mot de passe pour accéder au compte de l’entreprise sur Akamai se trouvait sur Internet. Ce n’est pourtant pas via Akamai que la modification et la diffusion du logiciel eut lieu. Les hackers l’ont fait depuis l’intérieur même des systèmes de SolarWinds.
Gestion des accès
La gestion des accès c’est-à-dire la gestion des identités des utilisateurs, les autorisations d’accès aux systèmes informatique et la définition des rôles et fonctions pour savoir qui peut avoir accès à quoi dans l’entreprise étaient eux aussi déficients. La direction de SolarWinds savait entre 2017 et 2020 qu’on donnait de manière routinière et à grande échelle aux employés des autorisations qui leur permettaient d’avoir accès à plus de systèmes informatiques que nécessaires pour leur travail. Dès 2017, cette pratique était bien connue du directeur IT et du CIO. Pourquoi diable a-t-on donné des accès administrateurs à des employés qui n’avaient que des tâches routinières à faire ? Cela a aussi compté dans l’attaque.
Les VPN furent un autre souci bien connu et non pris en compte. A travers le VPN pour accéder au réseau de SolarWinds, une machine qui n’appartient pas à SolarWinds pouvait contourner le système qui détecte les fuites de données (data loss prevention). L’accès VPN contournait donc cette protection. Comme d’habitude, serait-on tenté de dire à ce stade, c’était su et connu de la direction. Toute personne avec n’importe quelle machine, grâce au VPN de SolarWinds et un simple identifiant (volé), pouvait donc capter des données, de manière massive sans se faire remarquer. En 2018, un ingénieur leva l’alerte en expliquant que le VPN tel qu’il avait été configuré et installé pouvait permettre à un attaquant d’accéder au réseau, d’y charger du code informatique corrompu et de le stocker dans le réseau de SolarWinds. Rien n’y fit, aucune action correctrice ne fut menée. En octobre 2018, SolarWinds, une vraie passoire de sécurité, faisait son entrée en bourse sans rien dévoiler de tous ces manquements. C’est d’ailleurs la base de la plainte de la SEC, le régulateur américain des marchés. Toutes ces informations non divulguées n’ont pas permis aux investisseurs de se faire une bonne idée de la valeur de la société. Solarwinds ne se contenta pas de mentir sur son site web : dans des communiqués de presse, dans des podcasts and des blogs, SolarWinds faisait, la main sur le cœur, des déclarations relatives à ses bonnes pratiques cyber.
Avec toutes ces déficiences dont la direction était au courant, il est clair pour la SEC que la direction de SolarWinds aurait dû anticiper qu’il allait faire l’objet d’une cyberattaque.
Alerté mais silencieux
Encore plus grave : SolarWinds avait été averti de l’attaque par des clients et n’a rien fait pour la gérer. C’est bien via le VPN que les attaquants ont pénétré le réseau de SolarWinds via des mots de passe volés et via des machines qui n’appartenaient pas à SolarWinds (cette simple précaution de n’autoriser que des machines répertoriées par la société aurait évité l’attaque). Les accès via le VPN ont eu lieu entre janvier 2019 et novembre 2020. Les criminels eurent tout le temps de circuler dans le réseau à la recherche de mots de passe, d’accès à d’autres machines pour bien planifier l’attaque. Celle-ci a donc finalement consisté à ajouter des lignes de code malicieuses dans Orion, le programme phare de SolarWinds, utilisé pour gérer les réseaux d’entreprise. Ils n’ont eu aucun problème pour aller et venir entre les espaces de l’entreprise et les espaces de développement du logiciel, autre erreur de base (ségrégation et segmentation). A cause des problèmes relevés ci-dessus avec les accès administrateurs, donnés à tout bout de champ, notamment, les antivirus ont pu être éteints. Les criminels ont ainsi pu obtenir des privilèges supplémentaires, accéder et exfiltrer des lignes de codes sans générer d’alerte. Ils ont aussi pu récupérer 7 millions de courriels du personnel clé de Solarwind.
Jusqu’en février 2020, ils ont testé l’inclusion de lignes de code inoffensives dans le logiciel sans être repérés. Ils ont donc ensuite inséré des lignes de code malicieuses dans trois produits phares de la suite Orion. La suite, on connait : ce sont près de 18 000 clients qui ont reçu ces versions contaminées. Il y avait dans ces clients des agences gouvernementales américaines.
On s’est bien retranché, chez SolarWinds, derrière une soi-disant attaque d’un État pour justifier la gravité de ce qui s’est passé et sous-entendre qu’il n’y avait rien à faire pour la contrer mais le niveau de négligence, analyse la SEC, est si immense qu’il ne fallait pas être un État pour mettre en œuvre Sunburst, le surnom donné à l’attaque. Il y a aussi eu des fournisseurs de service (MSP) attaqués : ceux-ci utilisent les produits de SolarWinds pour proposer des services de gestion de leur réseau aux clients, ce qui donc démultipliait les effets.
Alors que des clients ont averti que non seulement le produit Orion était attaqué mais que les systèmes même de SolarWinds étaient affectés, la société a tu ces alertes. Elle fut aussi incapable de trouver la cause de ces attaques et d’y remédier. SolarWinds a même osé prétendre que les hackers se trouvaient déjà dans le réseau des clients (rien à avoir avec SolarWinds) ou que l’attaque était contre le produit Orion seul (sur laquelle une vulnérabilité aurait été découverte par exemple) alors que cette attaque avait eu lieu parce que les hackers avaient réussi à infester le réseau de SolarWinds
Pour la SEC, le manque de sécurité mise en place justifie déjà à lui seul la plainte et l’attaque elle-même donne des circonstances aggravantes.
L’audit interne a montré que de nombreuses vulnérabilités étaient restées non traitées depuis des années. De toute façon le personnel était largement insuffisant, a pu constater la SEC dans les documents internes, pour pouvoir traiter toutes ces vulnérabilités en un temps raisonnable. On parlait d’années. Lors de l’attaque, SolarWinds a menti sur ce qui se passait. Au lieu de dire qu’une attaque avait lieu, SolarWinds avait écrit que du code dans le produit Orion avait été modifié et pourrait éventuellement permettre à un attaquant de compromettre les serveurs sur lesquels le produit Orion avait été installé et tournait !
Que retenir de tout ceci ? Il ne faut pas se contenter des déclarations des fournisseurs sur leurs pratiques de sécurité. En voilà un qui a menti tout en sachant que son produit était une passoire. Ce qui frappe est la quantité d’ingénieurs et d’employés qui ont voulu être lanceurs d’alerte au sein de SolarWinds. Ils ne furent pas écoutés. Faut-il légiférer et prévoir une procédure de lanceur d’alerte sur ces matières-là aussi vers des autorités ? On se demande aussi si dans tous les clients d’Orion, il n’y en a eu aucun pour faire une due diligence avec des interviews sur site. Il est quasiment certain que des langues se seraient déliées.
Jean-Jacques Quisquater (Ecole Polytechnique de Louvain, Université de Louvain et MIT) & Charles Cuvelliez (Ecole Polytechnique de Bruxelles, Université de Bruxelles)
Pour en savoir plus : Christopher BRUCKMANN, (SDNY Bar No. CB-7317), SECURITIES AND EXCHANGE COMMISSION, Plaintiff, Civil Action No. 23-cv-9518, against SOLARWINDS CORP. and TIMOTHY G. BROWN