Un chercheur en sécurité a déclaré avoir saisi les informations d’identification d’un service AWS interne en exploitant une vulnérabilité de lecture de fichier local sur une instance EC2 du service de base de données relationnelle (RDS).

Le mérite de la découverte revient à Gafnit Amiga, directeur de la recherche sur la sécurité de la société israélienne de sécurité cloud Lightspin, qui a déclaré La gorgée quotidienne que la recherche était remarquable « parce que la charge utile finale est toutes les commandes SQL ».

L’impact a été obscurci par le fait qu’AWS a refusé de divulguer le but ou la mise en œuvre du service interne vulnérable, mais il a dit à Amiga que tout abus n’aurait pas mis en péril les données des clients.

Tout en reconnaissant l’attrait des services AWS, la découverte a montré que « le fait d’encapsuler des services tiers tels que PostgreSQL et d’essayer de fournir aux utilisateurs des fonctionnalités avancées est parfois une arme à double tranchant », a déclaré Amiga.

AWS a abordé la vulnérabilité de manière exhaustive et a déclaré n’avoir trouvé aucune preuve d’exploitation hostile, selon le chercheur.

Chemin vers la percée

Amiga a commencé la recherche en créant une instance RDS à l’aide du moteur Amazon Aurora PostgreSQL et en se connectant à la base de données à l’aide de psql, selon un article de blog documenter le processus.

Elle a décidé d’accéder à la machine sous-jacente exécutant PostgreSQL, « j’ai donc cherché quelque chose qui me permettrait d’exécuter des commandes du système d’exploitation, d’envoyer des requêtes réseau ou de lire des fichiers locaux », a expliqué le chercheur.

VOUS POURRIEZ AUSSI AIMER TruffleHog v3 : l’outil de détection de fuite de clé API ajoute la prise en charge de plus de 600 types

« Après avoir essayé toutes les techniques simples connues, j’ai décidé de passer en revue les extensions. »

RDS prend en charge de nombreuses extensions pour PostgreSQL, « mais j’ai senti que les chances qu’ils manquent quelque chose là-bas sont plus élevées car il n’est pas si simple de faire une intégration sécurisée à un code tiers », a-t-elle poursuivi.

Le chercheur a examiné la fonctionnalité de 8 à 10 extensions de ce type et les objets qu’elles ont créés dans Postgres avant de tomber sur celui qui a donné une percée potentielle : log_fdw.

Contournement de la validation

En utilisant le log_fdw extension, Amiga a tenté une traversée de chemin lors de la création d’une table étrangère, mais cela a provoqué une exception indiquant « le chemin du fichier journal spécifié n’était pas valide ».

Après avoir testé un autre chemin relatif, elle a identifié la source de l’erreur en tant que fonction de validation.

AWS a créé un wrapper de données étrangères personnalisé – qui peut obtenir des données à partir de fichiers externes – pour log_fdw avec des fonctions de gestionnaire et de validateur.

Une percée potentielle s’est produite lorsqu’il est apparu que la fonction de validation est facultative pour les données étrangères.

Amiga avait potentiellement la permission de mettre à jour la fonction de validation en utilisant le rds_superuser rôle. « J’espérais juste qu’ils ne valident le chemin que dans la fonction de validation », a-t-elle déclaré.

Cet espoir s’est réalisé lorsque le chercheur a abandonné la fonction de validation et que la traversée du chemin a réussi.

Elle a ensuite trouvé des identifiants temporaires de gestion des identités et des accès (IAM) sur csd-grover-credentials.jsoncomprenant un Clé publique et Clé privéequi s’est avéré être lié à un rôle interne du nom de csd-grover-rôle.

Amiga a alors pu découvrir et accéder à un service interne correspondant, « Grover ».

La vulnérabilité a été signalée à AWS le 9 décembre. AWS a appliqué un correctif initial pour les versions récentes des moteurs RDS et Aurora PostgreSQL le 14 décembre, puis a confirmé le 22 mars que toutes les versions actuellement prises en charge étaient corrigées et que les clients potentiellement concernés avaient reçu des instructions d’atténuation. .