TwoMillion这台机器是HackTheBox上一个把“合法功能玩坏”玩到极致的例子。核心考点是两个应用层的JWT越权加模板渲染导致的RCE系统层的OverlayFS内核提权。整个流程走下来你就能体会到一个道理——真正致命的漏洞往往不是某个高危函数而是多个看似无害的功能点串成的一条链。这篇文章我会把从信息收集到最终root的完整路径复盘一遍顺便把我在复现过程中踩到的坑也一并列出来给后面打靶机或者做类似Web渗透测试的朋友做个参考。先交代一下环境。我的攻击机是Kali靶机IP是分配的我这边记为10.10.11.221实际以你的机器编号为准。下面所有命令都是基于这个前提如果你打的不是这个IP替换成你的目标地址就行。1. 前期侦察锁定入口面1.1 目标发现与端口扫描拿到靶机IP后第一件事肯定是nmap。我习惯先用-sC -sV跑一轮再加-p-把全端口过一遍避免漏掉一些非标准端口上的服务。这台机器扫出来很干净只有22和80。nmap -sC -sV -p- -T4 10.10.11.22180端口跳转到了一个域名具体是HTTP重定向到http://2million.htb。这里要注意一个细节浏览器直接访问IP会给你302所以必须在本地把域名落到hosts里否则后面全是错的。这也是HTB机器惯用的套路虚拟主机按域名分发域名不对连不上对应的站点。echo 10.10.11.221 2million.htb | sudo tee -a /etc/hosts改完hosts再访问页面内容就正常了。实战中如果碰到类似情况域名解析是第一步别急着乱扫先把该进的入口进了再说。1.2 Web指纹识别与子域枚举用浏览器打开2million.htb后第一眼就看到“An alternative to the HackTheBox platform”的提示页面风格做得跟HTB早期的v1版本很像整体是个邀请制注册的落地页提供Login和Join按钮。这时候不用急着乱点我一般会先把页面源码和JS文件过一遍。在静态资源里能找到app.js里面有一大段API路由列表。这就很舒服说明前端把所有后端接口都暴露了。常见的接口像/api/v1/login、/api/v1/register、/api/v1/invite/generate这些都能看到。做Web渗透有一个好习惯是先把前端脚本里的接口清单拉出来配合目录扫描基本就能拼出整个应用的地图。我简单试了下常规路径admin目录不存在也没找到明显的备份文件。于是把重点放在邀请码注册这个流程上——千万不要觉得邀请码是无害的很多业务在这里埋了不该暴露的逻辑。2. RCE发现之路从普通注册到管理员越权2.1 邀请码生成中的逻辑漏洞注册必须填邀请码那邀请码从哪来直接POST/api/v1/invite/generate会提示需要权限也就是要先有一枚邀请码。但再看JS里的路由还藏着一个/api/v1/invite/verify接口请求格式是带code参数。这里其实有一个旋转编码的套路返回结果需要用ROT13解码解出来就是生成邀请码的另一个接口路径访问后能得到一串看起来乱码的data字段再解码一次就拿到了可用的邀请码。整个过程不难但折射出一个很常见的开发失误把本该服务端限制的流程全部暴露给前端前端能看到的接口攻击者全都能调。我们拿到邀请码后正常走注册拿到一个账号。这一步其实已经在为后面做铺垫了因为注册是获取JWT的前提而JWT又是这台机器最大的突破口。2.2 JWT越权从普通用户到管理员登录后每个请求都带一个JWT我用jwt.io或者本地的解码工具看了一眼payload里面带isAdmin字段值为false。按常规思路可以试着把isAdmin改成true再放回去但签名校验这关过不去原密钥猜不到。这个点如果只靠手动爆破效率很低。当时我回头翻了翻前端JS发现密钥确实被硬编码在某段脚本里。很多靶机机器为了模拟真实缺陷都故意把这种密钥留在前端现实中我确实见过不少企业也这么干。拿到密钥后直接重签JWT把isAdmin改成true。之后的请求全部换成这个管理员令牌普通用户瞬间就变成了管理员。这里想强调的是JWT的无状态特性决定了它一旦泄露签名密钥谁都拦不住。很多团队只用HS256算法密钥又短又弱这就相当于把大门钥匙放在门垫下面。做题的时候你会觉得这是靶机故意设计但在真实代码评审里这种问题出现的频率比你想象的高得多。2.3 管理端功能与模板渲染导致的RCE换管理员令牌后接口权限一下子大了很多。能访问的管理接口里有一个/api/v1/admin/settings/update对应的是网站的系统设置。其中一个参数是email_template也就是邮件模板的编辑入口。问题在于这个模板内容在服务端做了PHP模板渲染而模板渲染函数没有对PHP代码做任何过滤。换句话说模板里写的是什么最终就会被当成PHP代码执行。尝试在模板内容里插入一段调用系统命令的代码保存后用任意管理员可见的页面触发模板渲染会发现命令确实被执行了。来看一下利用思路的具体命令形态curl -s http://2million.htb/api/v1/admin/settings/update \ -H Authorization: Bearer $ADMIN_TOKEN \ -d email_template...恶意模板...这里我只讲原理模板中嵌入的PHP标签会在渲染时解析配合能够返回结果的页面或错误回显就能确认RCE是否生效。只要命令执行结果能回显下一步就是直接反弹shell。接下来用常见的反弹方式拿shell我把ip改成自己的监听地址用nc起一个监听然后提交包含反弹命令的模板触发后监听端就能收到连接。这里有一个常见坑如果模板保存成功但没触发或者触发了但命令没执行多半是模板没被正确渲染或者参数名不对。需要再回去核对字段名在正常调用和恶意调用之间对比服务端日志。这样RCE就拿到了。从最初的注册接口到管理员令牌再到模板渲染一条完整的攻击链在这里闭合。3. 服务器立足之后信息收集与线索串联3.1 获取稳定的Shell与初始信息收集RCE拿到的是www-data权限的shell。HTB的机器一般没有完整的TTY所以我习惯先升级终端。用python起一个PTY保证后面能用vim、tab补全等交互式操作。python3 -c import pty; pty.spawn(/bin/bash)控制台那边CtrlZ挂起然后stty raw -echo; fg就能得到一个比较顺手的交互终端。升级完之后第一时间看身份、网络、内核和目录。id uname -a cat /etc/os-release ls -la /var/www/html大概能看出这是一个Ubuntu 20.04环境Web根目录在/var/www/html。这时候会顺便看看.env、config.php这类敏感文件有时数据库口令、App密钥就藏在里面。找敏感文件这事优先级比乱翻代码高得多因为应用层拿到shell后最容易突破的点就是配置泄露。3.2 数据库凭据与后台信息在Web目录里翻到一个.env文件里面有数据库的连接信息用户名密码指向本机的MariaDB。这说明这台服务器落着Web应用的数据存储。紧接着用数据库客户端连进去看看有哪些库和表。mysql -u user -ppassword -e show databases;如果运气好里面会直接存在admin用户的密码哈希。不过我当时倒没在这条路上死磕因为哈希很有可能是bcrypt跑字典未必能很快出结果。我印象更深的反而是一个细节数据库里某个表存了后台账号记录换个思路查邮件目录在/var/mail里也可能有线索比如某些给管理员发的系统邮件里面甚至写了高强度口令。不过这台机器真正的突破口不在这里。系统层的提权条件已经摆在眼前了——内核版本在OverlayFS漏洞影响范围内。信息收集做到这一步我心里已经有两个提权方向一个是应用层的历史凭据复用另一个是直接走内核漏洞。哪个更稳就先用哪个。4. OverlayFS提权内核漏洞的研判与利用4.1 为什么选OverlayFSuname -a看到的内核是5.4.x这是Ubuntu 20.04很常见的版本。Check一下当前用户是不是在docker或其他受限容器里排除容器逃逸方向后判断内核层面有一个非常经典且稳定的提权面CVE-2021-3493也就是OverlayFS文件系统在copy_up流程中的权限校验缺陷。OverlayFS是Linux里一种堆叠文件系统用来把多个目录层合并挂载成单个视图。Docker的镜像分层依赖的就是它。而在某些内核版本中当overlayfs把一个lower层文件复制到upper层时对文件权限位的处理存在漏洞普通用户通过用户命名空间创建特殊文件再配合setuid特性就能在宿主机层面获得root权限。这个洞影响Ubuntu 20.04、Debian等一堆系统利用条件非常低本地普通用户就能触发不需要任何额外的交互。在HTB的机器上这就等于给了你一个稳定的root通道。选择它还有一个现实原因不需要任何额外的凭据不需要猜密码利用门槛就在这摆着比破解哈希省事多了。4.2 CVE-2021-3493的利用思路我对这个洞的理解用一句话概括用户命名空间给了普通用户创建“伪root”环境的能力而overlayfs在copy_up时没有正确区分命名空间边界导致文件的能力比特被错误地保留下来从而在真实root视角下出现一个本不该存在的setuid文件。实际利用时思路通常是检查当前内核是否支持unshare用户命名空间将已公开的exp源码编译成可执行文件上传到目标机器/tmp目录即可注意可执行权限运行后等待判定最终显示uid0(root)这中间有几个小坑。第一目标机器未必装了gcc所以exp经常需要在本机或攻击机交叉编译好再传上去。第二上传到/tmp后要确认没有noexec挂载否则会报权限错误。第三编译时如果目标机缺少头文件会非常麻烦所以更优的做法是静态编译或直接使用漏洞库中已经编译好的适配版本。这个机器上实测下来用公开exp就能一次成功关键是要选对适配内核版本的exp。4.3 提权执行与结果确认我把编译好的利用程序上传到目标机器的/tmp目录后先执行了id确认权限和用户命名空间是否可用。运行exp时过程里会创建用户命名空间、挂载overlayfs、构造恶意文件看起来输出有点乱但只要最后能执行/bin/sh并且权限是root就说明copy_up时期望的特权文件已经生效。./cve-2021-3493 id uid0(root) gid0(root) groups0(root)到这里这台机器的root就到手了。在真实项目中拿到root之后我不会马上收工而是会把提权过程中找到的凭据、进程、网络连接再梳理一遍看看有没有后续横向扩展的可能。HTB上一般只需要读取/root/root.txt证明渗透完成。回过头看这台的提权其实“重”在判断要对内核版本敏感要能想到OverlayFS这个方向并在动手前确认适用性。如果一上来就盲目跑各种提权脚本反而可能触发告警或者弄崩环境。很多人喜欢一把梭跑提权枚举器但这台机器其实不需要信息都摆在明面上。5. 踩坑实录与提速技巧5.1 邀请码环节卡住怎么办第一个容易卡住的地方就是邀请码生成。很多人直接请求/api/v1/invite/generate返回说没权限就不知道干嘛了。其实关键点在JS里藏着调一个调试接口就能拿到被ROT13编码的真实生成地址。做这类机器时我建议先把前端JS完整读一遍把所有API端点记下来再逐个测试效率远高于瞎猜。这个方法对于真实渗透项目同样适用前端就是信息富矿。5.2 RCE命令不回显的排查思路如果模板注入后命令没回显可以先在恶意模板里写一个只有几字节的探测响应比如只输出phpinfo第一行确认模板是否被渲染。如果模板确实渲染但还是没命令结果可以换一种思路把命令结果写入一个临时文件再通过静态路径访问。这个方法很笨但能有效排除回显链路的问题。还有一点容易被忽略用curl提交模板时如果参数里有特殊字符没有做URL编码服务端可能只取到一半参数。所以提交前可以把payload先用--data-urlencode处理一下礼貌很多。5.3 OverlayFS提权的版本匹配问题提权失败最多的情况就是版本不匹配。内核小版本差异可能导致exp失效所以执行前先uname -a对照一下。另外如果系统限制了unshareexp会直接报Operation not permitted那就需要切换其他提权方向不能死磕。还有一点上传exp后注意chmod x同时用file命令确认二进制架构别把aarch64的传到x86_64机器上这种低级错误真实发生过。别看这几点不起眼我在不同机器上提权时至少有两次卡在权限位和架构上。5.4 少走弯路的复盘建议TwoMillion这台机器整体难度不高但它把两条主流的攻击链路都练到了应用层的逻辑越权和模板注入系统层的内核提权。新手玩完以后可以重点总结两条经验第一前端泄露的API清单和密钥杀伤力远比想象中要大。很多开发者觉得前端代码无所谓反正别人能看到但里面的接口约定、密钥、调试逻辑都可能在不知不觉中成为突破口。第二拿到低权限shell后先看一眼内核版本和系统版本再决定提权路线盲目跑脚本只会浪费时间和触发告警。像这台机器一看Ubuntu 20.04加5.4内核OverlayFS的优先级就要提到最前面。我个人在实际复现中还有一个体会不要把攻击步骤机械化地背下来要理解每一步为什么这么做。比如JWT为什么能被重签、overlayfs为什么能越权只有理解了原理遇到同类问题才能举一反三。这台机器做完之后我顺手把OverlayFS的机制和JWT签名的注意事项都复习了一遍收获比单纯拿一个root要多得多。
