vulhub靶场通关

凌晨两点，靶场我盯着屏幕上那个熟悉的通关报错页面，第无数次尝试向Tomcat的靶场AJP端口发送畸形请求。隔壁工位的通关老王早睡了，只有风扇的靶场声音陪着我。直到那个返回包里的通关字符串变成`javax.naming.NamingException`，我知道，靶场这次终于通了。通关

Vulhub靶场不是靶场那种花里胡哨的CTF平台。它朴实得像一本字典——每个漏洞都放在独立目录里，通关`docker-compose up -d`一键拉起，靶场然后你面对的通关就是一个真实存在过的漏洞环境。我最初玩它的靶场时候，以为通关就是通关拿到shell，后来发现根本不是靶场那么回事。

第一个让我卡了三天的是`CVE-2019-0232`，Tomcat的CGI-Servlet远程代码执行。官方文档写得清清楚楚：需要开启enableCmdLineArguments，需要Windows系统，需要...我全满足了，就是弹不出计算器。后来翻源码才发现，那个漏洞的触发条件比描述里苛刻得多——请求头里的Content-Type必须精确匹配`application/x-www-form-urlencoded`，少一个字符都不行。那一刻我忽然明白，所谓通关，不是把exp跑通，而是理解漏洞为什么存在。

Vulhub的目录结构本身就带着规律。`fastjson/1.2.47-rce`、`shiro/CVE-2016-4437`、`thinkphp/5-rce`——每个文件夹里都藏着一段历史。我习惯先看`README.md`，里面连漏洞原理都懒得写，只给个链接。真正有趣的是，当你把环境跑起来，用curl手动构造请求时，那些在文章里被反复引用的poc突然活了过来。

有个细节特别有意思。很多漏洞的利用链在Vulhub里是“残缺”的。比如`weblogic/CVE-2020-2551`，环境里没有配好RMI注册中心，你得自己起一个。这反而逼着你理解IIOP协议到底怎么把恶意对象传过去。有次我图省事，直接拿网上现成的exp打，结果反序列化链版本对不上，报了半个小时的ClassCastException。后来老老实实从`weblogic.jms`模块里找可用gadget，反而意外发现了一个没人提过的利用方式。

通关Vulhub最大的障碍不是技术，是耐心。`CVE-2018-2894`那个WebLogic任意文件上传，需要先登录管理后台才能设置work home目录。我一开始完全没登录，直接打上传接口，当然失败。后来才注意到，漏洞描述里写着“需认证”，但很多人（包括我）第一次都会忽略这三个字。这种坑在Vulhub里到处都是——它不会替你踩刹车，也不会给你提示，一切全靠自己读文档、试错。

还有个容易翻车的点是环境依赖。Vulhub的镜像大多基于Ubuntu 16.04，里面自带的Java版本可能跟你的exp不兼容。我遇到过几次`UnsupportedClassVersionError`，最后不得不在容器里手动装个OpenJDK 8。这种时候反而觉得，漏洞利用本来就是脏活累活，跟环境搏斗是常态。

真正让我觉得“通关”的，不是把某个漏洞打穿，而是某天我突然意识到，自己开始能预测Vulhub里那些环境会怎么配置了。比如`jenkins/CVE-2018-1000861`，我一看目录就知道它肯定开放了8080端口，而且没设密码——因为官方文档里就写着一句话“默认无认证”。这种预判能力，是在反复踩坑里长出来的。

现在我用Vulhub的方式变了。不再追求把每个漏洞都打成shell，而是挑几个冷门的，比如`phpunit/CVE-2017-9841`，专门研究它为什么能被直接包含文件。有时候一个下午就盯着Wireshark抓包，看HTTP请求怎么被解析成PHP代码执行的。这种慢功夫，比跑通十个exp有用得多。

最后说句实在的，Vulhub通关没有终点。它更像一面镜子，照出你对Web安全理解得有多浅。那些你打不通的漏洞，不是靶场的问题，是你还没看到某个角落里的细节。凌晨三点，我关掉电脑前又扫了一眼那个报错页面——明天继续。