快捷搜索:  网络  渗透  后门  CVE  扫描  木马  黑客  as

Hack the Pentagon | 行使JIRA漏洞走访美军非失密因特网协定路由器网(NIPRnet)

163793634-e1459520249258.jpg

本文讲述了作者在参与美国国防部(DoD) Hack the Pentagon 漏洞众测项目中,行使JIRA漏洞CVE-2017-9506组织了SSRF攻击面,完成了对美军非失密因特网协定路由器网(NIPRnet)的走访,并且结合别的漏洞技巧,获取到DoD内网体系的一系列敏感信息。由于测试过程以及内容的涉密性,该篇文章仅点到为止,未对过量手艺细节以及具体场景作出表露,仅当学习分享,还望读者多多原谅。

JIRA 是澳大利亚 Atlassian 公司开发的一款优秀的问题跟踪治理软件工具,可以对种种类型的问题进行跟踪治理,包括缺点、义务、需求、改进等。JIRA采用J2EE手艺,能够跨平台部署,很多开源软件构造以及知名公司都在使用JIRA。

从头说来 – 发现DoD的JIRA应用网站

在参与美国国防部(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后面加上要求测试的网站!!!!!

测试DoD的JIRA应用网站漏洞

子细涉猎了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)的走访以及别的敏感信息获取

前期侦查发现

起首,我从基本的端口探测最先,发现目标体系开启了2一、22、80、44三、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方式进行测试时发现,WEB黑客,之条件示超时、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编译,

您可能还会对下面的文章感兴趣: