Des chercheurs ont découvert des failles de sécurité dans l’infrastructure cloud d’IBM

Les scientifiques en sécurité ont récemment pénétré la base de données en tant que telle d’IBM Cloud installations de service et ont trouvé de nombreux problèmes de sécurité qui leur ont permis d’accéder au serveur interne utilisé pour créer des images de base de données pour les versions des clients.

L’attaque illustrée met en évidence certaines omissions de sécurité courantes qui peuvent entraîner des compromis de chaîne dans l’infrastructure cloud.

Développée par des chercheurs de la société de sécurité Wiz, l’attaque a intégré une vulnérabilité d’escalade des avantages dans le service IBM Cloud Databases for PostgreSQL avec des informations d’identification en clair réparties dans l’environnement et un accès trop permissif au réseau interne pour gérer les mouvements latéraux. à l’intérieur de l’infrastructure.

PostgreSQL est une cible attrayante dans les environnements cloud

L’audit de Wiz sur les bases de données IBM Cloud pour PostgreSQL faisait partie d’une étude de recherche plus vaste. hat a évalué les implémentations de PostgreSQL dans d’importantes entreprises cloud qui utilisent ce moteur de base de données dans le cadre de leurs services de base de données en tant que service.

Plus tôt cette année, les scientifiques de Wiz ont également découvert et révélé des vulnérabilités dans les implémentations de PostgreSQL de Microsoft Azure et Google Cloud Platform (GCP).

Le moteur de base de données relationnelle PostgreSQL open-source est en fait en développement depuis plus de 30 ans avec un accent sur la stabilité, la haute disponibilité et l’évolutivité. Cependant, ce logiciel complexe n’a pas été développé avec un modèle d’approbation approprié pour les environnements cloud multi-locataires où les instances de base de données doivent être séparées les unes des autres et des installations sous-jacentes.

PostgreSQL a des fonctions efficaces à travers lesquelles les administrateurs peuvent modifier le système de fichiers du serveur et même effectuer du code via des requêtes de base de données, mais ces opérations sont dangereuses et doivent être limitées dans les environnements de cloud partagé.

En attendant, d’autres opérations d’administration telles que la réplication de base de données, la création de points de contrôle, la mise en place d’extensions et de déclenchements d’occasions doit être à la disposition des consommateurs pour que le service soit pratique. C’est pourquoi les sociétés cloud (CSP) ont dû développer des solutions de contournement et apporter des modifications à la conception d’approbation de PostgreSQL pour permettre ces capacités même lorsque les consommateurs n’opèrent qu’avec des comptes limités.

Escalade des opportunités via l’injection SQL

Lors de l’évaluation de l’exécution PostgreSQL d’IBM Cloud, les chercheurs de Wiz ont examiné le mécanisme de réplication logique qui est facilement disponible pour les utilisateurs. Cette fonctionnalité a été implémentée en utilisant un certain nombre de fonctions de base de données, dont une appelée create_subscription qui est détenue et exécutée par un superutilisateur de base de données appelé ibm.

Lorsqu’ils ont vérifié le code de cette fonction, les chercheurs ont remarqué une injection SQL vulnérabilité déclenchée par un nettoyage inapproprié des arguments qui lui sont transmis. Cela indiquait qu’ils pourraient transmettre des requêtes SQL approximatives à la fonction, qui effectuerait ensuite ces requêtes en tant que superutilisateur ibm.

Les chercheurs ont exploité cette faille au moyen de la déclaration PostgreSQL COPY pour exécuter des commandes approximatives sur le système virtuel sous-jacent. machine qui hébergeait l’instance de base de données et ouvrait un shell inversé.

Avec un shell sur le système Linux, ils ont commencé à faire des reconnaissances pour comprendre leur environnement, comme noter les procédures en cours d’exécution, vérifier les connexions réseau actives, examiner le contenu des fichiers / etc / passwd qui note les utilisateurs du système et exécute un scan de port sur le réseau interne pour découvrir d’autres serveurs. L’analyse étendue des ports a attiré l’attention du groupe de sécurité IBM qui a contacté l’équipe Wiz pour s’enquérir de leurs activités.

« Après avoir discuté de notre travail et partagé nos réflexions avec eux, ils nous ont gentiment offert l’autorisation de poursuivre notre étude de recherche et d’autres limites de sécurité des obstacles, reflétant la culture de sécurité saine de l’organisation », a déclaré le groupe Wiz.

Les informations d’identification stockées conduisent à une attaque de la chaîne d’approvisionnement

Les informations collectées, telles que les variables d’environnement, ont indiqué aux chercheurs qu’ils étaient restés dans un conteneur de pod Kubernetes (K8s) et après avoir recherché le système de fichiers, ils ont découvert qu’une API K8s avait accès au jeton enregistré localement dans un fichier appelé/ var/run/secrets / kubernetes.io/ serviceaccount/token.

Le jeton API leur a permis de recueillir plus d’informations sur le cluster K8s, mais il s’est avéré que tous les pods étaient associés à leur compte et fonctionnaient sous le même espace de noms . Ce n’était pas une impasse.

K8s est un système d’orchestration de conteneurs utilisé pour la mise en œuvre d’applications logicielles où les conteneurs sont généralement libérés à partir d’images – des ensembles prédéfinis qui contiennent tous les fichiers requis pour un conteneur et ses services préconfigurés courir. Ces images sont généralement conservées sur un serveur de registre de conteneurs, qui peut être public ou personnel. Dans le cas d’IBM Cloud, c’était un registre de système informatique de conteneur personnel qui nécessitait une authentification.

Les chercheurs ont utilisé le jeton d’API pour lire les configurations des pods dans leur espace de noms et ont trouvé la clé d’accès pour quatre différents registres de conteneurs pc dans ces fichiers de configuration.

La description de cette clé nouvellement trouvée dans l’API de gestion des identités et des accès (IAM) d’IBM Cloud suggérait qu’elle avait à la fois des opportunités de lecture et de composition pour les registres du système informatique du conteneur, ce qui ont fourni aux scientifiques la possibilité d’écraser des images existantes avec des images non autorisées.

Il s’est avéré que la description essentielle n’était pas fiable et qu’ils ne pouvaient que télécharger des images. Ce niveau d’accès avait des ramifications en matière de sécurité, mais il ne constituait pas une menace directe pour les autres consommateurs d’IBM Cloud, alors les scientifiques ont avancé.

Les images de conteneurs peuvent contenir une grande quantité d’informations délicates qui sont utilisées tout au long de la mise en œuvre et est ensuite supprimé, composé de code source, de scripts internes faisant référence à des services supplémentaires dans les installations, ainsi que des informations d’identification requises pour y accéder. Par conséquent, les scientifiques ont choisi de télécharger toutes les images à partir du service de registre des ordinateurs et d’utiliser un outil automatisé pour les analyser à la recherche d’astuces, telles que des qualifications et des jetons d’API.

« Afin d’analyser en profondeur les secrets, nous avons déchargé les images et analysé la combinaison de fichiers qui composait chaque image », ont déclaré les scientifiques.

« Les images de conteneurs sont basées sur une ou plusieurs couches ; chacune peut accidentellement inclure des astuces. Si un secret existe dans une couche cependant est effacé de la couche suivante, il serait complètement imperceptible depuis l’intérieur du conteneur. Analyser chaque couche séparément pourrait donc exposer des astuces supplémentaires. »

Les fichiers manifestes JSON des images de conteneur ont une zone « historique » qui répertorie les commandes historiques exécutées tout au long de la procédure de développement de chaque image. Dans un certain nombre de ces fichiers, les chercheurs ont découvert des commandes auxquelles étaient transmis des mots de passe en tant qu’arguments de ligne de commande. Ceux-ci comprenaient des mots de passe pour un serveur FTP interne IBM Cloud et un référentiel d’artefacts de construction.

Les scientifiques ont évalué s’ils pouvaient accéder à ces serveurs depuis leur conteneur et il s’est avéré qu’ils le pouvaient.

Cet accès au réseau excessivement permissif, combiné aux qualifications prolongées, leur a permis d’écraser des fichiers approximatifs dans le référentiel d’artefacts de génération utilisé par la procédure de construction automatisée d’IBM Cloud pour créer des images de conteneur. Ces images sont ensuite utilisées dans les versions des clients, déverrouillant une attaque de la chaîne d’approvisionnement.

« Nos recherches sur les bases de données IBM Cloud pour PostgreSQL ont amélioré ce que nous avons appris d’autres fournisseurs de cloud, à savoir que les ajustements au moteur PostgreSQL présentaient efficacement la marque – de nouvelles vulnérabilités au service », ont déclaré les scientifiques. « Ces vulnérabilités pourraient avoir été utilisées par une star malveillante dans le cadre d’une vaste chaîne d’utilisation aboutissant à une attaque de la chaîne d’approvisionnement sur la plate-forme. »

Leçons pour d’autres organisations

Bien que tous ces problèmes aient actuellement été signalés et résolus de manière indépendante par l’équipe IBM Cloud, ils ne sont pas spécifiques à IBM. Selon l’équipe Wiz, le problème des « astuces dispersées » est courant dans tous les environnements cloud.

Les workflows de construction et de mise en œuvre automatisés laissent souvent des secrets derrière eux dans de nombreux endroits tels que les fichiers de configuration, l’historique de bash Linux, les fichiers journaux et ainsi de suite que les développeurs oublient de nettoyer lorsque la version est terminée.

Certains développeurs téléchargent par erreur leurs fichiers de configuration whole.git et CircleCI sur des serveurs de production. Les secrets oubliés couramment trouvés par l’équipe Wiz incluent les clés d’accès au cloud, les mots de passe, les qualifications CI/CD et les jetons d’accès à l’API.

Un autre problème répandu qui a joué un rôle important dans l’attaque IBM Cloud est l’absence d’accès rigoureux contrôles entre les serveurs de production et les systèmes CI/CD internes. Cela permet souvent aux ennemis de se déplacer latéralement et d’avoir une emprise plus profonde sur l’infrastructure d’une organisation.

Les registres de conteneurs personnels peuvent offrir une mine d’informations aux agresseurs qui vont au-delà des qualifications. Ils peuvent exposer des informations sur les serveurs critiques à l’intérieur de l’infrastructure ou peuvent consister en un code qui expose des vulnérabilités supplémentaires.

Les organisations doivent s’assurer que leurs options de registre de fenêtres de conteneur appliquent un accès correct aux contrôles et à la portée, a déclaré le groupe Wiz.