Les chercheurs Rapid7 croient que les attaques d’assistance à distance Beyondtrust de décembre ont également exploité une faille zéro-jour dans Postgresql.
Les attaquants qui ont exploité une vulnérabilité zéro-jour dans les produits d’accès à distance privilégié et de support à distance privilégiés en décembre ont également exploité un défaut d’injection SQL auparavant inconnu dans PostgreSQL, un système de base de données d’objet open-source largement utilisé. Le problème PostgreSQL a été résolu jeudi et les utilisateurs sont invités à mettre à niveau leurs serveurs de base de données dès que possible.
Fin décembre, le département américain du Trésor a révélé que les attaquants chinois parrainés par l’État avaient accédé à certaines de ses postes de travail et ont obtenu des informations non classifiées. Le Trésor a déclaré que l’accès s’est produit via un service d’assistance à distance basé sur le cloud exploité par Beyondtrust.
Beyondtrust a lancé une enquête et a confirmé qu’une clé API avait été compromise et a été utilisée pour accéder aux comptes clients. Mais la société a également identifié deux problèmes d’injection de commandement zéro-jour dans ses produits – CVE-2024-12356 et CVE-2024-12686 – que l’Agence américaine de sécurité de la cybersécurité et de l’infrastructure (CISA) a ajouté plus tard à ses vulnérabilités exploitées (KVE) connues (KVE) Catalogue .
Des chercheurs de la société de sécurité Rapid7 ont analysé les correctifs de la vulnérabilité CVE-2024-12356 afin de comprendre le défaut et, dans le processus Commandes système. Le défaut d’injection PostgreSQL SQL est maintenant suivi comme CVE-2025-1094.
«Dans chaque scénario Rapid7, les chercheurs ont été testés lors de l’analyse du CVE-2024-12356, un exploit réussi pour le CVE-2024-12356 a dû inclure l’exploitation du CVE-2025-1094 afin d’atteindre l’exécution du code à distance», ont écrit les chercheurs dans leur rapport dans leur rapport . «En d’autres termes, sur la base de notre analyse, nous pensons que l’exploit de Beyondtrust RS CVE-2024-12356 se serait appuyé sur l’exploitation de PostgreSQL CVE-2025-1094.»
Le PostgreSQL Global Development Group, qui maintient le logiciel PostgreSQL, a conseillé aux utilisateurs de passer à la version corrigée pour leur branche respective: 17.3, 16.7, 15.11, 14.16 et 13.19.
Saisie des entrées contournée
Lorsque les chercheurs Rapid7 ont examiné les correctifs, ils ont remarqué qu’une certaine désinfection était ajoutée à une valeur appelée $ gskey qui était transmise à un script appelé $ ingrediroot / app / dbquote via la commande echo.
« Le changement dans la façon dont la valeur $ gskey est transmise à la commande Echo est un problème classique d’injection d’argument », ont écrit les chercheurs. «Dans un script de shell, lorsqu’il passait une variable non adoptée à une commande, le shell transmettra le contenu de la valeur à la commande comme arguments individuels à la commande, comme analysé le shell. Si la valeur est enveloppée en doubles guillemets, le shell passera la valeur entière en un seul argument à la commande. »
Mais l’avis de Beyondtrust a déclaré que l’exploitation de cette vulnérabilité «peut permettre à un attaquant distant non authentifié d’exécuter des commandes de système d’exploitation sous-jacentes dans le contexte de l’utilisateur du site». Et l’injection d’argument à elle seule ne le réalise pas, les chercheurs ont donc dû continuer à creuser.
Ils ont ensuite regardé DBQuote et ont vu que c’était un script PHP qui a pris la valeur Echoed $ gskey, l’a passé par la fonction PostgreSQL PHP PG_escape_string, puis a enveloppé la sortie en devis uniques et l’a imprimé comme une variable appelée citée.
Le but de la fonction PG_escape_string est de «s’échapper» de tout caractères spéciaux, tels que des citations uniques, à partir de l’entrée non fiable avant de l’utiliser dans une commande SQL. En effet
Les chercheurs étaient un peu confus à ce stade. L’utilisation de PG_escape_string aurait dû atténuer tout risque d’injection SQL. Alors pourquoi $ gskey était-il désinfecté en premier lieu?
Cette question leur a fait tomber un trou de lapin beaucoup plus profond qui s’est terminé par la constatation que le terminal interactif interactif de PostgreSQL semble gérer incorrectement l’entrée qui contient des caractères UTF-8 non valides. Lorsqu’il est présenté avec une chaîne qui a une certaine combinaison d’octets UTF-8 non valides, il fait que l’instruction SQL se termine tôt et ouvre la possibilité d’exécuter une instruction supplémentaire de la chaîne qui suit le caractère UTF-8 non valide et un point-virgule.
« Nous avons réussi à réaliser une injection SQL via une entrée non fiable correctement échappée, en raison de la gestion incorrecte de l’outil PSQL des caractères UTF-8 non valides », ont écrit les chercheurs. «Cette vulnérabilité est maintenant connue sous le nom de CVE-2025-1094.»
De plus, PSQL a une fonctionnalité appelée Meta-Commands qui permet l’exécution des commandes shell via le ! méta-command. Cette capacité transforme l’injection SQL en exécution de code de commande OS.
Les chercheurs ont même trouvé un moyen d’exploiter directement CVE-2025-1094 dans le produit Beyondtrust sans avoir à compter sur la vulnérabilité d’injection d’argument CVE-2024-12356. Cependant, les chèques supplémentaires mis en place pour $ gskey dans le cadre du patch pour CVE-2024-12356, atténuant également ce chemin d’attaque plus direct.
Plus précisément, le correctif vérifie désormais la valeur $ gskey en utilisant un modèle d’expression régulière de A-ZA-Z0-9 – lettres minuscules de A à Z, lettres majuscules de A à Z et chiffres de 0 à 9. En attendant, un exploit réussi Nécessite l’ajout d’un octet brut comme 0xc0 dans la valeur afin de déclencher une manipulation incorrecte de caractères non valides par PSQL, et cela échoue à la vérification nouvellement ajoutée.
