Microsoft Azure Cosmos DB : les leçons d’une faille majeure
Avec de nouvelles fonctionnalités ajoutées chaque jour, la recherche de vulnérabilités « zero-day » est une course sans fin entre, d’une part, les chercheurs en sécurité qui les débusquent et, d’autre part, les attaquants qui cherchent à les exploiter dans une quête de profits.
Ce mois d’août 2021, une nouvelle vulnérabilité dans la plateforme cloud Azure a été découverte par Wiz, une équipe de recherche en vulnérabilités spécialisée dans l’architecture Cloud. Cette faille permettait à n’importe quel utilisateur Azure d’obtenir un accès complet à l’instance Cosmos DB d’un autre utilisateur sans autorisation.
Cette vulnérabilité, appelée Chaos DB, est identifiée comme une vulnérabilité « zero-day » : elle était totalement inconnue jusqu’alors et, de ce fait, ne disposait d’aucun correctif au moment de sa découverte.
Ainsi pendant plusieurs mois, des données de milliers d’entreprises utilisatrices de Cosmos DB ont été exposées et ont pu être volées ou supprimées par des personnes mal intentionnées. Cosmos DB, largement utilisé chez de grands comptes selon l’éditeur, notamment dans la gestion de données en masse, est un service de base de données NoSQL utilisé dans de nombreux domaines tels que la vente au détail en temps réel, la gestion d’appareil IoT ou l’hébergement de données d’applications distribuées mondialement.
Ecrit par Sébastien Chauveau.
Une exploitation « triviale »
Wiz qualifie sur son propre blog l’exploitation de cette vulnérabilité comme triviale et explique que l’exploitation de cette faille ne nécessite aucun accès préalable à l’environnement cible. La source de cette faille : une série de mauvaises configurations dans Jupyter Noteboook.
L’attaque consiste à exploiter ces vulnérabilités de Jupyter Notebook pour permettre une élévation de privilèges et l’accès à la clé primaire de l’instance Cosmos DB de la cible par des requêtes. Une fois cette clé primaire acquise, l’attaquant peut l’utiliser pour avoir un accès administrateur (en lecture, écriture et suppression) à l’ensemble de l’instance Cosmos DB ciblée, avec par conséquence un accès à long terme aux données y étant stockées et la possibilité de les manipuler à sa guise. Ci-dessous un schéma présentant le fonctionnement de l’attaque :
Une réaction rapide de Microsoft
Dans les 48 heures suivant le signalement de la vulnérabilité, Microsoft a pris des mesures rapides pour désactiver les fonctionnalités à risque et empêcher que cette faille reste exploitable en rendant impossible la première partie de l’attaque (Partie 1 du schéma ci-dessus).
Cependant, la vulnérabilité a été présente pendant des mois et permettait d’accéder à des clés primaires garantissant un accès long terme aux données exposées même une fois la faille colmatée. (Partie 2 du schéma ci-dessus).
Microsoft a contacté les utilisateurs de Cosmos BD ayant activé la fonctionnalité Jupyter Notebook durant la période de recherche de l’équipe de sécurité ayant découvert la faille. Cela correspond à environ 30% des utilisateurs totaux de Cosmos DB. Cependant pour Wiz, cette action n’est pas suffisante car la fonctionnalité a été présente pendant des mois, et tout compte utilisant Jupyter Notebook ou ayant été créé à partir de février 2021 peut avoir été compromis.
Par conséquent des actions correctives complémentaires doivent être prises pour les comptes Azure Cosmos DB.
Quelles sont les mesures à prendre pour protéger Azure Cosmos DB ?
Microsoft demande à tous les clients ayant des comptes Cosmos DB utilisant Jupyter Notebook ou ayant été créés après Janvier 2021, de régénérer la clé primaire en lecture et écriture des comptes Cosmos DB à risque. Des détails sur la démarche et les actions à effectuer peuvent être trouvés dans le guide fourni par Microsoft.
Microsoft signale également que les comptes possédant un vNET (réseau virtuel) ou un pare-feu actif possèdent des mécanismes de protection supplémentaires qui peuvent empêcher les accès non autorisés. En effet, il est possible de configurer le pare-feu pour limiter l’accès à certaines adresses IP seulement en suivant ce guide de Microsoft et il est possible de limiter l’accès aux services de la base de données uniquement aux utilisateurs passant par le réseau virtuel. Les actions à effectuer sont détaillées ici. Par conséquent, même si des attaquants récupèrent les clés, ils ne pourront pas avoir accès aux données puisqu’ils ne pourront pas se connecter au réseau.
Par précaution, Microsoft recommande donc de mener les actions suivantes afin d’augmenter le niveau de sécurité des comptes Azure :
- Planifier une rotation et régénération régulières des clés primaires et secondaires
- Utiliser le pare-feu Azure Cosmos DB et l’intégration d’un réseau virtuel afin de contrôler l’accès aux comptes au niveau du réseau
- Dans le cas où le client utilise Azure Cosmos DB Core (SQL) API : Utiliser l’accès à base de rôles (RBAC) pour s’authentifier avec Azure Active Directory au lieu d’utiliser les clés primaires et secondaires, ce qui permet de désactiver complètement les clés primaires et secondaires.
- Se référer aux lignes de bases de sécurité pour une vision complète sur les possibilités de sécurisation de l’environnement Azure Cosmos DB.
Ces différentes mesures permettent d’empêcher qu’une personne qui aurait eu accès à des clés primaires lorsque la faille était présente de pouvoir continuer à avoir accès à la base de données en question.
Cet événement rappelle l’importance des bonnes pratiques de sécurité. En effet, chaque mesure supplémentaire agit comme un rempart de plus pour protéger ses données. Si l’un d’entre eux vient à tomber suite à une nouvelle vulnérabilité, d’autres seront toujours présents pour empêcher une attaque d’aboutir.
Ainsi une mesure (comme du whitelisting IP par exemple) qui paraît redondante aujourd’hui pourrait protéger contre une zero-day de demain. Les entreprises ont donc tout intérêt, lorsque l’occasion se présente, à implémenter des mesures de sécurité simples et peu coûteuses (« quick win ») dans le but de se protéger en cas de défaillances d’autres systèmes de sécurité.
Chronologie des événements de la faille d’Azure Cosmos DB
- 2019 – Ajout de la fonctionnalité Jupyter Notebook à Azure Cosmos DB
- Février 2021 – Jupyter Notebook activé par défaut sur Cosmos DB
- 09 Août 2021 – Découverte et première exploitation de la faille par Wiz
- 12 Août 2021 – Wiz alerte Microsoft sur la présence de cette vulnérabilité
- 14 Août 2021 – Microsoft désactive les fonctionnalités à risque
- 17 Août 2021 – Le Microsoft Security Response Center offre une prime de $40,000 à Wiz pour avoir signalé la faille
- 26 Août 2021 – Divulgation de l’affaire au grand public
Crédit photo : Mike Mozart