Des chercheurs en sécurité ont récemment examiné l'infrastructure de base de données en tant que service d'IBM Cloud et ont découvert plusieurs problèmes de sécurité qui leur ont permis d'accéder à des serveurs internes utilisés pour créer des images de base de données pour les déploiements des clients. L'attaque démontrée met en évidence certains oublis de sécurité courants qui peuvent conduire à la compromission de la chaîne d'approvisionnement dans l'infrastructure en nuage.
L'attaque, développée par les chercheurs de la société de sécurité Wiz, combine une vulnérabilité d'escalade des privilèges dans le service IBM Cloud Databases for PostgreSQL, des identifiants en clair dispersés dans l'environnement, et des contrôles d'accès au réseau interne trop laxistes qui permettent des mouvements latéraux au sein de l'infrastructure. 4gdtu
PostgreSQL est une cible attrayante dans les environnements en nuage
L'audit d'IBM Cloud Databases for PostgreSQL réalisé par Wiz fait partie d'un projet de recherche plus large qui analyse les déploiements de PostgreSQL par les principaux fournisseurs de cloud qui proposent le moteur de base de données dans le cadre de leurs solutions de base de données gérées en tant que service. Plus tôt cette année, les chercheurs de Wiz ont également découvert et divulgué des vulnérabilités dans l'implémentation de PostgreSQL sur Microsoft Azure et Google Cloud Platform (GCP).
[Faites progresser votre carrière grâce aux meilleures certifications en matière de sécurité : Ce qu'elles font, combien elles coûtent et ce dont vous avez besoin. | S'inscrire à la lettre d'information du CSO. ]
Le moteur de base de données relationnelle open source PostgreSQL a été développé pendant plus de 30 ans en mettant l'accent sur la stabilité, la haute disponibilité et l'évolutivité. Cependant, ce logiciel complexe n'a pas été conçu avec un modèle de permissions adapté aux environnements cloud multi-tenant, où les instances de base de données doivent être isolées les unes des autres et de l'infrastructure sous-jacente.
1 seconde sur 28 secondesVolume 0%
PostgreSQL possède de puissantes fonctionnalités qui permettent aux administrateurs d'apporter des modifications au système de fichiers du serveur et même d'exécuter du code via des requêtes de base de données, mais ces opérations ne sont pas sécurisées et doivent être restreintes dans un environnement de cloud partagé. Parallèlement, d'autres opérations de gestion telles que la réplication de la base de données, la création de points de contrôle, l'installation d'extensions et de déclencheurs d'événements doivent être mises à la disposition des clients pour que le service fonctionne correctement. C'est pourquoi les fournisseurs de services en nuage (CSP) doivent trouver des solutions de contournement et apporter des modifications au modèle de permissions de PostgreSQL pour permettre ces fonctionnalités, même si les clients n'opèrent qu'avec des comptes limités.
Augmentation des privilèges par injection SQL
En analysant l'implémentation PostgreSQL d'IBM Cloud, les chercheurs de Wiz ont examiné les mécanismes de réplication logique mis à la disposition des utilisateurs. Cette fonctionnalité est mise en œuvre à l'aide de plusieurs fonctions de base de données, y compris une fonction appelée create_subscription, qui est détenue et exécutée par le superutilisateur de la base de données nommé ibm.
Lorsqu'ils ont inspecté le code de cette fonction, les chercheurs ont remarqué une vulnérabilité d'injection SQL causée par une mauvaise analyse des paramètres qui lui sont transmis. Cela signifie qu'ils peuvent passer des requêtes SQL arbitraires à la fonction et que celle-ci les exécutera en tant que superutilisateur ibm. Les chercheurs ont exploité cette vulnérabilité via une instruction COPY de PostgreSQL pour exécuter des commandes arbitraires sur la machine virtuelle sous-jacente hébergeant l'instance de la base de données et ouvrant un shell inversé.
À l'aide d'un shell sur un système Linux, ils commencent à effectuer une reconnaissance pour comprendre leur environnement, par exemple en listant les processus en cours, en vérifiant les connexions réseau actives, en vérifiant le contenu du fichier /etc/passwd qui répertorie les utilisateurs du système, et en effectuant un balayage des ports sur Linux. Le réseau interne découvre d'autres serveurs. Le balayage généralisé des ports a attiré l'attention de l'équipe de sécurité d'IBM, qui a contacté l'équipe Wiz pour s'enquérir de ses activités.
"Après avoir discuté de notre travail et partagé nos idées avec eux, ils nous ont gentiment permis de poursuivre nos recherches et de repousser les limites de la sécurité, ce qui reflète la culture de sécurité saine de l'organisation", a déclaré l'équipe Wiz.
Les informations d'identification stockées sont à l'origine d'attaques contre la chaîne d'approvisionnement
Les informations recueillies, telles que les variables d'environnement, ont indiqué aux chercheurs qu'ils se trouvaient à l'intérieur d'un conteneur de pods Kubernetes (K8s) et, après avoir fouillé le système de fichiers, ils ont découvert que le jeton d'accès à l'API K8s était stocké localement dans un fichier nommé /var/run/secrets/kubernetes middle. io/serviceaccount/token. Le jeton API leur permet de recueillir plus d'informations sur le cluster K8s, mais il s'avère que tous les pods sont associés à leur compte et s'exécutent sous le même espace de noms. Mais ce n'est pas une impasse.
K8s est un système d'orchestration de conteneurs pour le déploiement de logiciels, où les conteneurs sont généralement déployés à partir d'images - des paquets préconstruits qui contiennent tous les fichiers nécessaires à l'exécution du conteneur et de ses services préconfigurés. Ces images sont généralement stockées sur un serveur de registre de conteneurs, qui peut être public ou privé. Dans le cas d'IBM Cloud, c'est un registre de conteneurs privé qui nécessite une authentification.
Les chercheurs ont utilisé des jetons d'API pour lire la configuration des pods dans leur espace de noms et ont trouvé des clés d'accès à quatre registres de conteneurs internes différents dans ces fichiers de configuration. La description de la clé récemment découverte dans l'API Identity and Access Management (IAM) d'IBM Cloud indique qu'elle a un accès en lecture et en écriture au registre des conteneurs, ce qui permettrait aux chercheurs d'écraser les images existantes avec des images malveillantes.
Mais plus tard, j'ai découvert que la description de la clé était inexacte et que je ne pouvais télécharger que des images. Ce niveau d'accès avait des implications en termes de sécurité, mais ne représentait pas une menace directe pour les autres clients d'IBM Cloud, et les chercheurs ont donc poursuivi leur travail.
Les images de conteneurs peuvent contenir de nombreuses informations sensibles qui sont utilisées lors du déploiement et supprimées par la suite, notamment le code source, les scripts internes qui font référence à d'autres services de l'infrastructure et les informations d'identification requises pour y accéder. Les chercheurs ont donc décidé de télécharger toutes les images à partir du service de registre et d'utiliser des outils automatisés pour les analyser à la recherche de secrets tels que des informations d'identification et des jetons d'API.
"Pour analyser les secrets de manière exhaustive, nous avons décompressé les images et examiné la combinaison des fichiers qui composent chaque image", expliquent les chercheurs. "Les images des conteneurs sont basées sur une ou plusieurs couches ; chacune d'entre elles peut contenir des secrets de manière non intentionnelle. Par exemple, si un secret existe dans une couche mais qu'il est retiré de la couche suivante, il sera complètement invisible à l'intérieur du conteneur. Par conséquent, l'analyse individuelle de chaque couche peut révéler davantage de secrets."
Le fichier manifeste JSON d'une image de conteneur comporte une section "historique" qui répertorie les commandes historiques exécutées au cours du processus de construction de chaque image.
Leçons tirées d'autres organisations
Bien que tous ces problèmes aient été signalés en privé à l'équipe IBM Cloud et corrigés par elle, ils ne sont pas propres à IBM. Selon l'équipe Wiz, le problème des "secrets dispersés" est commun à tous les environnements cloud.
Les processus automatisés de construction et de déploiement laissent souvent des secrets à divers endroits, tels que les fichiers de configuration, l'historique de Linux bash, les fichiers journaux, etc. que les développeurs oublient d'effacer une fois le déploiement terminé. De plus, certains développeurs téléchargent accidentellement l'intégralité de leurs fichiers de configuration .git et CircleCI sur le serveur de production. Les secrets oubliés que l'équipe Wiz découvre souvent incluent les clés d'accès au cloud, les mots de passe, les identifiants CI/CD et les jetons d'accès à l'API.
Un autre problème courant qui joue un rôle clé dans les attaques contre IBM Cloud est l'absence de contrôles d'accès stricts entre les serveurs de production et les systèmes CI/CD internes. Cela permet souvent aux attaquants de se déplacer latéralement et de s'implanter plus profondément dans l'infrastructure d'une organisation.
Enfin, les registres de conteneurs privés peuvent fournir aux attaquants de nombreuses informations au-delà des informations d'identification. Ils peuvent révéler des informations sur des serveurs critiques au sein de l'infrastructure, ou contenir du code qui révèle d'autres vulnérabilités. L'équipe de Wiz indique que les organisations devraient s'assurer que leurs solutions de registres de conteneurs mettent en œuvre des contrôles d'accès et un cadrage appropriés.