Comment les certificats X.509 ont été impliqués dans l'attaque de SolarWinds

Pendant un moment, nous étions prêts à laisser 2020 derrière nous, jusqu'à cette semaine.

Tout a commencé par le vol signalé des outils de l'équipe rouge de FireEye, puis est venue la nouvelle la plus importante. FireEye et les départements du Trésor et du Commerce des États-Unis ont été infiltrés par des mises à jour de SolarWinds Orion software , qui comprenaient un code malveillant injecté par le groupe de pirates informatiques Cozy Bear (APT 29), soutenu par la Russie.

Cette nouvelle ne concerne pas seulement SolarWinds, FireEye et les agences gouvernementales américaines - elle nous concerne tous. Lorsqu'un État-nation s'en prend à l'un d'entre nous, il s'en prend à nous tous, et nous en ressentons tous les effets. C'est un rappel brutal de notre réalité quotidienne : tout le monde peut être victime d'une intrusion.

Bien que tous les détails de l'attaque - désormais connue sous le nom de SUNBURST - n'aient pas encore été révélés, nous en avons appris beaucoup plus sur nos adversaires et sur la manière dont ils ont réussi à échapper aux défenses.

Voyons ce que nous savons jusqu'à présent :

• Le⁸ décembre, FireEye a révélé le vol de ses outils d'évaluation Red Team sur un dépôt GitHub. Malgré le battage médiatique, la plupart de ces outils et exploits étaient déjà bien connus.
• Le¹³ décembre, FireEye a découvert, dans le cadre de sa propre enquête, que l'attaque impliquait un code malveillant inséré dans des mises à jour software légitimes de la plateforme SolarWinds Orion datant d'entre mars 2020 et mai 2020.
• Le même jour, les départements du Trésor et du Commerce des États-Unis ont annoncé que leurs systèmes avaient été violés par un groupe de pirates informatiques soutenu par la Russie et connu sous le nom de CozyBear (APT 29). La CISA a ensuite publié la directive d'urgence 21-01, "Mitigation de la compromission du code SolarWinds Orion".
• Le¹⁵ décembre, Microsoft a réquisitionné le nom de domaine malveillant utilisé pour contrôler les systèmes affectés afin de prévenir et même d'atténuer l'attaque à l'aide d'un "kill switch".

Il faudra probablement un certain temps pour déterminer la portée et l'ampleur de cet incident, mais au cours de la semaine écoulée, nous avons beaucoup appris sur les outils et les techniques utilisés par les auteurs de l'attaque.

Au fur et à mesure que la poussière retombe et que d'autres détails émergent, une chose est devenue claire : les attaquants ont abusé des certificats et des clés X.509 dans le cadre de leur boîte à outils pour se faire passer pour des personnes de confiance et éviter d'être détectés. L'affaire a commencé avec SolarWinds, mais elle ne s'arrête pas là.

Un article récemment publié par le Microsoft Security Response Center passe en revue certains des détails techniques de l'attaque de la chaîne d'approvisionnement. Voici quelques informations clés sur la manière dont les certificats X.509 ont été utilisés par les attaquants pour falsifier et saper la confiance :

Un fil d'Ariane nous ramène à SolarWinds, où les attaquants ont modifié le code source pour y inclure une porte dérobée malveillante, qui a ensuite été compilée, signée et transmise à son insu par SolarWinds à près de 18 000 clients par le biais de ses systèmes de mise à jour et de signature de code software .

La violation initiale n'était pas le résultat d'un certificat de signature de code volé, mais la bibliothèque falsifiée était signée par SolarWinds, ce qui la faisait apparaître comme légitime aux yeux des systèmes des utilisateurs finaux. Bien qu'il n'y ait aucune preuve que le certificat de signature ou le processus lui-même ait été compromis, le processus de construction et de révision avant la signature a été compromis, ce qui a permis au code malveillant de se faufiler.

Ce n'est pas la première fois non plus. Les attaquants utilisent de plus en plus la confiance à laquelle nous nous fions. Des attaques similaires contre la chaîne d'approvisionnement ont impliqué soit le vol de certificats de signature de code, comme les attaques menées par APT41 et Kimsuky, soit l'intégration d'un code falsifié dans le processus de signature, comme l'attaque contre ASUS l'année dernière.

Selon Microsoft, "une fois dans le réseau, l'intrus utilise les autorisations administratives acquises par le biais de la compromission sur site pour accéder au compte d'administrateur global de l'organisation et/ou au certificat de signature de jeton SAML de confiance".

Dans ce cas, les attaquants ont falsifié des jetons SAML et les ont signés avec des certificats légitimes compromis pour se faire passer pour des utilisateurs et des comptes de confiance, ce qui leur a permis de se déplacer latéralement sans être détectés.

Dans certains cas, l'acteur malveillant a modifié les paramètres d'Azure Active Directory pour obtenir un accès à long terme, notamment en "ajoutant des informations d'identification (clés X.509 ou mots de passe) à une ou plusieurs applications OAuth légitimes..."

Une fois qu'ils ont pris pied, la priorité suivante pour les attaquants est souvent de trouver des moyens de rester à l'intérieur. Ici, ils ont utilisé des certificats X.509 pour créer un accès OAuth légitime au réseau.

Comme je l'ai mentionné précédemment, il n'existe pas de solution miracle pour prévenir ces attaques sophistiquées. Il s'agissait d'une attaque très sophistiquée qui faisait appel à de nombreux outils et techniques différents.

Nous ne sommes pas là pour spéculer, mais plutôt pour attirer l'attention sur un problème croissant que nous observons dans l'industrie : l 'utilisation abusive et le vol de clés et de certificats numériques. Il ne s'agit pas de cette violation ou de la prochaine, mais de la nécessité de suivre et de contrôler efficacement l'utilisation des certificats dans les applications, l'infrastructure en nuage et le réseau.

Voici quelques bonnes pratiques recommandées pour limiter l'utilisation abusive des clés et des certificats :

• Maintenez un inventaire actif de tous les certificats, de l'endroit où ils sont installés, de leur émetteur et de leur propriétaire (et de vos domaines).
• Contrôlez l'émission des certificats et les flux de travail d'approbation pour vous assurer que chaque certificat est fiable, conforme à la politique et à jour.
• Testez régulièrement vos capacités de réémission et de révocation des certificats afin de vous assurer que vous pouvez réagir efficacement en cas de compromission.
• Ne jamais stocker les clés de signature de code sur les postes de travail des développeurs ou sur les serveurs de construction. Les clés privées doivent être conservées dans un HSM validé par la norme FIPS 140-2 et ne jamais quitter le site hardware.
• Séparer les tâches entre les personnes autorisées à signer le code, celles qui peuvent approuver la demande et celles qui peuvent contrôler et faire respecter les politiques de signature.
• Définissez des politiques pour limiter l'accès aux clés de signature de code par utilisateur, machine, lieu, durée, heure de la journée, méthode de signature ou tout autre paramètre pertinent pour votre organisation.

Pour en savoir plus sur les tendances observées en matière d'utilisation (et d'abus) de la cryptographie, consultez notre rapport 2021 sur les tendances en matière de cryptographie.