POC delle vulnerabilità di ProFTPD

Dimostrazioni proof-of-concept per CVE-2026-42167, una vulnerabilità di SQL injection nella pipeline di logging di mod_sql di ProFTPD che consente a un attaccante non autenticato di eseguire SQL arbitrario — e di iniettare utenti backdoor nel database di autenticazione FTP o ottenere l'esecuzione remota di codice sull'host del database.

Tutti i POC sono specifici per PostgreSQL, ma quelli per l'utente backdoor funzionano anche con backend MySQL e sqlite con alcune modifiche alla query iniettata (che lasciamo come esercizio al lettore).

• Questa vulnerabilità è stata scoperta da ZeroPath Research. Il nostro blog tecnico contiene maggiori dettagli.

Vulnerabilità

Bypass di is_escaped_text() in mod_sql SQLLog (CVE-2026-42167, CWE-89)

Il mod_sql di ProFTPD registra ogni comando FTP tramite il meccanismo SQLLog / SQLNamedQuery. Quando risolve variabili di formato come %U (nome utente originale) o %{basename} (componente nome-file), il framework chiama is_escaped_text() per decidere se l'escaping è necessario — e salta del tutto l'escaping per qualsiasi valore che inizia e finisce con un apice singolo e non contiene apici singoli interni (es. '|| (SELECT 1) ||'). Il controllo è puramente sintattico e opera su input grezzo controllato dall'attaccante proveniente dalla sessione FTP, quindi non può distinguere "pre-escaped da codice fidato" da "creato da un attaccante per sembrare pre-escaped".

Il pattern standard documentato racchiude le variabili di formato tra apici singoli per la sicurezza SQL:

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

Quando un attaccante fornisce un valore della forma '<payload>', la sostituzione produce ''<payload>'' nel SQL finale — i literal di stringa vuota chiudono gli apici circostanti e il payload viene eseguito come SQL grezzo. Con PostgreSQL (PQexec) o SQLite (sqlite3_exec), il supporto alle query impilate fa sì che il payload possa essere un'istruzione INSERT, UPDATE, CREATE TABLE o COPY TO PROGRAM completa.

Quando un server è sfruttabile?

Il codice vulnerabile si trova in contrib/mod_sql.c (il framework SQL condiviso), non in un backend specifico, quindi tutti i backend SQL sono interessati — ma la superficie d'attacco dipende da come l'amministratore ha configurato il logging. Un server è sfruttabile quando entrambe le seguenti condizioni sono vere:

1. L'amministratore ha definito una SQLNamedQuery INSERT (o UPDATE) la cui stringa di formato interpola una di queste variabili controllabili dall'attaccante racchiusa tra apici singoli — es. "'%U', '%m'". Le variabili che provengono dall'input dell'attaccante sono:

   Var	Significato
   %A	stringa password del login anonimo
   %J	parametri del comando (tutto ciò che segue il verbo)
   %S	stringa del messaggio di risposta (può includere input dell'attaccante riflesso negli errori)
   %U	nome utente originale da USER (impostato prima dell'autenticazione, disponibile anche su login fallito)
   %d	nome della directory (ultimo componente del percorso)
   %l	risposta ident RFC 1413 (controllabile dall'attaccante se esegue identd)
   %m	metodo/verbo FTP (l'attaccante sceglie quale comando inviare)
   %r	comando FTP completo (verbo + argomenti)
   %u	nome utente autenticato
   %{basename}	componente nome-file dell'argomento del percorso, senza prefisso directory

   %f, %F e %D sembrano controllabili dall'attaccante ma risolvono sempre in percorsi assoluti che iniziano con /, quindi non possono soddisfare il requisito di is_escaped_text() di iniziare con '.

2. L'amministratore ha associato quella SQLNamedQuery a una direttiva SQLLog per un comando FTP (o classe di comandi) raggiungibile dall'attaccante. I wildcard ampiamente documentati SQLLog * e SQLLog ERR_* sono il caso più ampio e ciò che rende il percorso %U pre-autenticazione: ERR_* scatta su un USER fallito, quindi non servono credenziali. Le direttive per singolo comando come SQLLog STOR coprono qualsiasi utente autenticato.

Cosa può fare un attaccante?

Il bypass trasforma il percorso di logging in una primitiva SQL arbitraria sul backend. I due scenari di maggiore impatto:

• Iniettare un utente backdoor con privilegi arbitrari (auth bypass). Il backend di autenticazione SQL di ProFTPD legge nomi utente, hash delle password, uid, gid, homedir e shell dalla stessa tabella users su cui la INSERT di logging ora può scrivere. Una INSERT INTO users impilata inserisce un account scelto dall'attaccante — uid=0, homedir=/, password in chiaro — e l'attaccante accede poi normalmente con pieno accesso al filesystem tramite il demone FTP. Raggiungibile pre-autenticazione tramite il percorso %U + SQLLog ERR_*, oppure post-autenticazione tramite qualsiasi variabile controllata dall'attaccante associata a un comando che l'attaccante può inviare (es. %{basename} + SQLLog STOR). Funziona su PostgreSQL e SQLite (entrambi supportano query impilate).

• Esecuzione di codice remota sull'host del database tramite COPY TO PROGRAM. COPY (SELECT …) TO PROGRAM '<cmd>' di PostgreSQL esegue <cmd> tramite una shell sul server del database. Un'iniezione con query impilata che emette COPY TO PROGRAM consente l'esecuzione arbitraria di comandi del sistema operativo come utente di sistema postgres, il che è sufficiente per l'esfiltrazione di credenziali, il movimento laterale e la persistenza. Raggiungibile attraverso gli stessi percorsi di trigger del caso backdoor (pre-auth via %U o post-auth via %{basename} ecc.). Specifico di PostgreSQL e richiede che il ruolo DB di ProFTPD abbia privilegi di superuser (il prerequisito per COPY TO PROGRAM) — comune nelle distribuzioni single-tenant in cui il ruolo è il proprietario del database.

Scelte dei POC

I POC in questo repository hanno come target PostgreSQL in particolare — il caso più forte, poiché PQexec() supporta query impilate e COPY TO PROGRAM fornisce l'esecuzione diretta di comandi OS. Il bypass stesso si trova nel framework SQL condiviso e riguarda tutti i backend:

• PostgreSQL (coperto qui): query impilate tramite PQexec, RCE tramite COPY TO PROGRAM.
• SQLite: query impilate tramite sqlite3_exec, viene eseguito sotto PRIVS_ROOT nel worker di proftpd — l'iniezione della backdoor funziona allo stesso modo; la primitiva RCE differisce (non esiste un equivalente di COPY TO PROGRAM, ma una tabella users scrivibile su un backend SQL in un processo root è più che sufficiente).
• MySQL: il bypass si attiva allo stesso modo, ma raggiungere la tabella users o l'esecuzione di comandi OS dall'interno della singola INSERT di logging è più difficile. La manipolazione con singola istruzione (esfiltrazione tramite subquery in uno slot VALUES, blind basata sul tempo, blind basata sugli errori) è semplice; trasformarla in una scrittura su una tabella diversa richiede di aggirare diversi ostacoli:
  • mod_sql_mysql chiama mysql_real_query() senza CLIENT_MULTI_STATEMENTS, quindi un ; INSERT INTO users … finale viene rifiutato dalla connessione.
  • Un attaccante dovrebbe capire come aggirare questa limitazione per scrivere nella tabella users o in un file su disco.

Nella configurazione PostgreSQL, i POC dimostrano due percorsi di trigger rappresentativi. Le altre combinazioni della tabella sopra sono equivalenti in linea di principio:

• Pre-autenticazione via %U + USER. SQLLog ERR_* rende questo percorso completamente non autenticato.
• Post-autenticazione via %{basename} + STOR. Richiede qualunque credenziale FTP ma nessun privilegio oltre alla possibilità di caricare un file.