Avec une plus grande variété de services dans le cloud, les questions de sécurité se font de plus en plus présentes. Ainsi, une équipe d’experts de la société Wiz a découvert deux failles dans l’offre Server Flexible PostgreSQL dans Azure. En les combinant, il est possible de mener une attaque baptisée ExtraReplica, qui donne accès aux base de données d’autres utilisateurs sur le cloud. Ces vulnérabilités sont relatives à une élévation de privilèges, offrant la possibilité d’exécuter du code au sein du conteneur hébergeant leur propre base de données et un contournement de l’authentification pour abuser du service de réplication.

Les failles ont été corrigées côté serveur, de sorte que les clients n’ont pas besoin d’intervenir pour sécuriser leurs instances. Mais les chercheurs demandent à Microsoft et autres fournisseurs de cloud de fournir une meilleure documentation sur les modèles d’isolation et d’architecture de leurs services pour mieux évaluer les risques.

Un accès via l’interface réseau interne

L’offre PostgreSQL dans Azure est un service managé de la base de données relationnelle open source. Ce dernier est doté de nombreuses fonctionnalités et met l’accent sur la stabilité, la haute disponibilité et la montée en charge. Microsoft propose trois versions de déploiement pour le service Azure Database for PostgreSQL: Single Server, Flexible Server flexible et Hyperscale (Citus). La déclinaison Flexible Server ciblée par les failles propose de la haute disponibilité au sein d’une ou plusieurs zones géographiques. Son architecture comprenant l’isolation du calcul et du stockage. Le moteur de SGBD s’exécute sur un conteneur dans une machine virtuelle Linux, tandis que les fichiers de données résident sur le stockage Azure avec trois copies synchrones en local des données.

Les chercheurs de Wiz ont donc lancé une instance Flexible Server et ont commencé à exécuter des requêtes dans leur base de données afin de comprendre son environnement. Ils ont déterminé qu'il se trouvait dans un conteneur Docker exécutant Ubuntu 18.04.6 LTS avec un noyau récent. Ils ont également examiné les interfaces réseau et ont remarqué une interface qui autorisait les connexions à partir d'un bloc d’adresses IP interne. Ensuite, ils ont créé une autre base de données dans un compte Azure différent et ont essayé d'y accéder depuis leur premier compte via le port 5342 (PostgreSQL) en utilisant l'interface réseau interne. La connexion a fonctionné même si le pare-feu était configuré pour bloquer tous les accès. Cela signifie que les accès entre les bases de données de différents utilisateurs (tenants) étaient possibles via le réseau interne. Une première étape suffisante, mais pas concluante car les chercheurs ne disposaient toujours pas des informations d’authentification pour accéder à l’autre base de donnée

Le contournement de l’authentification

Poursuivant leur quête, les experts se sont alors demandés pourquoi cette connexion réseau interne entre utilisateurs était autorisée et ont décidé d'examiner deux fichiers trouvés sur la machine, appelés pg_hba.conf et pg_ident.conf. Selon la documentation de PostgreSQL, ces fichiers sont responsables de l'authentification des clients et des mappages de noms d'utilisateurs. Le fichier pg_hba.conf est le plus intéressant en révélant qu’un agent baptisé replication était autorisé à se connecter via le réseau interne en se basant sur un certificat pour s’authentifier. Cet agent fait partie de la fonction de réplication de bases de données Azure pour créer des copies de sauvegarde des bases de données ou de les répliquer sur plusieurs serveurs.

Pour cette question d’authentification, les spécialistes ont analysé le fichier pg.ident.conf et ont trouvé une expression régulière destinée à valider le certificat du client. Il s’agit en général d’un nom de domaine ou de sous-domaine. Dans le cas présent, le certificat de la réplication était sur le format replication.eee03a2acfe6.database.azure.com. S’il était impossible pour les chercheurs d’obtenir un certificat auprès d’une autorité avec Azure.com, l’équipe de Wiz a constaté que la chaîne de caractères se terminait par .*. Cela signifie que l’expression régulière pouvait correspondre replication.eee03a2acfe6.database.azure.com mais aussi replication.eee03a2acfe6.database.azure.com.something-else.com. Ils ont donc demandé un certificat auprès de DigiCert, et ils ont pu se connecter à leur propre base de données en tant que réplication et en disposant de toutes les autorisations de lecture.

Comme les connexions aux autres bases de données via le réseau interne étaient possibles et que l'usurpation d'identité du compte de réplication et de ses privilèges étaient possibles, le seul élément d'information manquant pour accéder à la base de données d'un autre client était de trouver l'ID unique tel que eee03a2acfe6 attribué à la base de données cible et d'obtenir un certificat. Ce n’était pas difficile du tout car il était inclus dans le certificat du serveur de la base de données cible lors de la connexion à celui-ci via SSL. Les chercheurs notent néanmoins que l'attaque ne fonctionne que contre les bases de données d'une même région, mais il est facile de déterminer la région de disponibilité Azure d'une base de données particulière en examinant les adresses IP des serveurs qui les hébergent. Il suffit alors aux attaquants potentiels de créer un compte dans la même région.

L’impact d’ExtraReplica

Les offres Azure PostgreSQL Single Server ont également été affectées par la première vulnérabilité d'élévation de privilèges de PostgreSQL, mais pas par le contournement de l'authentification inter-tenant utilisant le service de réplication. De plus, les instances Flexible Server n'étaient pas impactées, si elles étaient configurées pour un accès privé virtuel (intégration VNet). VNet est la fonctionnalité de réseau virtuel d'Azure.

Lors de la première configuration de leur compte Azure PostgreSQL, les utilisateurs doivent choisir leur préférence de connectivité réseau entre l'accès public via les adresses IP autorisées, qui est l'option par défaut, et l'accès privé via VNet. Cela dépend de la façon dont ils souhaitent que leurs applications communiquent avec la base de données et il est difficile de dire combien d'utilisateurs choisissent l'option VNet. Selon les chercheurs de Wiz, Microsoft n'a pas divulgué le nombre de clients potentiellement touchés, mais a déclaré ne pas avoir connaissance de tentatives d'exploitation de ces vulnérabilités.

« Microsoft et d'autres fournisseurs de cloud publient généralement de la documentation sur leurs modèles d'isolation et leur architecture « », ont déclaré les chercheurs. « Cependant, nous avons remarqué que le serveur flexible PostgreSQL manque de documentation publique sur l'isolation, ce qui rend difficile pour les clients d'évaluer le risque lorsqu'ils intègrent un tel service. Ce problème n'est pas propre à Azure, car les autres fournisseurs de cloud ont tendance à partager le modèle d'isolation pour un nombre limité de services seulement. » Ils ont également noté que, contrairement aux failles de sécurité des logiciels, les vulnérabilités et les mauvaises configurations des services cloud ne reçoivent pas d'identifiant CVE, ce qui les rend plus difficiles à suivre ou à surveiller. C'est pourquoi une communauté des volontaires s'efforce de créer une base de données sur les problèmes et les incidents de sécurité dans le cloud.