
PoC de "DEF CON 32 - L'injection SQL n'est pas morte : le passage clandestin de requêtes au niveau du protocole - Paul Gerste"
Une application web simple avec fonctionnalité de connexion. Seuls les administrateurs peuvent se connecter.
Cette application utilise PostgreSQL et pgx v5.5.3 (version vulnérable).
L'attaquant tente de se connecter en insérant malicieusement des enregistrements dans la table users. Cependant, comme des paramètres fictifs (placeholders) sont utilisés, l'injection SQL traditionnelle ne fonctionne pas.
Formats des messages PostgreSQL : https://www.postgresql.org/docs/17/protocol-message-formats.html
L'exploit dépend du format de message que pgx envoie au serveur de base de données lors de l'exécution de SQL.
Par défaut, pgx envoie une instruction préparée avec P(Parse) puis envoie les paramètres avec B(Bind).
Si la configuration suivante est définie, pgx envoie la requête interpolée avec :
Q(Query)cfg.ConnConfig.DefaultQueryExecMode = pgx.QueryExecModeSimpleProtocol
Vous pouvez visualiser les messages réels en utilisant tcpdump avec l'option -X.
Q_simple.py : Provoque un débordement avec Q(Query). Suppose que l'attaquant a une connaissance complète de la requête exécutée (en boîte noire, une attaque par force brute est requise).Q_nop_sled.py : Provoque un débordement avec Q(Query). Réussit l'exploitation en moins de 5 tentatives.B_simple.py : Provoque un débordement avec B(Bind). Suppose que l'attaquant a une connaissance complète de la requête exécutée (à mon avis, l'exploitation de B(Bind) est difficile dans des scénarios en boîte noire).