Protéger les clés d’accès – Leçons tirées du hack des clés Azure

Ce qui s'est passé

Le 15 mai, l'acteur étatique basé en Chine et identifié sous le nom de Storm-0558 a accédé aux systèmes de messagerie Office 365 basés sur Azure. L'attaque a été découverte après que des clients d'Office 365 aient commencé à signaler des activités de messagerie inhabituelles. Le 16 juin, Microsoft a entamé le processus d'enquête et de remédiation.

Microsoft a découvert que les clés d'accès utilisées n'avaient pas été émises par son organisation. Au lieu de cela, Storm-0558 avait forgé des clés en utilisant une clé Microsoft account (MSA) consumer signing key volée pour créer de fausses clés privées Azure Active Directory (AD). Dans le même temps, ils ont exploité une vulnérabilité désormais corrigée qui permettait d'utiliser des clés sur plusieurs systèmes.

Le professeur Bill Buchanan OBE a publié sur son blog un article intitulé "Losing The Keys To The Castle : Azure Key Breach Should Worry Every Organisation", qui explique en détail comment fonctionne la signature par token et comment cette attaque a réussi. L'analyse de l'incident par Microsoft contient plus de détails techniques sur l'incident.

Ce qu’il est possible de faire

Microsoft a déclaré n'avoir trouvé aucune preuve indiquant un accès non autorisé supplémentaire après avoir terminé ses efforts d'atténuation. Microsoft assure à ces clients qu'il n'y a plus de raison de s'inquiéter.

L'équipe a identifié plusieurs domaines dans lesquels elle devait améliorer la sécurité, notamment en isolant davantage les systèmes, en affinant la surveillance de l'activité du système et en adoptant une utilisation cohérente de la base de données de clés de l'entreprise. Examinons de plus près ces leçons et d'autres que nous pouvons tirer de cet incident pour nous aider à rester plus en sécurité.

Être à l'affût de toute information suspecte

Un fait qui ressort de tous les rapports est que l'attaque n'a pas été découverte par des analyses ou des alarmes internes ; elle a d'abord été identifiée par des utilisateurs qui ont remarqué quelque chose d'anormal. Il est très utile d'être à l'écoute des réactions des utilisateurs pour déceler les indices d'une attaque. Tout comme le fait de se fier uniquement aux remontées par des humains n'est pas une bonne solution, le fait de se fier excessivement aux alertes automatisées est tout aussi erroné.

Rappeler aux clients et aux membres de l'équipe interne de signaler tout ce qui sort de l'ordinaire lorsqu'ils utilisent le produit. Non seulement cela peut contribuer à la sécurité, mais cela peut aussi aider à trouver et à éliminer d'autres bogues non liés à la sécurité. Réviser régulièrement les playbooks pour s’assurer que le processus de détection des problèmes de sécurité éventuels et les voies d'escalade sont clairs et à jour. Il est important que les équipes chargées de suivre les clients et les équipes chargées de la sécurité travaillent ensemble pour identifier les problèmes de sécurité potentiels.

Stocker toutes les clés en toute sécurité

Lorsque l'équipe de Microsoft a enquêté pour la première fois sur la situation, elle a supposé que les attaquants utilisaient des clés de clients volées. Il y a de bonnes raisons de penser cela, car le problème de la prolifération des secrets ne cesse de s'aggraver. Une clé a bien été volée. Cependant, il ne s'agissait pas des clés des utilisateurs finaux, mais de la clé utilisée pour vérifier que les informations d'identification étaient légitimes. Toutefois, quelle que soit la puissance d'un identifiant, il s'agit toujours d'une clé qui doit être correctement stockée, ce qui signifie qu'elle doit être chiffrée.

Bien que nous ne sachions pas exactement comment cette clé a été acquise, certaines déclarations concernant l'amélioration de l'utilisation du "key store de l'entreprise" nous amènent à nous interroger sur la manière dont ces clés de signature très importantes ont été stockées. Le stockage des clés dans un système de coffre-fort, tel que Vault de Hashicorp, Azure Key Vault ou Doppler, offre de nombreux avantages en matière de sécurité.

• Chiffrement au repos - les clés sont stockées dans un état illisible et inutilisable.
• Accès programmatique - seules les références au secret dans le coffre-fort sont partagées dans la base de code.
• Chiffrement en transit - les clés ne sont déchiffrées qu'à leur arrivée, au moment de l'exécution.
• Journalisation de la gestion des accès et des modifications - à partir d'un emplacement central, pour savoir qui a ajouté ou modifié un identifiant, ainsi que le moment où les clés ont été consultées.

Une autre approche qui mérite d'être envisagée consiste à stocker les secrets dans un module de sécurité matériel (HSM). Comme son nom l'indique, un HSM nécessite du matériel supplémentaire dans votre infrastructure, qui peut approvisionner, stocker et gérer des clés cryptographiques. Les HSM peuvent fournir des couches de sécurité supplémentaires au sein de leur architecture physique qui vont au-delà de ce qui peut être accompli par le seul logiciel.

Ne pas réutiliser les clés pour plusieurs services

Une autre raison pour laquelle les attaquants ont réussi à percer cette brèche est que les clés d'un système pouvaient donner accès à plusieurs autres systèmes. La leçon à tirer de cette vulnérabilité est que chaque clé doit être unique et spécifique à un travail, ce qui s’appelle "l'isolation des systèmes".

Lorsque l'on a affaire à des environnements DevOps complexes, il peut être tentant de penser que parce que quelqu'un ou quelque chose a été autorisé à accéder à un service de confiance, il devrait être autorisé à accéder à d'autres systèmes sensibles. C'est toujours une mauvaise décision du point de vue de la sécurité. Les attaquants essaieront presque toujours de se déplacer latéralement dans un environnement, et ils savent à quel point il est courant de réutiliser les informations d'identification. Ils essaieront très certainement d'utiliser les mêmes informations d'identification qui ont fonctionné une fois dans tous les autres verrous qu'ils rencontrent.

La philosophie architecturale de la confiance zéro consiste à restreindre le champ d'application des informations d'identification pour n'autoriser que l'accès minimum nécessaire à l'accomplissement du travail. De même que la réutilisation des mots de passe est néfaste, les informations d'identification à large portée qui permettent d'accéder à plusieurs systèmes sont également à éviter.

Vérifier régulièrement ses logs

L'une des premières mesures prises par l'équipe de Microsoft dans le cadre de son enquête a été d'examiner les logs afin d'identifier le moment où l'accès inattendu s'est produit et les clés utilisées. Les logs peuvent fournir de nombreuses informations après un incident, une fois l'attaque terminée, mais ils peuvent également aider à identifier une attaque en cours.

Si l'examen régulier des logs d'accès ne fait pas partie des pratiques de sécurité d’une entreprise, il faut ajouter cette étape à ses tâches quotidiennes ou hebdomadaires. Il existe de nombreuses solutions sur le marché pour faciliter la surveillance des logs, telles que Sumo Logic et Datadog, qui peuvent identifier et faire remonter à la surface des activités inhabituelles beaucoup plus rapidement.

Affiner plan de rotation des secrets

L'une des principales mesures prises par Microsoft pour remédier à l'incident a consisté à révoquer et à remplacer les clés de signature. Quelle que soit la clé compromise, la rotation des clés est un élément central de tout plan de réponse à un incident. L'un des signes les plus évidents de la maturité en gestion des secrets est la programmation d'une rotation régulière et automatisée des secrets. La plupart des fournisseurs de cloud, comme AWS, font de la rotation automatisée des clés un processus simple.

Si une entreprise n’est pas encore prête à adopter la rotation automatique, elle devrait au moins viser une rotation régulière. Plus la rotation des informations d'identification est fréquente, en particulier lorsqu'il n'y a pas de pression réelle et que les enjeux sont moindres, plus il sera facile de procéder à une rotation en cas d'indécence.

Surveiller activement les informations d'identification dans vos environnements

Savoir qu'un secret a été volé seulement après l'attaque, c'est le savoir trop tard. L'une des meilleures façons de se protéger est de savoir quand vos clés sont exposées en clair à n'importe quel moment du cycle de développement du logiciel. C'est là que des outils de Secret Scanning sont nécessaires. 

Bien que l'attaque Storm-0558 contre les clients de Microsoft se soit appuyée sur un certain nombre de vulnérabilités spécifiques, nous pouvons tous en tirer des leçons précieuses. Conserver tous nos secrets de manière cohérente et correcte est un très bon début. Les bonnes pratiques sont de limiter les informations d'identification à un seul cas d'utilisation et de ne jamais les réutiliser dans plusieurs services afin de s’assurer qu'en cas d'attaque basée sur la fuite d'une clé, l'accès sera extrêmement limité. Une rotation régulière des clés ainsi qu'une surveillance active de l'activité inhabituelle dans les journaux d’une entreprise sont essentielles pour rester en sécurité dans un monde où les défis de sécurité évoluent sans cesse. Le fait d'être alerté de la présence d'informations d'identification en clair dans des environnements permettra de garder une longueur d'avance sur les attaquants.

La sécurité est un voyage ; personne ne sait tout ce qu'il y a à savoir sur le sujet. Afin d’améliorer sa posture de sécurité, il faut franchir les étapes petit à petit.