Une vulnérabilité dans PostgreSQL a été corrigée, utilisée lors de l'attaque contre BeyondTrust

Des mises à jour correctives ont été émises pour toutes les versions prises en charge de PostgreSQL 17.3, 16.7, 15.11, 14.16 et 13.19, corrigeant plus de 70 bogues et éliminant une vulnérabilité (CVE-2025-1094) qui, fin décembre, a été exploitée dans une attaque contre la société BeyondTrust et le ministère des Finances des États-Unis. Le problème dans PostgreSQL a été identifié lors de l'analyse d'une vulnérabilité à distance (CVE-2024-12356) dans les services BeyondTrust PRA (Privileged Remote Access) et BeyondTrust RS (Remote Support), dont l'exploitation a également impliqué une vulnérabilité auparavant inconnue (0-day) dans libpq.

À la suite de l'attaque, les cybercriminels ont réussi à obtenir une clé d'accès à l'API utilisée pour fournir un support technique à distance aux clients des services SaaS de BeyondTrust. Cette API a été utilisée pour réinitialiser le mot de passe et compromettre l'infrastructure du ministère des Finances des États-Unis, qui utilise des produits BeyondTrust. Au cours de l'attaque, les cybercriminels ont pu télécharger des documents confidentiels et accéder aux stations de travail des employés du ministère.

La vulnérabilité se manifeste dans la bibliothèque libpq, qui fournit une API pour interagir avec les bases de données depuis des programmes en langage C (des bibliothèques de liaison pour C++, Perl, PHP et Python sont également implémentées sur cette bibliothèque). Le problème concerne les applications qui utilisent les fonctions PQescapeLiteral(), PQescapeIdentifier(), PQescapeString() ou PQescapeStringConn() pour échapper les caractères spéciaux et neutraliser les guillemets.

Un attaquant peut parvenir à injecter son propre code SQL si le texte reçu de l'extérieur est échappé à l'aide des fonctions libpq mentionnées ci-dessus avant d'être utilisé dans une requête SQL. Dans les applications de BeyondTrust, les requêtes ainsi échappées étaient transmises via l'utilitaire de ligne de commande psql. La vulnérabilité est causée par l'absence de vérification de la validité des caractères Unicode utilisés dans le texte dans les fonctions d'échappement, ce qui permet de contourner la normalisation des guillemets en spécifiant des séquences multi-octets UTF-8 incorrectes.

Pour exploiter la vulnérabilité, il est possible d'utiliser un caractère UTF-8 incorrect, composé des octets 0xC0 et 0x27 («└'»). L'octet 0x27 en codage ASCII correspond à une apostrophe («‘»), qui doit être échappée. Dans le code d'échappement, la combinaison d'octets 0xC0 et 0x27 est traitée comme un seul caractère Unicode. Par conséquent, l'octet 0x27 dans cette séquence reste non échappé, tandis que lors du traitement de la requête SQL dans l'outil psql, il est traité comme une apostrophe.

En cas lancement de requêtes SQL à l'aide de l'outil psql pour organiser l'exécution de code arbitraire, il est possible d'utiliser la substitution dans la chaîne de commande «\!», destinée dans psql à exécuter des programmes arbitraires. Par exemple, pour lancer sur le serveur l'outil «id», la valeur «hax\xC0′; \! id #» peut être transmise. Dans l'exemple ci-dessous, pour l'échappement, un script PHP dbquote est appelé, utilisant la fonction PHP pg_escape_string, qui fonctionne sur la fonction PQescapeString de libpq : $ echo -e «hello \xC0’world'» | .\/dbquote ‘hello └’world»’ $ quoted=$(echo -e «hax\xC0′; \! id # » | .\/dbquote) $ echo «SELECT COUNT(1) FROM gw_sessions WHERE session_key = $quoted AND session_type = ‘sdcust’ AND (expiration IS NULL OR expiration>NOW())» | psql -e SELECT COUNT(1) FROM gw_sessions WHERE session_key = ‘hax└’; ERROR: invalid byte sequence for encoding «UTF8»: 0xc0 0x27 uid=1000(myexamplecompany) gid=1000(myexamplecompany)

Source : opennet.ru