Hack the Pentagon | 利用JIRA漏洞访问美军非保密因特网协议路由
本文讲述了作者在参与美国国防部（DoD） Hack the Pentagon 漏洞众测项目中，利用JIRA漏洞CVE-2017-9506构造了SSRF攻击面，实现了对美军非保密因特网协议路由器网（NIPRnet）的访问，并且结合其它漏洞技巧，获取到DoD内网系统的一系列敏感信息。由于测试过程和内容的涉密性，该篇文章仅点到为止，未对过多技术细节和详细场景作出披露，仅当学习分享，还望读者多多包涵。
JIRA 是澳大利亚 Atlassian 公司开发的一款优秀的问题跟踪管理软件工具，可以对各种类型的问题进行跟踪管理，包括缺陷、任务、需求、改进等。JIRA采用J2EE技术，能够跨平台部署，很多开源软件组织和知名公司都在使用JIRA。
从头说来 – 发现DoD的JIRA应用网站
在参与美国国防部（DoD）的漏洞众测项目时，我发现其中有两个特别的网站部署了项目跟踪管理工具JIRA，经过初略分析后，我认为不存在可利用的漏洞，所以就直接没继续深挖了。
后来，我从Twitter中发现了一条利用JIRA漏洞实现SSRF攻击的发贴：
它的意思是这样的：
JIRA用户小心了，JIRA漏洞CVE-2017-9506能被攻击者利用，用于窃取你的内网数据。这是一种开放重定向漏洞，但在某些情况下，它可被利用重定向到内部JIRA系统的本地链接地址中，从而导致如AWS密钥等某些内部资源信息泄露。
JIRA漏洞CVE-2017-9506说明
荷兰安全研究机构Dontpanic给出了CVE-2017-9506大概的漏洞原因：JIRA包含的认证授权插件Atlassian OAuth plugin中存在一个名为 IconUriServlet 的组件，它用于接收客户端中附带参数值consumerUri的GET请求，但IconUriServlet 组件也能用于创建由服务端执行的另外一种HTTP GET请求，这种由JIRA作为间接代理发起的请求，由服务端响应后再经JIRA返回给客户端，该过程中通过构造请求，可导致服务端内部信息泄露在响应内容中返回给客户端。
Dontpanic给出的漏洞验证方法：
https://%basepath%/plugins/servlet/oauth/users/icon-uri?consumerUri=https://google.com
把basepath换成JIRA系统网站链接，访问上述页面之后，如果正常出现google.com页面，则证明JIRA系统存在该漏洞；如果访问出现404页面，则漏洞不存在。请注意，是在consumerUri后面加上请求测试的网站！！！！！
测试DoD的JIRA应用网站漏洞
仔细阅读了CVE-2017-9506的说明之后，我如获至宝，赶紧转向之前发现的两个国防部网站上，急切想验证一下这种漏洞利用技术的可行性。我先测试了其中一下网站，竟然能正常跳出google页面，那只肯定是存在漏洞的了！
https://website.mil/plugins/servlet/oauth/users/icon-uri?consumerUri=http://google.com
根据AWS规定，任何实例都可通过请求AWS设定的元数据地址169.254.169.254，来检索自身实例元数据示例（相关方法可参考AWS官方说明），为此我构造了以下链接发起请求：
https://website.mil/plugins/servlet/oauth/users/icon-uri?consumerUri=http://169.254.169.254/latest/meta-data/local-hostname/
竟然能看到内部主机名！好吧，那我来试试能否获取AWS密钥呢：
https://website.mil/plugins/servlet/oauth/users/icon-uri?consumerUri=http://169.254.169.254/latest/meta-data/iam/security-credential
但好像不行。在认真阅读了AWS官方说明文档之后，我再次用以下链接尝试来获取包含实例 ID、私有IP地址等信息：
https://website.mil/plugins/servlet/oauth/users/icon-uri?consumerUri=http://169.254.169.254/latest/dynamic/instance-identity/document
很好，竟然都能成功响应获取到！
到了这一步，我想应该能说明问题了，于是没再深入测试就简单写了份漏洞报告进行提交，但之后，DoD的项目分类人员把该漏洞定级为中危漏洞，但我认为这绝对是一个严重的高危漏洞。经过一番沟通之后，我向DoD申请了深入测试授权，想继续测试一下这个漏洞到底会有什么最终影响。
深入测试 – 实现对非保密因特网协议路由器网（NIPRnet）的访问和其它敏感信息获取
前期侦察发现
首先，我从基本的端口探测开始，发现目标系统开启了21、22、80、443、8080端口，有了这些端口信息之后，我就能测试各种错误信息的返回，通过这些信息判断目标系统中的服务器和网络部署情况，如下对目标系统8080端口发起请求后的响应信息：
其次，我又对gopher文件目录查看协议、DICT字典服务器协议、FTP协议、LDAP轻量级目录访问协议等其它协议作了一遍请求测试。如系统返回了以下不支持LDAP的响应：
本文讲述了作者在参与美国国防部（DoD） Hack the Pentagon 漏洞众测项目中，利用JIRA漏洞CVE-2017-9506构造了SSRF攻击面，实现了对美军非保密因特网协议路由器网（NIPRnet）的访问，并且结合其它漏洞技巧，获取到DoD内网系统的一系列敏感信息。由于测试过程和内容的涉密性，该篇文章仅点到为止，未对过多技术细节和详细场景作出披露，仅当学习分享，还望读者多多包涵。
JIRA 是澳大利亚 Atlassian 公司开发的一款优秀的问题跟踪管理软件工具，可以对各种类型的问题进行跟踪管理，包括缺陷、任务、需求、改进等。JIRA采用J2EE技术，能够跨平台部署，很多开源软件组织和知名公司都在使用JIRA。
从头说来 – 发现DoD的JIRA应用网站
在参与美国国防部（DoD）的漏洞众测项目时，我发现其中有两个特别的网站部署了项目跟踪管理工具JIRA，经过初略分析后，我认为不存在可利用的漏洞，所以就直接没继续深挖了。
后来，我从Twitter中发现了一条利用JIRA漏洞实现SSRF攻击的发贴：
它的意思是这样的：
JIRA用户小心了，JIRA漏洞CVE-2017-9506能被攻击者利用，用于窃取你的内网数据。这是一种开放重定向漏洞，但在某些情况下，它可被利用重定向到内部JIRA系统的本地链接地址中，从而导致如AWS密钥等某些内部资源信息泄露。
JIRA漏洞CVE-2017-9506说明
荷兰安全研究机构Dontpanic给出了CVE-2017-9506大概的漏洞原因：JIRA包含的认证授权插件Atlassian OAuth plugin中存在一个名为 IconUriServlet 的组件，它用于接收客户端中附带参数值consumerUri的GET请求，但IconUriServlet 组件也能用于创建由服务端执行的另外一种HTTP GET请求，这种由JIRA作为间接代理发起的请求，由服务端响应后再经JIRA返回给客户端，该过程中通过构造请求，可导致服务端内部信息泄露在响应内容中返回给客户端。
Dontpanic给出的漏洞验证方法：
https://%basepath%/plugins/servlet/oauth/users/icon-uri?consumerUri=https://google.com
把basepath换成JIRA系统网站链接，访问上述页面之后，如果正常出现google.com页面，则证明JIRA系统存在该漏洞；如果访问出现404页面，则漏洞不存在。请注意，是在consumerUri后面加上请求测试的网站！！！！！
测试DoD的JIRA应用网站漏洞
仔细阅读了CVE-2017-9506的说明之后，我如获至宝，赶紧转向之前发现的两个国防部网站上，急切想验证一下这种漏洞利用技术的可行性。我先测试了其中一下网站，竟然能正常跳出google页面，那只肯定是存在漏洞的了！
https://website.mil/plugins/servlet/oauth/users/icon-uri?consumerUri=http://google.com
根据AWS规定，任何实例都可通过请求AWS设定的元数据地址169.254.169.254，来检索自身实例元数据示例（相关方法可参考AWS官方说明），为此我构造了以下链接发起请求：
https://website.mil/plugins/servlet/oauth/users/icon-uri?consumerUri=http://169.254.169.254/latest/meta-data/local-hostname/ www.wnhack.com
竟然能看到内部主机名！好吧，那我来试试能否获取AWS密钥呢：
https://website.mil/plugins/servlet/oauth/users/icon-uri?consumerUri=http://169.254.169.254/latest/meta-data/iam/security-credential
但好像不行。在认真阅读了AWS官方说明文档之后，我再次用以下链接尝试来获取包含实例 ID、私有IP地址等信息：
https://website.mil/plugins/servlet/oauth/users/icon-uri?consumerUri=http://169.254.169.254/latest/dynamic/instance-identity/document
很好，竟然都能成功响应获取到！
到了这一步，我想应该能说明问题了，于是没再深入测试就简单写了份漏洞报告进行提交，但之后，DoD的项目分类人员把该漏洞定级为中危漏洞，但我认为这绝对是一个严重的高危漏洞。经过一番沟通之后，我向DoD申请了深入测试授权，想继续测试一下这个漏洞到底会有什么最终影响。
深入测试 – 实现对非保密因特网协议路由器网（NIPRnet）的访问和其它敏感信息获取
前期侦察发现 内容来自无奈安全网
首先，我从基本的端口探测开始，发现目标系统开启了21、22、80、443、8080端口，有了这些端口信息之后，我就能测试各种错误信息的返回，通过这些信息判断目标系统中的服务器和网络部署情况，如下对目标系统8080端口发起请求后的响应信息：
其次，我又对gopher文件目录查看协议、DICT字典服务器协议、FTP协议、LDAP轻量级目录访问协议等其它协议作了一遍请求测试。如系统返回了以下不支持LDAP的响应：
copyright 无奈人生