JIRA 未授权漏洞实战：从用户枚举到 SSRF 的十大 CVE 攻击链

导语：Atlassian JIRA 是全球企业部署最广的项目管理工具之一，同时也是 Bug Bounty（漏洞悬赏）历史上最高产的靶子。2019 到 2020 年间，研究员们接连挖出十余个未授权可利用的高危 CVE。本文把这十条攻击链串起来，看攻击者如何从一个公开端点一路打到远程代码执行（RCE）。

一、JIRA 为什么是攻击者的”金矿”

JIRA 的 Web 入口遍布几十个 servlet 和 REST API，其中相当一部分没有强校验：只要知道 URL，就能拿到用户列表、项目结构、内部配置。配合 Bug Bar（漏洞悬赏评级标准）对未授权信息泄露的高权重，这类漏洞几乎成了入门 Bug Bounty 的”必修课”。攻击面集中在四类：信息泄露、用户枚举、SSRF（服务端请求伪造）、模板注入。

二、十大 CVE 攻击链详解

2.1 信息泄露类（CVE-2020-14179 / CVE-2019-8449 / CVE-2019-8442）

CVE-2020-14179：直接访问 /secure/QueryComponent!Default.jspa，未授权就能看到 JQL（内部查询语言）面板的 custom fields、custom SLA（服务等级协议）、配置项。这些字段往往包含内部资产命名规范，是后续社工和口令猜测的素材。

CVE-2019-8449：/rest/api/latest/groupuserpicker?query=1&maxResults=50000 接口允许未授权拉取最多 5 万条用户信息，包含 displayName、email、avatar。一次请求拿到整张花名册，是最经典的”开局裸奔”。

CVE-2019-8442：/s//_/META-INF/maven/com.atlassian.jira/atlassian-jira-webapp/pom.xml 利用路径规范化缺陷，把 当成 prefix 匹配后，照样返回内部 pom.xml，泄露精确版本号，方便对接已知 PoC（概念验证利用代码）。

2.2 用户与项目枚举（CVE-2020-14181 / CVE-2020-14178 / CVE-2019-3403）

CVE-2020-14181：/secure/ViewUserHover.jspa?username= 根据用户名是否存在返回不同长度的响应，攻击者拿字典批量跑，命中率极高。

CVE-2019-3403：/rest/api/2/user/picker?query= 接口在用户存在与不存在时返回的 JSON 结构不同，是 REST 风格的枚举点。

CVE-2020-14178：/browse. 在项目 Key 合法时返回 200，非法时返回 404。更危险的是，JIRA 配置不当时，未授权用户能直接浏览未公开项目的 ticket（工单）内容。

2.3 XSS 与 SSTI（CVE-2019-3402 / CVE-2019-11581）

CVE-2019-3402：/secure/ConfigurePortalPages!default.jspa 的 searchOwnerUserName 参数未做输出编码，直接拼进 HTML，构造 alert(1) 即反射型 XSS（跨站脚本攻击）。管理员访问后被窃取会话。

CVE-2019-11581：/secure/ContactAdministrators!default.jspa 提交的 subject 参数被 Velocity 模板引擎解析，攻击者注入 ${7*7} 这样的 OGNL（对象图导航语言）表达式会得到 49。模板注入在 JIRA 上直接对应 RCE 风险。

2.4 路径遍历与 SSRF（CVE-2019-3396 / CVE-2019-8451）

CVE-2019-3396：通过 Confluence/JIRA 的 attachment（附件）下载接口配合特殊编码的路径，能跳出 webroot 读取服务器任意文件，属于经典的”穿越附件”类路径遍历。

CVE-2019-8451：/plugins/servlet/gadgets/makeRequest?url=https://attacker:1337@example.com，这是 JIRA 的 Gadget Proxy（代理小工具）功能，本意是给 Jira Gadget 渲染跨域内容，但服务端会主动 fetch 攻击者构造的 URL，绕过 @ 之前的认证信息直接打到内网。SSRF 通常用于探测云元数据（如 169.254.169.254）、打内网 Redis、甚至配合 Jira 的 gadget 渲染链打到 XSS——这篇 Medium 文章的标题《How I converted SSRF to XSS in JIRA》讲的就是这条利用路径。

三、自动化与战果

把上面十条 CVE 写成 Nuclei（一个开源漏洞扫描工具）workflow，几分钟就能扫完上千个 JIRA 实例。一条命令搞定：

nuclei -l jira_targets.txt -w nuclei-templates/workflows/jira-workflow.yaml -o findings.txt

HackerOne 报告 #632808（Path Traversal）与 #1003980（User Enumeration）只是冰山一角——大部分企业 JIRA 在未打补丁的窗口期被批量枚举出 admin 账号，再被撞库登入。需要注意的是，JIRA 8.x 之后 REST 路由从 /rest/api/2/ 部分迁移到 /rest/api/latest/，老 payload 直接打新版会 404，红队评估时要先 fingerprint（指纹识别）版本。

四、防御方案

升级到对应修复版本：CVE-2020-14179/14178/14181 修复于 8.5.5 / 8.8.1 / 8.11.1；CVE-2019-3396 修复于 8.4.0；CVE-2019-8451 修复于 8.4.0；CVE-2019-11581 修复于 7.13.6 / 8.4.0；CVE-2019-8442 / 8449 / 3403 修复于 8.4.0。无法升级时，在反向代理（WAF）层面封禁 /s/*/_/META-INF/、/rest/api/latest/groupuserpicker、/plugins/servlet/gadgets/makeRequest、/secure/ConfigurePortalPages!default.jspa、/secure/ContactAdministrators!default.jspa 这些端点的未授权访问。同时开启 JIRA 的”匿名访问”白名单，把 custom field、SLA（服务等级协议）、项目浏览全部收紧到认证用户。

五、总结

JIRA 的十大未授权 CVE 共同指向一个事实：Web 应用只要对外开放，就别假设攻击者不会先翻一翻 REST API（应用程序接口）和 servlet 路由。Red Team（红队）做外部侦察时，JIRA、Confluence、Grafana 这”老三家”永远是优先目标；Blue Team（蓝队）则要把未授权访问面常态化扫描写进日常基线，别等漏洞被挂在 HackerOne 上才动手。

原文出处：https://github.com/harsh-bothra/learn365/blob/master/days/day4.md

实战参考：

• Nuclei JIRA workflow：https://github.com/projectdiscovery/nuclei-templates/blob/master/workflows/jira-workflow.yaml
• SSRF 转 XSS 利用链：https://medium.com/@D0rkerDevil/how-i-convert-ssrf-to-xss-in-a-ssrf-vulnerable-jira-e9f37ad5b158
• HackerOne 报告：https://hackerone.com/reports/632808、https://hackerone.com/reports/1003980