利用Jira进行主机扫描

iso60001  246天前

22.png

去年10月,我针对Jira软件(版本8.4.1)进行了深度研究,希望能发现新的漏洞。最初,我得到了一些CSRF,并发现可利用其指示Jira服务器对我选择的其他主机发起连接。这个CSRF漏洞(CVE-2019-20099)影响Atlassian Jira Server和Data Center 8.7.0之前的版本,并且攻击者可以利用该漏洞通过受影响的Jira服务器对内部网络进行扫描。

这篇文章详细介绍了这个漏洞的发现以及相关PoC的信息。

跨站点请求伪造

CSRF攻击可通过借用合法登录用户的浏览器所存储的cookie来攻击网站,借用合法用户的身份在他们不知情的情况下执行一些恶意操作。

为了防御这种攻击,Jira服务器在HttpOnly cookie中设置了CSRF令牌。对于任何执行更改状态的操作的,服务器都会先检查令牌是否正确。这使得攻击者很难利用用户cookie来进行恶意操作。此外,还会根据服务器域和端口号对Referer头进行验证,以符合同源策略。

33.png

上图是一个POST请求的例子,它主要将issue类型设置为bug。其中CSRF cookie被命名为Atlassian.xsrf.token,CSRF相关参数被命名为atl_token。此外Referer头的信息被用来和Jira服务的IP和端口进行对比。

通过测试各种请求时,我发现Jira并不总是会验证以上这些值。

漏洞

若在Jira中设置一个对外的POP3邮件服务器,需要系统管理员提交一个包含邮件服务器详细信息的表单,比如服务器名、主机地址、端口号、用户凭证等等。而在这个表单的底部有两个按钮,一个用于请求设置新的邮件服务器,另一个用于测试邮件服务器的连接。

44.png

测试连接的按钮会让Jira服务器尝试连接到表单指定的邮件服务器。该连接数据主要由与POP3邮件服务器进行的凭证交换组成。

当查看这个请求的流量时,发现既没有进行Referer的同源检查,也没有进行CSRF参数验证检查。此时,执行CSRF攻击是没有任何限制的。

为了进行测试,我设置了一个带有POP3邮件服务器的主机来接收来自Jira服务器的验证连接,同时在服务器上托管一个CSRF攻击网页。主体思想是模拟管理用户单击恶意链接,而该链接将利用用户的session ID cookie,向Jira服务器发出请求,让其向我所选择的主机和端口发送邮件服务器测试连接。

以下是我在CSRF网页中使用的脚本:

55.png

下图是运行上述脚本时所捕获的Wireshark流量。

66.png

受害者的浏览器(172.16.68.1)向Jira服务器(172.16.68.248)发送了一个POST请求(172.16.68.248)。很快,Jira发起一个POP3请求连接到指定的主机和端口(172.16.68.229:110)。由于验证失败,无法进行操作,连接终止。

总而言之,该脚本能够通过CSRF漏洞驱使Jira服务器向我选择的主机和端口发起请求。

POP3连接验证请求需要在POST参数中加入用户名和密码。而在成功握手之后,这些参数会被发送到指定的主机和端口。

主机扫描

xmlHttpRequest对象有一个readyState属性,可以与onreadystatechange事件处理程序一起使用。readyState属性会保存一个0到4之间的值,表示请求的状态。下表摘自w3schools.com网站,其中详细描述了readyState值的含义:

77.png

onreadystatechange事件处理程序在readyState值每次更改时都会被调用。因此我修改了Web页面脚本,以在每次xmlHttpRequest更改状态时发出警告。我想知道当我请求连接到不同的主机和端口时,状态转换是否有所不同。

我在脚本中添加了以下代码来跟踪状态转换:

88.png

当Jira服务器试图连接到不存在的IP地址时,请求中状态1到状态4的转换大约需要3秒。

服务器只有在终止了与指定主机的连接之后才会返回对POST请求的响应。因此,如果扫描的IP地址不存在,则连接超时和终止大约需要3秒。

PoC

我最后创建了一个PoC扫描脚本,利用Jira服务器对内网进行扫描。该脚本主要通过CSRF向Jira服务器发出几个请求,以验证一定IP范围内邮件服务器的存活(PoC定义了端口110,但可以将其更改为任何其他端口)。完成每个请求所需的时间将被发布到Web页面的文本区域。

在实施攻击后,Web页面中的文本区域将出现如下结果。

99.png

为了验证结果,我还使用了Nmap进行扫描。

100.png

Nmap扫描的结果与PoC扫描的结果一致。

而捕获的Wireshark流量也显示,JIRA向某个主机和端口发起了POP连接,并显示了如何使用username字段向主机发送消息。

结论

Jira的POP3测试连接组件中发现的CSRF漏洞通过CSRF脚本从Jira服务器执行主机发现扫描,这驱使Jira为一系列IP地址启动测试连接。计算完成每个请求所需的时间,以确定在相应的IP地址是否存在主机。结果证明这种方法得到的结果与来自Nmap的扫描的结果一致。

该漏洞已经通过Atlassian公司的漏洞披露程序进行了报告,并已在Atlassian Jira Server和Data Center version的8.7.0版本中得到了解决。

关于该漏洞的进一步信息,请参阅Tenable发布的研究咨询,其中列出了漏洞时间表。

本文由白帽汇整理并翻译,不代表白帽汇任何观点和立场
来源:https://securityaffairs.co/wordpress/98149/hacking/themerex-plugin-zero-day.html

最新评论

昵称
邮箱
提交评论