Après plus de deux mois d’enquête, Microsoft annonce avoir terminé son investigation interne autour des attaques exploitant la brèche au cœur de SolarWinds Orion. Et les dégâts semblent limités. L’éditeur en profite pour mettre en évidence certaines leçons à en retirer.

Dans un long billet de blog, l’équipe d’investigation du MSRC (Microsoft Security Response Center) dévoile les résultats de son enquête autour de l’attaque sur ces systèmes menée par une équipe de hacker au travers de la brèche SunBurst/Solorigate du logiciel de supervision réseau SolarWinds Orion.
Rappelons qu’au moins une centaine d’entreprises clientes de ce logiciel ont été victimes d’une série d’attaques d’espionnage et d’infiltrations menées par une équipe de hackers probablement financées par une intelligence étatique.

Dès le début du billet, l’équipe MSRC cherche à rassurer ses clients en expliquant n’avoir trouvé aucune preuve que les hackers aient eu accès à ses systèmes de production et aux données des clients ni que des systèmes Microsoft aient été utilisés pour porter des attaques sur d’autres entreprises. L’éditeur affirme que les hackers n’ont pas réussi à obtenir les accès privilégiés nécessaires et à utiliser les techniques SAML (Security Assertion Markup Language) contre ses domaines corporate.
Néanmoins, les hackers ont visité plusieurs serveurs et espaces de stockage internes contenant notamment des codes sources.

Des dégâts limités…

Si les attaques menées à travers SolarWinds Orion dans le monde ont probablement commencé en juin 2020, Microsoft confirme que les plus anciennes traces de ces attaques sur ses propres infrastructures remontent à la fin novembre 2020. Cependant l’éditeur n’a détecté des activités inhabituelles qu’à partir de décembre 2020. Évidemment, des premières mesures de blocage et remédiation ont commencé dès ces premières détections, mais l’éditeur a continué à repérer des tentatives d’accès (qui ont toutes échoué) jusqu’au début de janvier 2021. Les tentatives se sont ensuite arrêtées.

L’éditeur confirme qu’un petit nombre de dossiers contenant des sous-ensembles de codes sources Azure, Intune et Exchange ont bien été accédés par les hackers et certains de ces codes ont effectivement été téléchargés. Toutefois selon Microsoft, « il n’y a eu aucun cas où tous les référentiels liés à un produit ou service unique ont été consultés. Les hackers n’ont pas accédé à la grande majorité du code source de ces produits. Pour presque tous les référentiels de code accessibles, seuls quelques fichiers individuels ont été consultés à la suite d’une recherche dans le référentiel ».

… Mais des codes sources téléchargés.

En un mot, les hackers n’étaient pas intéressés par les codes sources des produits, mais ciblaient très précisément leurs recherches pour ne pas se faire trop rapidement repérer, mais également obtenir des éléments pouvant leur être utiles… à préparer d’autres attaques. Car les produits ciblés sont tout sauf innocents. Les services Azure ciblés par les hackers étaient les codes sources de services de sécurité et de contrôle des identités. Intune est le service d’administration à distance de tous les terminaux mobiles des entreprises. Exchange est le service de messagerie email qui sert de fondation à Outlook.com et à Microsoft 365.

Microsoft reconnaît d’ailleurs que « les termes de recherche utilisés par les attaquants indiquent un accent sur la recherche de secrets ». L’éditeur précise cependant que « notre politique de développement interdit les secrets dans le code et nous utilisons des outils automatisés pour vérifier cette conformité. En raison de l’activité détectée, nous avons immédiatement lancé un processus de vérification pour les branches actuelles et historiques des référentiels. Nous avons confirmé que les référentiels piratés étaient conformes et ne contenaient pas d’informations d’identification ».

Des leçons à en tirer

Pour Microsoft, toutes les entreprises (à commencer par l’éditeur lui-même) ont des leçons à tirer de cette attaque. « L’industrie de la cybersécurité est consciente depuis longtemps que des acteurs sophistiqués et bien financés sont théoriquement capables de techniques avancées, de patience et de fonctionner sous le radar… cet incident prouve que tout ceci n’est pas seulement théorique ».

Pour l’équipe MSRC, il est aujourd’hui impératif pour toutes les entreprises d’embrasser une culture « Zéro Trust » et de protéger aussi durement que possible les accès à privilèges.

La notion de « Zéro Trust » impose de définitivement en finir avec la pratique du « tout ce qui est dans le réseau interne de l’entreprise est sain et sûr ». Au contraire, il est essentiel d’assumer que tous les systèmes peuvent être compromis et même qu’ils le sont déjà. Dans ce modèle, tout doit être mis en œuvre pour sans cesse vérifier explicitement le statut de l’utilisateur authentifié, du endpoint utilisé, du réseau utilisé, et autres ressources accédées.

La gestion des comptes à privilège est d’autant plus essentielle aujourd’hui que la compromission d’un compte administrateur « on premises » conduit souvent aujourd’hui à également compromettre l’accès à toutes les ressources clouds de l’entreprise. D’où la nécessité de bien segmenter les profils et les droits, et de limiter l’utilisation des comptes à privilèges pour des accès bien identifiés et pour une très courte durée.

Enfin la dernière leçon à en tirer est qu’il ne peut exister de cybersécurité sans un minimum de transparence et une volonté de tous les acteurs d’échanger et collaborer. Et les responsables du MSRC de rappeler que la cybersécurité n’est pas une destination, mais un voyage itératif vers une certaine forme de perfection… Un long voyage, semé d’embûches.