下面讲述了作者在参与美国国防部（DoD） Hack the Pentagon 漏洞众测项目中，利用JIRA漏洞CVE-2017-9506构造了SSRF攻击面，实现了对美军非保密因特网协议路由器网（NIPRnet）的访问，并且结合其它漏洞技巧，获取到DoD内网系统的一系列敏感信息。由于测试过程和内容的涉密性，该篇文章仅点到为止，未对过多技术细节和详细场景作出披露，仅当学习分享，还望读者多多包涵。
JIRA 是澳大利亚 Atlassian 公司开发的一款优秀的问题跟踪管理软件工具，可以对各种类型的问题进行跟踪管理，包括缺陷、任务、需求、改进等。很多知名公司和开源软件组织都在使用 JIRA，因其采用J2EE技术，并能够进行跨平台部署。
从头说来 - 发现DoD的JIRA应用网站
在参与美国国防部（DoD）的漏洞众测项目时，我发现其中有两个特别的网站部署了项目跟踪管理工具JIRA，经过初略分析后，我认为不存在可利用的漏洞，所以就直接没继续深挖了。
后来，我从Twitter中发现了一条利用JIRA漏洞实现SSRF攻击的发贴：
它的意思是这样的：
JIRA漏洞CVE-2017-9506说明
荷兰安全研究机构Dontpanic给出了CVE-2017-9506大概的漏洞原因：JIRA包含的认证授权插件Atlassian OAuth plugin中存在一个名为 IconUriServlet 的组件，它用于接收客户端中附带参数值consumerUri的GET请求，但IconUriServlet 组件也能用于创建由服务端执行的另外一种HTTP GET请求，这种由JIRA作为间接代理发起的请求，由服务端响应后再经JIRA返回给客户端，该过程中通过构造请求，可导致服务端内部信息泄露在响应内容中返回给客户端。
Dontpanic给出的漏洞验证方法：
把basepath换成JIRA系统网站链接，访问上述页面之后，如果正常出现google.com页面，则证明JIRA系统存在该漏洞；如果访问出现404页面，则漏洞不存在。请注意，在consumerUri的末尾添加要测试的网站的请求！！！
测试DoD的JIRA应用网站漏洞
仔细阅读了CVE-2017-9506的说明之后，我如获至宝，赶紧转向之前发现的两个国防部网站上，急切想验证一下这种漏洞利用技术的可行性。我测试了其中一个网站后发现，居然可以成功跳转到Google页面，这说明该网站一定存在漏洞！
根据AWS规定，任何实例都可通过请求AWS设定的元数据地址169.254.169.254，来检索自身实例元数据示例（相关方法可参考AWS官方说明），为此我构造了以下链接发起请求：
竟然能看到内部主机名！好吧，那我来试试能否获取AWS密钥呢：
但好像不行。经过仔细阅读AWS官方文档后，我重新使用了以下链接来获取实例ID、私有IP地址等信息：
很好，竟然都能成功响应获取到！
到了这一步，我想应该能说明问题了，于是没再深入测试就简单写了份漏洞报告进行提交，但之后，DoD的项目分类人员把该漏洞定级为中危漏洞，但我认为这绝对是一个严重的高危漏洞。我与国防部进行了交流后，申请了深入测试的授权，以便测试该漏洞的最终影响。
深入测试 - 实现对非保密因特网协议路由器网（NIPRnet）的访问和其它敏感信息获取
前期侦察发现
首先，我从基本的端口探测开始，发现目标系统开启了21、22、80、443、8080端口，有了这些端口信息之后，我就能测试各种错误信息的返回，通过这些信息判断目标系统中的服务器和网络部署情况，如下对目标系统8080端口发起请求后的响应信息：
其次，我又对gopher文件目录查看协议、DICT字典服务器协议、FTP协议、LDAP轻量级目录访问协议等其它协议作了一遍请求测试。如系统返回了以下不支持LDAP的响应：
综合利用发现
在记录下这些信息时，我又想到了PortSwigger首席研究员James Kettle的在USA 2017黑帽大会的研究分享《Cracking the Lens: Targeting HTTP’s Hidden Attack-Surface》，James Kettle通过构造恶意的HTTP请求和Header头信息，侧面勾勒出目标系统中HTTP服务的隐藏攻击面，最终，他利用了这种技术，‘伪装’成美国国防部内部IP身份，成功入侵访问到了DoD受限的内部网络系统和相关资源。我记得在Kettle的分享中，他还展示了两个他曾用来作入侵测试的DoD内部网站：（网站信息出处defensivecarry.com）
结合这两个James Kettle提到过的DoD内部网站，用我发现的DoD的两个JIRA网站来向它们发起请求，目的就是测试能否以这种途径实现对James Kettle提到的两个DoD内部网站的访问。最终，我用其中一个JIRA网站向James Kettle提到的两个DoD内部网站发起请求后，其中一个显示请求超时：
另一个返回了US Goverment（USG）的政府警告信息，如下：
在此测试过程中，我还发现了其它的DoD内部web服务，通过该内部web服务，我竟然能成功访问到美军的非保密协议路由网（NIPRnet），该网络系统被DoD内部用来处理比机密级较低的敏感级信息。由于保密性原则，在此我就不详细披露具体方法和途径。
通过响应内容判断获取内部敏感信息
我用第二个JIRA网站向James Kettle提到的两个DoD内部网站发起请求后，返回的响应信息基本没什么可用之处。
经过测试，最终我发现可以根据响应时间来评估DoD内部系统端口的开放情况。就比如，当向内部系统请求22端口时候，其响应用时1000毫秒，而请求21端口时响应用时将近10000毫秒，从这种时间差上可对一些端口情况作出猜测判断。另外，由于缺少详细的错误信息响应返回，我无法对系统中的具体协议作出判断，但我要着重强调本文的重点是：通过该内部的web服务端，我可以访问到DoD的非保密协议路由网（NIPRnet）！我还使用了Burp的Collaborator插件探测了对该web服务端请求发起后，服务端和请求端数据交换时存在的信息泄露情况。
比如从请求头中的'X-Forwarded-For’可以获取到内部IP，我用Burp的Collaborator插件查询了所有可交互的内部IP，虽然最终能查询到内部IP和相关的网络服务信息，但却不能在该web服务端上实现AWS元数据检索。
最终，我向DoD提交了涉及的两个漏洞之后，两个漏洞都被评级为高危（Critical），由此，我联想到我今年年初向DoD上报的两个SSRF漏洞，想看看上述漏洞能否用这种SSRF方式有所深入利用。
JIRA SSRF的深入利用
我年初上报的两个SSRF漏洞是，用某个web应用过滤器可以对特定的IP地址发起HTTP连接请求，例如能以提交CONNECT IP 请求方式，枚举出目标系统内的应用服务；另外也能通过更改主机头信息对目标系统内部IP或外部IP发起经过验证的请求信息，如militarywebsite.mil@internal_IP。当我在这两个JIRA网站上用这种SSRF方式进行测试时发现，之前提示超时、SSL错误和其它响应的请求环境中，竟然也能用Blind SSRF方法实现对内部IP和网络服务进行枚举探测。所以，这个点上的SSRF漏洞利用最终也被DoD评级为中危。
JIRA SSRF漏洞利用的其它技巧
在我对以上漏洞的综合测试过程中，我发现在某些情况下，会莫名其妙地发生堆栈错误并泄露各种敏感信息，比如，用不完整的HTTP头信息http://或http://[::]，这种堆栈错误时泄露的敏感信息包括数据库IP、数据库版本、应用插件、操作系统架构和其它系统：
发生堆栈错误时，仍然可以继续对目标网站进行深入的信息获取利用，比如，我发现有时候目标网站会指向其它Altassian实例，如某次测试中，我发现目标站点某子域名中部署有Altassian的confluence实例，经过测试证明，这些实例同样会受到信息泄露漏洞的影响。
总结梳理
作者描述了参与美国国防部漏洞众测项目时发现的JIRA漏洞，并概要性地介绍了整个漏洞利用的测试过程，我们一起来梳理下：
以上就是利用JIRA漏洞访问美军非保密因特网协议路由器网的示例分析的详细内容，更多请关注Work网其它相关文章！