dimanche, 21 avril 2024

Les chercheurs rompent l’isolation de la base de données en tant que service Azure PostgreSQL avec une attaque entre locataires

Crédit : Dreamstime

Un groupe de scientifiques a découvert 2 vulnérabilités dans le serveur flexible Azure PostgreSQL de Microsoft qui, une fois enchaînés, leur permettaient d’accéder aux bases de données PostgreSQL d’autres locataires du cloud.

L’attaque, surnommée ExtraReplica car elle abusait des fonctionnalités liées à la duplication de la base de données, intègre une vulnérabilité d’escalade de privilèges qui leur a donné la capacité d’exécuter du code à l’intérieur du conteneur hébergeant leur propre base de données et un autre problème de contournement d’authentification qui leur a permis de abuser du service de duplication du système pour accéder aux bases de données d’autres utilisateurs.

Les failles ont été corrigées côté serveur, de sorte que les clients n’ont rien à faire pour sécuriser leur situation, cependant les chercheurs de la société de sécurité cloud Wiz qui a découvert les problèmes a contacté Microsoft et d’autres fournisseurs de services cloud pour fournir de meilleurs documents sur les modèles d’isolement et l’architecture de leurs services afin de permettre aux clients de mieux évaluer les dangers pour leurs informations lors de l’intégration.

De la base de données au système sous-jacent

La base de données Azure pour PostgreSQL est une base de données gérée -en tant que service ce basé sur le moteur de base de données relationnelle open-source PostgreSQL qui est en développement depuis plus de trente ans.

PostgreSQL est un logiciel complexe avec de nombreuses fonctions qui mettent l’accent sur la stabilité, la haute disponibilité et l’évolutivité. Microsoft fournit le service Azure Database pour PostgreSQL en 3 variantes de version : serveur unique, serveur flexible et hyperscale (Citus).

Le serveur flexible permet aux consommateurs d’optimiser leurs dépenses en choisissant une haute accessibilité dans une seule zone d’accessibilité Azure ou sur plusieurs zones d’accessibilité ou en arrêtant et en démarrant leurs serveurs et leur niveau de calcul extensible selon les besoins.

L’architecture sépare le calcul et le stockage avec le moteur de base de données s’exécutant à l’intérieur d’un conteneur dans un appareil virtuel Linux et les fichiers de données vivant sur le stockage Azure dans 3 copies simultanées redondantes dans votre région.

L’une des fonctionnalités du moteur PostgreSQL consiste à exécuter des commandes système natives via des requêtes de base de données. Les chercheurs de Wiz se sont inscrits sur le serveur et ont commencé à poser des questions dans leur base de données pour comprendre l’environnement.

Ils avaient la possibilité de déterminer que l’utilisateur de la base de données auquel le service était proposé n’avait pas la fonction essentielle pour exécuter du code, comme des commandes de célébration. Cela les a amenés à essayer de trouver des recherches antérieures sur les méthodes possibles pour intensifier les opportunités à l’intérieur de PostgreSQL et a finalement trouvé un bogue dans l’implémentation de Microsoft.

 » En recherchant nos circonstances, nous avons découvert qu’Azure avait modifié son moteur PostgreSQL,  » le les chercheurs ont déclaré dans un post.

 » Il est probable qu’Azure ait présenté ces changements au moteur PostgreSQL pour solidifier leur conception d’avantage et ajouter de nouvelles fonctions. Nous avons réussi à exploiter un bogue dans ces ajustements pour obtenir une escalade des avantages, nous permettant d’effectuer des enquêtes arbitraires en tant que superutilisateur. L’obtention d’avantages de superutilisateur nous a permis d’effectuer des commandes au niveau du système d’exploitation en fonction de nos circonstances. « 

Bien que cette vulnérabilité ait été signalée à Microsoft en janvier et couverte, les chercheurs ne souhaitent pas publier d’informations sur l’exploitation mais par crainte que d’autres fournisseurs aient apporté des modifications comparables à leurs moteurs PostgreSQL et aient présenté exactement le même bogue.

Une fois qu’ils ont acquis la capacité d’exécuter des commandes système, les scientifiques ont compris qu’ils étaient à l’intérieur un conteneur Docker exécutant Ubuntu 18.04.6 LTS avec un noyau actuel. Ils ont également examiné les interfaces utilisateur du réseau et ont observé une interface qui permettait les connexions à partir d’un netblock IP interne.

Ils ont ensuite créé une autre base de données dans un compte Azure différent et ont tenté d’y accéder à partir de leur premier compte en utilisant le port 5342 (PostgreSQL) à l’aide de l’interface réseau interne.

La connexion fonctionnait même lorsque le pare-feu était configuré pour obstruer toutes les connexions, ce qui indiquait que les connexions entre les bases de données des différents occupants étaient possibles via le réseau interne, bien que cela ne veuille pas dire grand-chose puisqu’elles ne le faisaient toujours pas disposer des informations d’identification appropriées pour accéder à l’autre base de données et y lire ou y écrire.

Échec de l’authentification du client basée sur un certificat

Les chercheurs ont alors demandé pourquoi ce réseau interne connection across-tenants a obtenu la première place et a choisi de jeter un œil à 2 fichiers trouvés sur la machine appelée pg_hba. conf et pg_ident. conf. Selon la documentation PostgreSQL, ces fichiers sont responsables de l’authentification des clients et des mappages de noms d’utilisateur.

Le fichier pg_hba. conf a révélé qu’un utilisateur appelé duplication était autorisé à se connecter via le réseau interne en utilisant une authentification basée sur des certificats. Cet utilisateur fait partie de la fonction de réplication de base de données d’Azure qui permet de développer des copies de sauvegarde de bases de données ou de reproduire des bases de données sur des serveurs.

Les scientifiques se sont ensuite penchés sur pg_ident. conf et a découvert une expression régulière implicite pour confirmer le certificat client en examinant le CN (nom typique) pour lequel il a été fourni. Il s’agit généralement d’un nom de domaine ou de sous-domaine. Dans ce cas, la base de données a été configurée pour activer les connexions en tant qu’utilisateur de duplication si la connexion client présentait un certificat correspondant à replication.eee03a2acfe6.database.azure.com.

Le eee03a2acfe6 est un identifiant unique à leurs circonstances particulières de base de données, donc un tel certificat fournirait simplement l’accès à leur propre base de données, mais obtenir un tel certificat auprès d’une autorité de certification de confiance serait difficile car les chercheurs n’ont pas posséder azure.com pour passer la reconnaissance.

Cependant, les chercheurs ont vu une erreur dans l’expression de routine car elle se terminait par la chaîne (. *). Cela indique qu’il correspondrait non seulement à un certificat pour replication.eee03a2acfe6.database.azure.com mais également à replication.eee03a2acfe6.database.azure.com.something-else. com.

Les scientifiques ont entrepris d’obtenir un certificat de DigiCert, l’une des autorités de certification publiques approuvées par le système, correspondant au sous-domaine prévu mais sur un domaine qu’ils possédaient. Cela a fonctionné et leur a permis de se connecter à leur propre base de données en tant que service de réplication, qui a des autorisations de lecture complètes.

Parce que des connexions à d’autres bases de données par le biais du réseau interne étaient possibles et usurpant le compte de duplication et ses opportunités était possible, la seule information manquante pour accéder à la base de données d’un autre client était de découvrir l’ID spécial tel que eee03a2acfe6 affecté à la base de données cible et d’obtenir un certificat avec un CN qui lui correspondait.

Ce n’était pas difficile du tout puisqu’il était composé du certificat du serveur de base de données cible lors de la connexion via SSL. Dans l’authentification client basée sur des certificats, le client et le serveur se présentent leurs certificats respectifs pour valider leurs identités et établir une connexion cryptée.

Comme ceux-ci reposent ouvertement sur des certificats fournis par une autorité de certification, ils sont publiés dans les journaux d’ouverture des certificats, cela peut donc également être utilisé pour découvrir les identifiants spéciaux associés à une base de données cible si son sous-domaine Azure personnalisé est connu.

L’attaque fonctionne uniquement par rapport aux bases de données de la même zone, mais en découvrant la région de disponibilité Azure pour une base de données particulière peut être déterminée rapidement en consultant les adresses IP des serveurs qui les hébergent. Les ennemis potentiels auraient simplement dû créer un compte dans la même région.

Impact d’ExtraReplica

Les offres de serveur unique Azure PostgreSQL ont également été impactées par la toute première vulnérabilité d’escalade d’opportunité PostgreSQL, mais pas par le contournement de l’authentification entre locataires à l’aide du service de duplication. Les circonstances du serveur flexible n’étaient pas affectées si elles étaient configurées pour l’accès Private Gain à (Intégration VNet). VNet est la fonctionnalité de réseau virtuel d’Azure.

Lors de la configuration initiale de leur compte de base de données Azure PostgreSQL, les utilisateurs doivent sélectionner leur choix de connexion réseau entre un accès public via des adresses IP autorisées, qui est l’option par défaut, ou accès privé via VNet. Cela dépend de la façon dont ils s’attendent à ce que leurs applications communiquent avec la base de données et il est difficile d’indiquer le nombre d’utilisateurs qui choisissent le choix du réseau virtuel.

Selon les scientifiques de Wiz, Microsoft n’a pas révélé la variété d’utilisateurs potentiellement affectés. consommateurs, mais ont déclaré qu’ils n’étaient pas au courant des efforts déployés pour exploiter les vulnérabilités.

 » Microsoft et d’autres CSP publient généralement des documents sur leurs conceptions et architectures d’isolement actuelles « , ont déclaré les chercheurs.

 » Nous avons remarqué que le serveur flexible PostgreSQL manque de documentation sur l’isolation publique, ce qui rend difficile pour les consommateurs d’examiner le danger lorsqu’ils intègrent un tel service. Cette préoccupation n’est pas propre à Azure seul, car d’autres fournisseurs de services cloud ont tendance à partager le modèle d’isolement pour un nombre minimal de services. « 

Les fournisseurs de cloud devraient être plus transparents avec leurs architectures d’isolement et les consommateurs doivent demander à leurs fournisseurs une telle documentation avant d’utiliser de tels services, ont déclaré les chercheurs. .

Ils ont également noté que, contrairement aux défauts de sécurité des applications logicielles, les vulnérabilités et les erreurs de configuration des services cloud ne se voient pas attribuer d’ID CVE, ce qui les rend plus difficiles à suivre ou à suivre. Pour cette raison, il existe des efforts volontaires menés par la communauté pour créer une base de données pour les problèmes et les incidents de sécurité dans le cloud.

.

Toute l’actualité en temps réel, est sur L’Entrepreneur

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici