「FreeBuf」利用Jira的邮件服务器连通测试功能发现其CSRF漏洞( 二 )

利用漏洞执行内网主机探测发现XMLHttpRequest对象存在一个readyState属性，它和onreadystatechange事件一起使用， readyState属性包含了0到4之间的不同状态表示值，如下：

本文插图
readyState属性值每次发生变化时，都会调用onreadystatechange事件进行处理，为此我在上述脚本中对XMLHttpRequest的state属性变化加入了alert方法，以便每次状态改变时能有所提醒。目的在于观察请求去连接不同主机和端口号时的状态变化差异。我在上述脚本中加入了以下state状态转化跟踪代码：
当Jira服务端试图去连接一个内网不存在的IP地址时，其XMLHttpRequest请求的state属性会从1到4变化，从而去调用onreadystatechange事件，而只有当连接终止结束后，原始的POST请求才会得到相应的响应，这个过程会花费3秒左右（约3000多毫秒）的时间完成。
PoC最终我写了一段PoC脚本来让Jira服务端以测试邮件服务器连通性的CSRF操作去执行内网主机探测，当然，我把其中的邮件服务器地址设置为了一段内网IP地址，请求端口为110 。运行PoC脚本后可以发现，那些花费3000多毫秒的主机IP是不存在的内网IP地址，只有少量耗时的IP才是存在IP ，如下：

本文插图
为了验证上述发现结果，我又用nmap进行了扫描，果然发现结果相同：

本文插图
在以下我用Wireshark抓包的图片中可以发现， PoC脚本会让Jira服务端去连接指定的IP主机端口，而且，还可以在之前用来进行凭据交换的用户字段中填入任意消息，发送给连接的指定IP主机。

本文插图
总结这是Jira服务端连接邮件服务器功能的一个CSRF漏洞，我利用它可以执行内网主机和端口的扫描探测。可利用场景是，针对Jira管理员构造恶意链接迷惑其点击执行，实现针对其内网的主机端口枚举探测。
*参考来源：medium ， clouds 编译整理，转载请注明来自 FreeBuf.COM
精彩推荐

本文插图