来源：https://mp.weixin.qq.com/s/NRGzXvW1RuZc0pTB7xFtVw
**从“扫不到漏洞”到“稳定产出”**

**我的CDN绕过+漏洞挖掘之路**

**第一步：踩坑！域名打不准，不代表没漏洞**

第一次挖时我其实也有点懵：在目标站点上，我能看到“有业务、有页面、有接口”，但用域名去扫，总是：

*   命中一堆看起来“像是代理层”的东西
    
*   或者请求能通，但权限/返回内容不对
    
*   甚至目录/接口爆不出结果

师傅提过一个思路：如果域名在CDN/WAF后面，先验证资产落点。

于是我把精力从“直接利用”转向“确认是否CDN”：

*   **多地Ping 看解析和落点是否一致**
    
    用多地 Ping 服务去观察：同一个域名在不同地区解析/延迟表现是否“非单点”。
    
    用到了 **ping.chinaz.com** 这种多地检测的思路：
    
    *   如果我发现不同地区表现差异明显、IP 不唯一，基本就可以把它归类为“多节点分发”，CDN 的可能性会很高；
        
    
    ![图片](/media/202604/72b566cdca2e4e18ab276b43779205116341.png)

*   **nslookup：看DNS返回多个IP的情况**
    
    **接着用**`nslookup`做确认（原理很简单：**解析结果如果对应多个IP，通常意味着CDN轮询/多节点**）。
    
    重点看两点：
    
    *   nslookup 返回的 Address 是否有多个
        
    *   是否能看到“Aliases/多记录”对应到多个节点 IP

nslookup 的验证逻辑是：**返回多个 IP 多半是用了 CDN**。

举例：

使用了CDN

![图片](/media/202604/95b0d7ae2eb24ade896fddcf5145741b7975.png)

未使用CDN

![图片](/media/202604/511b691311ef49238666ca4615d41e1b9297.png)

做完这一步，基本就能确定：直接对域名打，不会是我想要的源站角。

**第二步：关键一跳！绕过CDN找到源站真实IP**

这一段我觉得是这次出结果的“返现关键”，因为只要源站 IP 找对，后面漏洞利用会瞬间变得顺滑。

我用了三种师傅提过的方法：

### 方法一：绕过主站，去探子域名

主站接 CDN 很常见，但子域名往往维护成本更高，有些根本没上 CDN。  
所以我做的是：

1.  **批量采集目标站点子域名**
2.  再逐个去解析/探测
    
3.  找到那些“疑似未走 CDN 的子域名/落点”
    
4.  借助它们定位到源站真实 IP

> 这一步我个人很喜欢用“探测优先”的思维：先把资产面铺出来，再做筛选，不然一直盯一个域名容易浪费时间。

### 方法二：网络空间引擎搜索法（Quake / FOFA / Hunter）

当我觉得子域名探测效率不够快，我就会直接用网络空间引擎补位。  
复盘材料里点名了类似 **quake、fofa、hunter** 的思路：它们有时候能直接给到真实 IP、端口、历史指纹。

我会用引擎结果做“反向确认”：

*   引擎给的 IP 是否和业务端口吻合？
    
*   是否能访问到与域名不同的服务表现？
    
*   是否能出现 swagger/目录等“源站特征”？

![图片](/media/202604/1faa26aa86654de2936fc4923cb846fe9613.png)

### 方法三：海外 DNS 解析

师傅在上课时说过：有些 CDN 运营商主要对国内线路做了完善节点，而海外节点覆盖有限。  
于是我尝试用海外 DNS/海外解析工具去“看另一套视角”。  
通过海外解析/探测，往往更容易得到源站真实 IP。

![图片](/media/202604/0afcfa80be2b4ec1b043910aef5b6f546449.png)

我自己的感受：这一招不是每次都成功，但一旦命中，就非常快，属于“赌对了直接起飞”。

**第三步：拿到源站后，我是怎么打出2高危2中危？**

当我拿到真实 IP 后，后续就不是“瞎试”，而是按服务类型做针对性测试。

### 高危 1：路径爆破直接拿到 Swagger（信息泄露）

先对源站做路径爆破，目标就是找那种**能直接泄露接口路由**的入口。

最终我打到了类似：

*   `http://<源站IP>:8088/swagger/`

![图片](/media/202604/cfac98feb9304502a4b343d4defc2c0d8644.png)

页面里出现了 **Servers** 和多个接口的 `GET` 入口信息。  
这类信息泄露在 src 里往往很容易升高危，因为它能降低后续利用门槛。

### 高危 2：端口爆破 + 目录遍历

在确认 `:8088` 相关服务可用后，继续扩展到更多端口/服务面。

对 IP 做端口爆破后，发现 `:8088` 具备目录遍历特征，并能看到类似：

*   `Index of /`

当出现“目录索引页”，通常意味着对文件路径访问/目录列出存在缺陷，进一步可能读到敏感资源或配置信息。

![图片](/media/202604/4585d64842b84b5cb5bf133bb48df93b5847.png)

### 中危 1：页面弱口令爆破拿到后台

随后我对源站发现还有 web 系统入口，并尝试了弱口令。

命中的入口类似：

*   `http://<源站IP>:8081/#/console`
*   账号密码：`admin admin`

页面是后台/控制台风格。  
如果后台存在弱口令而且可直接登录，最终定级取决于实际权限范围。

![图片](/media/202604/37ec5d966d4b45d38234e3711ec201eb6657.png)

### 中危 2：另一个登录页弱口令

同样的逻辑，我继续对其他端口的管理页面验证弱口令风险。

命中类似：

*   `http://<源站IP>:18083/#/login?redirect=...`
*   账号密码：`admin 123456`

这种属于“同一类问题的不同入口复现”，也能提高报告说服力：不是偶然猜中，而是存在配置类薄弱点。

![图片](/media/202604/058c3822cc89427aadaceff5952f56213271.png)

**第四步：经验总结：为什么这次能出成果？**

我自己的总结：  
1\. 资产落点对准：先绕开CDN找到源站，避免无效操作；  
2\. 信息入口拿到：Swagger是漏洞加速器，提供接口和路径方向；  
3\. 利用链形成：从信息泄露到目录遍历、弱口令，逐步扩大影响。

绕过CDN获取2高2中