ProFTPD 漏洞概念验证（POC）

针对 CVE-2026-42167 的概念验证演示，这是 ProFTPD 的 mod_sql 日志记录管道中的一个 SQL 注入漏洞，允许未认证的攻击者执行任意 SQL —— 并可将后门用户注入到 FTP 认证数据库中，或在数据库主机上实现远程代码执行。

所有 POC 均针对 PostgreSQL，但后门用户 POC 在经过一些查询修改后（我们将其留给读者作为练习），也适用于 MySQL 和 SQLite 后端。

• 该漏洞由 ZeroPath Research 发现。 我们的技术博客提供了更多细节。

漏洞

is_escaped_text() 绕过 —— mod_sql SQLLog（CVE-2026-42167，CWE-89）

ProFTPD 的 mod_sql 通过 SQLLog / SQLNamedQuery 机制记录每条 FTP 命令。当解析 %U（原始用户名）或 %{basename}（文件名组件）等格式变量时，框架会调用 is_escaped_text() 来判断是否需要转义 —— 并且对于任何以单引号开头和结尾、且内部不包含单引号的值（例如 '|| (SELECT 1) ||'），完全跳过转义。该检查纯粹是语法层面的，并在原始的攻击者控制的输入上运行，因此无法区分“由可信代码预先转义”和“由攻击者伪造的看起来像预先转义”。

标准文档模式将格式变量用单引号包裹以保证 SQL 安全：

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

当攻击者提供形如 '<payload>' 的值时，替换后会在最终 SQL 中产生 ''<payload>'' —— 两个空字符串字面量闭合了周围的引号，而 payload 作为原始 SQL 执行。对于 PostgreSQL（PQexec）或 SQLite（sqlite3_exec），支持堆叠查询意味着 payload 可以是一条完整的 INSERT、UPDATE、CREATE TABLE 或 COPY TO PROGRAM 语句。

服务器何时可利用？

漏洞代码位于 contrib/mod_sql.c（共享 SQL 框架）中，而非任何特定后端，因此所有 SQL 后端都受影响 —— 但攻击面取决于管理员如何配置日志记录。当以下两个条件同时满足时，服务器可利用：

1. 管理员定义了一条 SQLNamedQuery INSERT（或 UPDATE），其格式字符串插入了这些攻击者可控制的变量并用单引号包裹 —— 例如 "'%U', '%m'"。来自攻击者输入的变量有：

攻击者能做什么？

绕过将日志记录路径转变为后端上的任意 SQL 原语。两个影响最大的场景：

• 注入一个具有任意权限的后门用户（认证绕过）。 ProFTPD 的 SQL 认证后端从相同的 users 表中读取用户名、密码哈希、uid、gid、主目录和 shell，而日志记录的 INSERT 现在可以向该表写入。一个堆叠的 INSERT INTO users 会植入攻击者选择的账户 —— uid=0、homedir=/、明文密码 —— 然后攻击者通过 FTP 守护进程正常登录，获得完整的文件系统访问权限。可通过 %U + SQLLog ERR_* 路径在预认证阶段达成，或通过任何攻击者可控制的变量绑定到攻击者可发出的命令（例如 %{basename} + SQLLog STOR）在认证后达成。适用于 PostgreSQL 和 SQLite（两者都支持堆叠查询）。

• 通过 COPY TO PROGRAM 在数据库主机上实现远程代码执行。 PostgreSQL 的 COPY (SELECT …) TO PROGRAM '<cmd>' 会在数据库服务器上通过 shell 运行 <cmd>。堆叠查询注入执行 COPY TO PROGRAM 可以以 postgres 操作系统用户身份执行任意 OS 命令，足以窃取凭据、横向移动和持久化。可通过与后门用户案例相同的触发器路径达成（预认证通过 %U，认证后通过 等）。仅适用于 PostgreSQL，并且要求 ProFTPD 数据库角色具有超级用户权限（ 的前提条件）—— 这在单租户部署中很常见，因为该角色通常是数据库所有者。

POC 选择

本仓库中的 POC 专门针对 PostgreSQL —— 最强大的一种情况，因为 PQexec() 支持堆叠查询，而 COPY TO PROGRAM 提供直接的 OS 命令执行。绕过本身位于共享 SQL 框架中，影响所有后端：

• PostgreSQL（此处覆盖）：通过 PQexec 堆叠查询，通过 COPY TO PROGRAM 实现 RCE。
• SQLite：通过 sqlite3_exec 堆叠查询，在 proftpd 工作进程中以 PRIVS_ROOT 运行 —— 后门注入方式相同；RCE 原语不同（没有 COPY TO PROGRAM 的等价物，但对于根进程的 SQL 后端而言，可写的 users 表已经足够了）。
• MySQL：绕过的触发方式相同，但在单个日志 INSERT 中访问 users 表或执行 OS 命令更加困难。单语句操作（子查询在 VALUES 槽中泄露、基于时间盲注、基于错误盲注）很简单；但要将其转化为向不同表的写入则需要克服几个障碍：
  • mod_sql_mysql 调用 mysql_real_query() 时没有 CLIENT_MULTI_STATEMENTS，因此尾部的 ; INSERT INTO users … 会被连接拒绝。
  • 攻击者需要找出如何绕过此限制，才能写入 users 表或磁盘上的文件。

在 PostgreSQL 设置中，POC 演示了两个代表性的触发器路径。表中其他组合原理上是等价的：

• 预认证通过 %U + USER。 SQLLog ERR_* 使其完全无需认证。
• 认证后通过 %{basename} + STOR。 需要任何 FTP 凭据，但上传文件的能力外无需其他权限。

仓库内容

• setup/ —— 自动环境设置。克隆 ProFTPD 源码树并固定到报告这些发现时的提交，构建支持 mod_sql + mod_sql_postgres 的守护进程，并搭建 Docker Compose 集群（ProFTPD + PostgreSQL），包含种子数据和易受攻击的 SQLLog 配置。

• pocs/ —— 五个利用脚本。均为仅依赖标准库的自包含 Python 脚本。

  • preauth_user_backdoor.py —— 预认证 %U 触发器 → 将后门用户（uid=0，homedir=/）注入认证数据库。无需凭据，无需数据库超级用户。该 POC 仅限 PostgreSQL，但也可利用 mysql 或 sqlite 后端加以利用。
  • preauth_user_rce.py —— 预认证 %U 触发器 → 通过 COPY TO PROGRAM 在 PostgreSQL 主机上实现 RCE。无需凭据。要求 ProFTPD 数据库角色是 PostgreSQL 超级用户。
  • postauth_stor_backdoor.py —— 认证后 %{basename} 触发器 → 注入后门用户。需要任何已认证的 FTP 用户。该 POC 仅限 PostgreSQL，但也可利用 mysql 或 sqlite 后端加以利用。
  • postauth_stor_rce.py —— 认证后 触发器 → 在 PostgreSQL 主机上实现 RCE。需要任何已认证的 FTP 用户和 PostgreSQL 超级用户数据库角色。

使用说明

先决条件：Docker、Git、Python 3.10+ 和 uv。

cd setup
./setup.sh

首次运行会克隆 ProFTPD 源码并构建服务器（约 2-3 分钟）。后续运行会重用构建缓存，并在几秒内启动。

设置完成后，会打印完整的环境详情（FTP 和数据库端点、测试凭据以及可粘贴的 POC 命令）。按照这些说明运行 POC。

拆除环境：

cd setup
./teardown.sh