最近的几个Jira漏洞
cnnvd上发布了几个jira的漏洞，都是中低危的：
https://mp.weixin.qq.com/s/cylzALSdMPud5-hXqo4mKA
后来才看到这几个漏洞是Talos发现的：
https://blog.talosintelligence.com/2019/09/vuln-spotlight-atlassian-jira-sept-19.html
大量jira的bug漏洞可以参考这里：
https://jira.atlassian.com/browse/JRASERVER-69858?filter=13085
jira的各种REST API文档：
https://docs.atlassian.com/software/jira/docs/api/REST/7.13.0/
CVE-2019-3403：信息泄露（用户名枚举）
The /rest/api/2/user/picker rest resource in Jira before version 7.13.3, from version 8.0.0 before version 8.0.4, and from version 8.1.0 before version 8.1.1 allows remote attackers to enumerate usernames via an incorrect authorisation check.
触发处在创建问题的时候，选择报告人：
参考：https://jira.atlassian.com/browse/JRASERVER-69787
还有其他地方都可以调用这个rest接口：
提供正常登录凭据情况下
可以通过模糊匹配搜索到相关用户的邮箱，及全名等
未授权情况下
对于没有搜索到到用户：
对于搜索到到用户：
可以进行用户名枚举，不过一般wiki在内网的话，可能就是一个正常的功能。
CVE-2019-11584: XSS
The MigratePriorityScheme resource in Jira before version 8.3.2 allows remote attackers to inject arbitrary HTML or JavaScript via a cross site scripting (XSS) vulnerability in the priority icon url of an issue priority.
CVE-2019-11589: open redirect
The ChangeSharedFilterOwner resource in Jira before version 7.13.6, from version 8.0.0 before version 8.2.3, and from version 8.3.0 before version 8.3.2 allows remote attackers to attack users, in some cases be able to obtain a user’s Cross-site request forgery (CSRF) token, via a open redirect vulnerability.
CVE-2019-8446：信息泄露（用户名枚举）
The /rest/issueNav/1/issueTable resource in Jira before version 8.3.2 allows remote attackers to enumerate usernames via an incorrect authorisation check.
这个REST API是在issue Navigator中查询issue的时候用到的。
一般请求长这样：
未复现成功：
需要提供登录凭据：
参考：
https://jira.atlassian.com/browse/JRASERVER-41100
后来参考talos的漏洞报告：
https://www.talosintelligence.com/vulnerability_reports/TALOS-2019-0839
才知道这里的payload应该这样写：
POST /rest/issueNav/1/issueTable HTTP/1.1
Host: jira.com
User-Agent: Mozilla/5.0
Connection: close
X-Atlassian-token: no-check
Cookie: jira.editor.user.mode=wysiwyg; JSESSIONID=05A9A04CC5F6D76AAB77D054E4FD181C
Content-Type: application/x-www-form-urlencoded
Content-Length: 44
jql=project in projectsLeadByUser("your_username")
如果这个用户名存在，则会响应200，
若不存在则会响应400。
需要具有查询权限的账号。
CVE-2019-8444 存储型XSS
影响版本：
< 7.13.6,
8.0.0 <= version < 8.3.2
参考：https://www.talosintelligence.com/vulnerability_reports/TALOS-2019-0833
两种payload都是向：
POST /rest/api/2/issue/TEST-7/comment HTTP/1.1
Content-Type: application/json
{"body":"!image.png|width=\\\" οnmοuseοver=alert(333);//!"}
第二种：
POST /rest/api/2/issue/TEST-7/comment HTTP/1.1
Content-Type: application/json
{"body":"!image.png|width=http://οnmοuseοver=alert(42);//!"}
[CVE-Pending] DoS through Jira Gadget API
The Gadget API in Atlassian Jira Server and Data Center from version 8.5.0 allows remote attackers to make Jira unresponsive via repeated requests to a certain endpoint in the Gadget API.
This is fixed in versions 8.5.4, 8.6.1 and 8.7.0.
影响范围
version < 8.5.4
8.6.0
参考：
https://jira.atlassian.com/browse/JRASERVER-70808
jira/confluence漏洞复现笔记
当一个jira或者confluence的cve出来的时候，可能当时只有漏洞描述，没有复现步骤，需要自己定位到漏洞点。
我一般是通过
grep -rn "" *
引号里填漏洞所在url，或者类名。
一般会在WEB-INF/web.xml中找到url对应的处理类：
比如我通过官方的描述，知道了CVE-2019-8446的触发点是/rest/issueNav/1/issueTable，那我就搜/rest/issueNav，然后在WEB-INF/web.xml中找到了对应的处理类/过滤器名
然后根据过滤器的名字搜索类
再根据类名定位到具体的文件中，可能是jar包形式，也可能是.class文件形式。
然后再去IDEA中下断点。
还有一个办法就是直接去日志里查调用栈（如果出错的话）
如果只知道一个关键方法的名字，可以先搜它在哪个jar包中
确定jar包之后， 再用反编译工具将jar包反编译你成java代码，再搜索，确定其具体的路径，定位到具体的文件。
