利用Jira进行主机扫描

去年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头进行验证，以符合同源策略。

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

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

漏洞

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

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

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

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

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

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

受害者的浏览器（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值的含义：

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

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

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

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

PoC

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

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

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

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