freeBuf
主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

Hack the Pentagon | 利用JIRA漏洞访问美军非保密因特网协议路由器网(NIPRnet)
2018-04-23 15:00:15

*本文中涉及到的相关漏洞已报送厂商并得到修复,本文仅限技术研究与讨论,严禁用于非法用途,否则产生的一切后果自行承担。

163793634-e1459520249258.jpg

本文讲述了作者在参与美国国防部(DoD) Hack the Pentagon 漏洞众测项目中,利用JIRA漏洞CVE-2017-9506构造了SSRF攻击面,实现了对美军非保密因特网协议路由器网(NIPRnet)的访问,并且结合其它漏洞技巧,获取到DoD内网系统的一系列敏感信息。由于测试过程和内容的涉密性,该篇文章仅点到为止,未对过多技术细节和详细场景作出披露,仅当学习分享,还望读者多多包涵。

JIRA 是澳大利亚 Atlassian 公司开发的一款优秀的问题跟踪管理软件工具,可以对各种类型的问题进行跟踪管理,包括缺陷、任务、需求、改进等。JIRA采用J2EE技术,能够跨平台部署,很多开源软件组织和知名公司都在使用JIRA。

从头说来 - 发现DoDJIRA应用网站

在参与美国国防部(DoD)的漏洞众测项目时,我发现其中有两个特别的网站部署了项目跟踪管理工具JIRA,经过初略分析后,我认为不存在可利用的漏洞,所以就直接没继续深挖了。

后来,我从Twitter中发现了一条利用JIRA漏洞实现SSRF攻击的发贴

2018-04-16_104346.png

DYLNlWIW0AEyqaJ.jpg

它的意思是这样的:

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后面加上请求测试的网站!!!!!

测试DoDJIRA应用网站漏洞

仔细阅读了CVE-2017-9506的说明之后,我如获至宝,赶紧转向之前发现的两个国防部网站上,急切想验证一下这种漏洞利用技术的可行性。我先测试了其中一下网站,竟然能正常跳出google页面,那只肯定是存在漏洞的了!

https://website.mil/plugins/servlet/oauth/users/icon-uri?consumerUri=http://google.com

01.png

根据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/

02.png

竟然能看到内部主机名!好吧,那我来试试能否获取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端口发起请求后的响应信息:

03.png

其次,我又对gopher文件目录查看协议、DICT字典服务器协议、FTP协议、LDAP轻量级目录访问协议等其它协议作了一遍请求测试。如系统返回了以下不支持LDAP的响应:

04.png

综合利用发现

在记录下这些信息时,我又想到了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

https://safe.amrdec.army.mil/safe/

https://dots.dodiis.mil/

结合这两个James Kettle提到过的DoD内部网站,用我发现的DoD的两个JIRA网站来向它们发起请求,目的就是测试能否以这种途径实现对James Kettle提到的两个DoD内部网站的访问。最终,我用其中一个JIRA网站向James Kettle提到的两个DoD内部网站发起请求后,其中一个显示请求超时:

05.png

另一个返回了US Goverment(USG)的政府警告信息,如下:

06.png

在此测试过程中,我还发现了其它的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、数据库版本、应用插件、操作系统架构和其它系统:

07.png

发生堆栈错误时,仍然可以继续对目标网站进行深入的信息获取利用,比如,我发现有时候目标网站会指向其它Altassian实例,如某次测试中,我发现目标站点某子域名中部署有Altassian的confluence实例,经过测试证明,这些实例同样会受到信息泄露漏洞的影响。

总结梳理

本文中,作者描述了参与美国国防部漏洞众测项目时发现的JIRA漏洞,并概要性地介绍了整个漏洞利用的测试过程,我们一起来梳理下:

1 其中两个部署有JIRA实例的DoD网站存在授权插件漏洞CVE-2017-9506,攻击者利用该漏洞可获取目标网站系统内部资源信息,并能形成SSRF攻击面;

2 结合CVE-2017-9506利用方法,我从存在漏洞的DoD网站中获取到了JIRA实例 ID、私有IP地址、一系列错误响应等信息;

3 综合PortSwigger首席研究员James Kettle分享提到的两个DoD网站,利用CVE-2017-9506请求方法,发现请求的DoD网站返回了有效USG(政府警告)信息;

4 在第3步过程中,我通过发现的某个内部web服务,结合CVE-2017-9506利用方法,实现了对DoD非保密协议路由网(NIPRnet)的访问;

5 结合CVE-2017-9506利用方法,在存在漏洞的DoD网站上复现了SSRF攻击,实现了内部IP和网络服务枚举,以及后续堆栈错误时的敏感信息获取。

*参考来源:alyssa,FreeBuf小编clouds编译,转载请注明来自FreeBuf.COM

# 漏洞 # JIRA
本文为 独立观点,未经允许不得转载,授权请联系FreeBuf客服小蜜蜂,微信:freebee2022
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
相关推荐
  • 0 文章数
  • 0 关注者