POC de vulnérabilité ProFTPD

Démonstrations de preuve de concept pour CVE-2026-42167, une vulnérabilité d'injection SQL dans le pipeline de journalisation mod_sql de ProFTPD qui permet à un attaquant non authentifié d'exécuter du SQL arbitraire — et d'injecter des utilisateurs backdoor dans la base de données d'authentification FTP ou d'obtenir une exécution de code à distance sur l'hôte de la base de données.

Tous les POC sont spécifiques à PostgreSQL, mais ceux concernant les utilisateurs backdoor fonctionnent avec les backends MySQL et sqlite avec quelques modifications de la requête injectée (ce que nous laissons comme exercice au lecteur).

• Cette vulnérabilité a été découverte par ZeroPath Research. Notre blog technique contient plus de détails.

Vulnérabilité

Contournement de is_escaped_text() dans mod_sql SQLLog (CVE-2026-42167, CWE-89)

Le module mod_sql de ProFTPD journalise chaque commande FTP via le mécanisme SQLLog / SQLNamedQuery. Lors de la résolution de variables de format comme %U (nom d'utilisateur original) ou %{basename} (composant du nom de fichier), le framework appelle is_escaped_text() pour décider si l'échappement est nécessaire — et ignore complètement l'échappement pour toute valeur qui commence et se termine par un guillemet simple et ne contient aucun guillemet simple interne (par exemple '|| (SELECT 1) ||'). La vérification est purement syntaxique et s'effectue sur l'entrée brute contrôlée par l'attaquant depuis la session FTP, elle ne peut donc pas faire la distinction entre "pré-échappé par du code de confiance" et "fabriqué par un attaquant pour ressembler à du pré-échappé".

Le modèle documenté standard entoure les variables de format par des guillemets simples pour la sécurité SQL :

SQLNamedQuery log_activity INSERT "'%U', '%r', '%m'" activity_log
SQLLog        *           log_activity
SQLLog        ERR_*       log_activity

Lorsqu'un attaquant fournit une valeur de la forme '<payload>', la substitution produit ''<payload>'' dans le SQL final — les littéraux de chaîne vides ferment les guillemets environnants et la payload s'exécute en tant que SQL brut. Avec PostgreSQL (PQexec) ou SQLite (sqlite3_exec), le support des requêtes empilées signifie que la payload peut être une instruction INSERT, UPDATE, CREATE TABLE ou COPY TO PROGRAM complète.

Quand un serveur est-il exploitable ?

Le code vulnérable se trouve dans contrib/mod_sql.c (le framework SQL partagé), pas dans un backend spécifique, donc tous les backends SQL sont concernés — mais la surface d'attaque dépend de la configuration de journalisation de l'administrateur. Un serveur est exploitable lorsque les deux conditions suivantes sont vraies :

1. L'administrateur a défini un SQLNamedQuery INSERT (ou UPDATE) dont la chaîne de format interpole l'une de ces variables contrôlables par l'attaquant entourée de guillemets simples — par exemple "'%U', '%m'". Les variables provenant de l'entrée de l'attaquant sont :

   Var	Signification
   %A	chaîne de mot de passe de connexion anonyme
   %J	paramètres de commande (tout après le verbe)
   %S	chaîne du message de réponse (peut inclure l'entrée de l'attaquant renvoyée dans les erreurs)
   %U	nom d'utilisateur original de USER (défini avant l'authentification, disponible même en cas d'échec de connexion)
   %d	nom du répertoire (dernier composant du chemin)
   %l	réponse d'identification RFC 1413 (contrôlée par l'attaquant s'il exécute identd)
   %m	méthode/verbe FTP (l'attaquant choisit la commande à envoyer)
   %r	commande FTP complète (verbe + arguments)
   %u	nom d'utilisateur authentifié
   %{basename}	composant du nom de fichier de l'argument de chemin, sans préfixe de répertoire

   %f, %F et %D semblent contrôlables par l'attaquant mais donnent toujours des chemins absolus commençant par /, donc ils ne peuvent pas satisfaire l'exigence de is_escaped_text() de commencer par '.

2. L'administrateur a lié ce SQLNamedQuery à une directive SQLLog pour une commande FTP (ou une classe de commandes) que l'attaquant peut atteindre. Les caractères génériques largement documentés SQLLog * et SQLLog ERR_* sont le cas le plus large et ce qui rend le chemin %U pré-authentification : ERR_* se déclenche sur un USER échoué, donc aucune information d'identification n'est nécessaire. Les directives par commande comme SQLLog STOR concernent tout utilisateur authentifié.

Que peut faire un attaquant ?

Le contournement transforme le chemin de journalisation en une primitive SQL arbitraire sur le backend. Les deux scénarios à plus fort impact :

• Injecter un utilisateur backdoor avec des privilèges arbitraires (contournement d'authentification). Le backend d'authentification SQL de ProFTPD lit les noms d'utilisateur, les hachages de mots de passe, uid, gid, homedir et shell à partir de la même table users que l'INSERT de journalisation peut maintenant écrire. Un INSERT INTO users empilé permet de planter un compte choisi par l'attaquant — uid=0, homedir=/, mot de passe en clair — et l'attaquant se connecte ensuite normalement avec un accès complet au système de fichiers via le démon FTP. Accessible avant authentification via le chemin %U + SQLLog ERR_*, ou après authentification via toute variable contrôlée par l'attaquant liée à une commande que l'attaquant peut émettre (par exemple %{basename} + SQLLog STOR). Fonctionne sur PostgreSQL et SQLite (les deux supportent les requêtes empilées).

• Exécution de code à distance sur l'hôte de la base de données via COPY TO PROGRAM. Le COPY (SELECT …) TO PROGRAM '<cmd>' de PostgreSQL exécute <cmd> via un shell sur le serveur de base de données. Une injection de requête empilée qui émet COPY TO PROGRAM donne une exécution de commande OS arbitraire en tant qu'utilisateur OS postgres, ce qui est suffisant pour l'exfiltration d'identifiants, le mouvement latéral et la persistance. Accessible via les mêmes chemins de déclenchement que le cas backdoor (avant authentification via %U ou après authentification via %{basename}, etc.). Spécifique à PostgreSQL, et nécessite que le rôle DB ProFTPD ait des privilèges de superutilisateur (la condition préalable pour COPY TO PROGRAM) — courant dans les déploiements mono-locataire où le rôle est le propriétaire de la base de données.

Choix des POC

Les POC de ce dépôt ciblent PostgreSQL spécifiquement — le cas le plus fort, puisque PQexec() supporte les requêtes empilées et que COPY TO PROGRAM fournit une exécution directe de commande OS. Le contournement lui-même se trouve dans le framework SQL partagé et affecte tous les backends :