## 【漏洞分析】Jira未授权SSRF漏洞(CVE-2019-8451)
原创: 奇安信 CERT [奇安信 CERT](javascript:void(0);) *昨天*
本文作者:77 @奇安信A-TEAM
漏洞背景
前一段时间Atlassian的bug跟踪里公开了一个Jira未授权SSRF漏洞。看一下官方的描述:
Jira的/plugins/servlet/gadgets/makeRequest资源存在SSRF漏洞,原因在于JiraWhitelist这个类的逻辑缺陷,成功利用此漏洞的远程攻击者可以以Jira服务端的身份访问内网资源。经分析,此漏洞无需任何凭据即可触发。
![](https://images.seebug.org/1569299440098-w331s)
### 影响范围
< 8.4.0
官方说在7.6版本中引入,在8.4.0中修复。但是我经过测试发现至少6.4.14版本也受此漏洞影响。而目前多数Jira是在8.4.0版本以下的。
修复建议
升级到8.4.0及以上版本。
### 漏洞分析
两个关键信息点:
- 漏洞点在/plugins/servlet/gadgets/makeRequest
- 原因在于JiraWhitelist这个类的逻辑缺陷
首先上直接去访问这个url,然而告诉我404:
![](https://images.seebug.org/1569299455872-w331s)
有点绝望,都404了,还看啥!然后开始按照以往Jira/Confluence的漏洞搜索方法,
```
grep -rn "makeRequest" *
```
![](https://images.seebug.org/1569299465554-w331s)
然而通过这一点并没有搜出来直接到漏洞点的地方。换另一条思路,搜索:`JiraWhitelist`,
![](https://images.seebug.org/1569299508614-w331s)
找到了这个类是在atlassian-jira/WEB-INF/classes目录下,于是在IDEA中直接将这个目录加到Library中(否则调试无法进入),然后在其可疑方法allows下断点:
![](https://images.seebug.org/1569299518362-w331s)
发起一个`/plugins/servlet/gadgets/makeRequest`的请求,但是这个时候没能直接触发到断点。后来找到了一个跟这个比较像的url:`/plugins/servlet/gadgets/dashboard-diagnostics`深入跟进了一下,发现原来是所有`/plugins/servlet`开头的url会交给某一些类处理,而这是在web.xml中配置的:
![](https://images.seebug.org/1569299528883-w331s)
![](https://images.seebug.org/1569299540494-w331s)这里url中的`/plugins/servlet`匹配到了servlet-module-container-servlet对应的servlet为:`com.atlassian.jira.plugin.servlet.ServletModuleContainerServlet`。然后后面通过`request.getPathInfo()`来获取url后面的内容。参考:https://blog.csdn.net/turkeyzhou/article/details/3270289
![](https://images.seebug.org/1569299558952-w331s)
获取到之后,去一个Map里查找:
![](https://images.seebug.org/1569299569243-w331s)
找到这个pathInfo对应的Servlet descriptor
![](https://images.seebug.org/1569299578883-w331s)
然后根据这个descriptor找到具体的Servlet类:
![](https://images.seebug.org/1569299588520-w331s)
这里显示已经找到了:
![](https://images.seebug.org/1569299970527-w331s)
这个Servlet为`com.atlassian.gadgets.shindig.servlet.XsrfMakeRequestServlet`。
至此终于定位到了处理具体请求的地方。
跟进这个类atlassian-jira/WEB-INF/atlassian-bundled-plugins/atlassian-gadgets-opensocial-plugin-4.3.9.jar!/com/atlassian/gadgets/shindig/servlet/XsrfMakeRequestServlet的doGet方法。
可以看到这里对请求中的请求头`X-Atlassian-Token: no-check`做了判断,如果请求中没有这个请求头,则直接响应404了。
![](https://images.seebug.org/1569299918685-w331s)
注:这个请求头是官方提供的一种绕过Jira自身CSRF防御的方式,用于告诉Jira不对此请求进行CSRF防御,方便在自动化脚本中使用。具体介绍可以参考:https://developer.atlassian.com/server/jira/platform/form-token-handling/
到这里就解释了为什么直接访问这个url会响应404了。
带上这个请求头,继续调试。跟进其父类即`org.apache.shindig.gadgets.servlet.MakeRequestServlet`的`doGet`方法。由于这个包我没有在Jira提供的jar包中找到,最后去这里:https://repo1.maven.org/maven2/org/apache/shindig/shindig-gadgets/2.5.2/shindig-gadgets-2.5.2.jar 找了一个jar包作为Library供IDEA调试。最后跟进到了atlassian-jira/WEB-INF/classes/com/atlassian/jira/dashboard/JiraWhitelist#allows方法中,对请求中的url参数进行判断。如果请求中的url满足以Jira服务的canonicalBaseUrl开头(比如我的Jira是http://cqq.com:8091),
![](https://images.seebug.org/1569299889036-w331s)
则认为这个url符合白名单的规则:这里应该就是漏洞描述中`atlassian-jira/WEB-INF/classes/com/atlassian/jira/dashboard/JiraWhitelist#allows`方法的逻辑缺陷了。
符合白名单的规则就接着使用`atlassian-jira-6.4.14-standalone/atlassian-jira/WEB-INF/lib/httpclient-4.3.6.jar!/org/apache/http/client/utils/URIUtils`这个工具类将url中的协议名、Host名、端口等提取出来
![](https://images.seebug.org/1569299870666-w331s)
![](https://images.seebug.org/1569299858840-w331s)
![](https://images.seebug.org/1569299847740-w331s)
通过跟踪代码,发现它只判断了url是否以 `<jira服务的协议://ip:port>` 开头,所以这个poc中能进行SSRF请求的协议只能是HTTP(s)。
### 漏洞修复
在8.4.0版本中,使用这里使用了`java.net.URI#getHost,getPort`等方法获取主机名和端口号,与Jira服务的协议、主机名、端口进行逐个对比。若不符合,返回False。 ![](https://images.seebug.org/1569299827503-w331s)
### Demo
![](https://images.seebug.org/1569299808465-w331s)
### 参考
- https://nvd.nist.gov/vuln/detail/CVE-2019-8451
- https://jira.atlassian.com/browse/JRASERVER-69793
Unavailable Comments