CVE-2022-0540 Jira 身份驗證繞過漏洞分析

作者：xxhzz@星闌科技PortalLab
原文鏈接：https://mp.weixin.qq.com/s/fEhzBTl3SVVE072ubwi6EA

前言

在上篇分析CVE-2022-26135Atlassian Jira Mobile Plugin SSRF漏洞之后，發現在此之前，jira也曾爆出過身份驗證繞過漏洞，CVE編號為cve-2022-0540。趁著環境還熱乎，對其產生的原理和代碼進行一波分析和學習。

漏洞描述

Atlassian Jira是澳大利亞Atlassian公司的一套缺陷跟蹤管理系統。該系統主要用于對工作中各類問題、缺陷進行跟蹤管理。攻擊者可利用此漏洞向目標系統發送特制的HTTP請求，以使用受影響的配置繞過 WebWork 操作中的身份驗證和授權要求。

利用范圍

Jira

Jira 所有版本 < 8.13.18
Jira 8.14.x、8.15.x、8.16.x、8.17.x、8.18.x、8.19.x
Jira 8.20.x < 8.20.6
Jira 8.21.x

Jira Service Management

Jira Service Management 所有版本 < 4.13.18
Jira Service Management 4.14.x、4.15.x、4.16.x、4.17.x、4.18.x、4.19.x
Jira Service Management 4.20.x < 4.20.6
Jira Service Management 4.21.x

漏洞分析

環境搭建

本次環境使用docker搭建 Dockerfile

FROM atlassian/jira-software:8.13.17
USER root
COPY "atlassian-agent.jar" /opt/atlassian/jira/
RUN echo 'export CATALINA_OPTS="-javaagent:/opt/atlassian/jira/atlassian-agent.jar  -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005 ${CATALINA_OPTS}"' >> /opt/atlassian/jira/bin/setenv.sh

5005為idea debug端口；atlassian-agent.jar項目地址：https://github.com/hgqapp/atlassian-agent，使用maven編譯為jar文件即可。

后續創建容器根據提示配置。

調試源碼：將以下三個文件夾設置為Libraries。

\atlassian-jira-software-8.13.17-standalone\lib
\atlassian-jira-software-8.13.17-standalone\atlassian-jira\WEB-INF\classes
\atlassian-jira-software-8.13.17-standalone\atlassian-jira\WEB-INF\lib

前置知識

在漏洞分析之前，先簡單了解一下Jira相關的背景知識。

WebWork

Jira使用MVC框架WebWork來處理用戶發起的WEB請求。每個請求都是使用WebWork action來處理，在其中又使用了其他的utility and Manager classes來完成一個任務。作為響應返回給客戶端的HTML大部分都是View層的JSP生成的。URL中的”.jspa”后綴標識其后端對應的是一個JSP文件。

Seraph

Seraph是一個開源認證框架，主要由Atlassian開發和維護。Jira、Confluence的登錄認證是都由Seraph來負責的。Seraph是通過Servlet的Filter實現的。Seraph的功能只是用來在給定一個Web請求的情況下，將該請求與特定用戶相關聯。

動態分析

通過前置知識可以了解到Seraph是一個開源認證框架，也是jira核心身份驗證機制。Seraph是通過Servlet和Filter實現的。

查看Filter，發現com.atlassian.jira.security.JiraSecurityFilter.class

在doFilter中調用父方法super.doFilter

com.atlassian.seaph.filter.SecurityFilter#doFilter

這里處于atlassian-seaph-4.0.4.jar中filter也就是seraph過濾器，它會根據請求用戶權限進行判斷，進一步確定所需要的角色，確定是否需要認證。

持續跟進，發現會通過循環會出現三種Service

JiraPathService

JiraPathService是處理：如果請求的 servlet 路徑以 /secure/admin/ 開頭，那其角色權限必須是admin（管理員權限）。

WebworkService

WebworkService則是在actions.xml文件中獲取角色所需要的webwork配置。

經過調試，會多次進入getRequiredRoles函數，其中獲取URl的方式為getRequestURL。

繼續跟進發現在通過getRequestURL方式提取請求URL后，會通過提取最后一個/后面的接口產生一個targetURL，這里傳入的是/secure/InsightPluginShowGeneralConfiguration.jspa，而targetURL為/InsightPluginShowGeneralConfiguration.jspa

JiraSeraphSecurityService

繼續往下就是第三個服務JiraSeraphSecurityService，作用是在所有插件的 atlassian-plugin.xml 文件中獲取角色所需的 webwork 操作配置。

在跟進JiraSeraphSecurityService時，發現會調用WebworkPluginSecurityServiceHelper.getRequiredRoles，和WebworkService.getRequiredRoles代碼是相同的。

接口權限必須是admin。

在com.atlassian.jira.web.dispatcher.JiraWebworkActionDispatche中會對jspa進行處理。

service函數會從請求中獲取Action名稱，后續使用/和。jspa切割字符來獲取ActionName。

在webwork.dispatcher.GenericDispatcher#executeAction函數，會對Action進行檢查。

系列Action工廠。

如上分析，其實目前已經知道在Filter中提取URL的方法是getRequestURL，在Servlet中使用getServletPatch。

在URL加入上“;”，傳入/secure/InsightPluginShowGeneralConfiguration.jspa;那么在Filter中無法找到InsightPluginShowGeneralConfiguration.jspa；對應的Action，后續進入Servlrt處理，而getServletPath會將;刪除，這樣也就繞過了Filter層的認證。