挖洞经验 | 从负载均衡或CDN应用中发现的配置类漏洞

本文分享的Writeup是作者在测试一些目标服务相关的负载均衡或CDN应用时发现的错误配置型漏洞，这些漏洞有些发生服务端犄角旮旯的响应消息中，可能很少会引人注意，我们一起来看看。

前言

当针对一个Web应用测试目标进行漏洞分析时，我通常最后都会检查两件事：

1、在HTTP响应的Burp历史记录中查找一些涉及到的用户账户相关信息，如用户名、邮箱地址、手机号码等等；

2、通过Burp被动扫描收集分析HTTP响应中所有邮箱地址。

这样做的目的是为了寻找更多的攻击面，特别是针对IDOR或访问控制类型漏洞时尤为有用。然而这种习惯却逐渐成了我挖掘奇怪漏洞过程中必不可少的操作，此处我就分享一些类似漏洞安全，希望能对大家起到借鉴作用。

漏洞1：奇怪的负载均衡错误配置漏洞（$400）

这个漏洞以前我从没见过，当我在分析Burp被动扫描收集的HTTP响应消息邮箱地址时，我发现其中一个并不属于我的Gmail邮箱地址，于是，我就查找这个邮箱的具体归属，之后我在其HTTP响应消息中的的某个服务端HTML脚本源码中发现了它的身影，可见这是一个包含了用户ID和邮箱的响应：

它看上去非常奇怪，原因在于，当我把这个HTTP响应的主请求重新切换到Repeater中进行请求重发时，响应回来的却又是我自己相关的邮箱地址、用户ID和其他账户设置，刚刚那个Gmail邮箱地址又神奇的不见了！这是怎么回事，难道是我收集到了其他用户的邮箱地址了？

经过一番分析验证，原来是这样的，如果当前用户在没有特定的用户“Cookie”信息时，若他对目标服务端发起了请求，那么就会导致前端的负载均衡应用出现响应错乱，错把其他用户的用户个人响应到了那个JS脚本中，显示到了当前用户的响应消息中。

所以，如果当前用户把自己的所有Cookie信息删除后，对目标服务端发起请求，就会在HTTP响应中获取到其他用户包括个人邮箱在内的用户信息。而且，每次执行不同的请求，负载均衡应用就会响应给客户端不同的其他用户信息。因此，如果不停的Repeat重放请求，那么将会以此方式获取到目标网站中的大量注册用户敏感信息。如下变换请求获得其他用户的个人注册信息：

漏洞2：白名单用户信息泄露漏洞（$800）

有了上个漏洞的基础，在后续的测试中我就多了一些心眼。这不，几天之后，我又在一次网站测试中发现了类似漏洞，在某个请求涉及的whitelistExternalUserEmails参数中，服务端响应回来了一个脚本文件，其中包含了17个奇怪的邮箱地址，如下：

于是乎，我在目标网站上对这些邮箱进行了分析，之后发现这些邮箱对应的账户都是一些已经存在的有效账户。后续我搞明白了，原来这是一些目标网站应用的白名单用户，用以排除在某种安全限制之外之用（有可能是WAF），但是却错误地配置到了响应的脚本页面中了。

漏洞3：负载均衡的浅拷贝缓存漏洞

在某次渗透测试中，我发现与第一个漏洞类似的信息泄露问题，同样是我在查找Burp被动扫描记录时发现的：

这个漏洞与第一个漏洞的不同之处在于，我无法通过它来收集获取其他用户的相关个人信息，但由于这是一个渗透测试项目，我就直接和客户方进行了交流沟通，之后，客户方经过调查给我的解释为：

由于服务后端存在某个对象实体的浅拷贝（Shallow Copy），当对象实体引用了其他用户数据时就会发生暂时的缓存，当该对象实体返回后，存在该漏洞问题的页面将会在其中渲染加载****实例信息。

之后验证发现，这种情况在目标服务端每小时都会发生一次的事，非常难以定位复现，但在我多了个心眼的情况下，好在帮助客户发现了这个问题。

漏洞4：用户授权Authorization Header头信息泄露漏洞

同样的，在测试某个目标API应用时，当我在检查HTTP响应中我自己的注册用户名时，我发现它竟然包含在了其中一个JS脚本中，该脚本中还包含了我对访问该API的授权Authorization Header头信息，这是不是一个跨站脚本包含(XSSI)漏洞呢？

之后，我发现即使把我账户相关的会话Cookie删除之后，发起该请求，一样还会返回我的用户名和授权Authorization Header头信息：

我根本想不到会如此，所以我又接着进行了以下测试：

1、如果更改其中的loc参数，JS脚本响应的消息就会会包括上述用户相关泄露信息；

2、如果以第二个用户身份访问目标API应用，JS脚本中响应的就会是该用户相关的个人信息；

3、同样，在第二个用户会话环境下，即使删除所有会话Cookie，JS脚本返回的信息依然是第二个用户的个人信息。

现在来看，由于这是一个JS脚本文件，它由目标API服务的前端CDN执行了缓存，其中包含了loc参数上。有两种利用方式，一是即使loc参数无效，那么目标API服务端将会返回响应用户的授权头信息，利用这个点可以构造钓鱼链接，以无效的loc为参数，发送给受害者，诱惑其点击，那么就会把其授权Authorization Header头信息缓存在JS脚本中。

另一种为有效的loc参数环境下，可以通过loc参数样式构造字典，对API服务端进行枚举请求，那么，将会获取到一些有效loc参数相关的注册用户个人信息。

该漏洞上报后只收获了$300的奖金，原因在于厂商认为用户授权头信息不怎么敏感，但我认为漏洞还是被低估了。但不管怎么说，总比三年前发现这种漏洞时要好得多。