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

本文分享的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的奖金,原因在于厂商认为用户授权头信息不怎么敏感,但我认为漏洞还是被低估了。但不管怎么说,总比三年前发现这种漏洞时要好得多。

总结

漏洞众测是个特别的行业,除了XSS、CSRF、SQLi等其它通用漏洞的分析外,尝试进行上述逻辑错误配置漏洞的测试,说不定会发现一些独特的攻击面。有些测试起初看似没有意义,但仔细深入就会发现更多隐藏的线索。

*参考来源:medium,clouds 编译整理,转载请注明来自 FreeBuf.COM

来源:freebuf.com 2020-03-29 13:00:16 by: clouds

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论