Jira文件读取分析

date
Aug 10, 2021
slug
jira-read-file-analyse
status
Published
tags
Java安全
安全研究
summary
Jira 最近的几个漏洞，让我学着从补丁里面分析
type
Post

CVE-2019-8442

官方的描述：
The CachingResourceDownloadRewriteRule class in Jira before version 7.13.4, and 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 access files in the Jira webroot under the META-INF directory via a lax path access check.
问题是出在CachingResourceDownloadRewriteRule这个类上，通过
安装v8.1.0进行调试，Jira是使用Servlet编写的，直接在Tomcat里面的catalina.bat加上调试语句即可调试
观察web.xml，可以观察到所有路径都会经过UrlRewriteFilter的处理
notion image
跟进UrlRewriteFilter 的doFilter ，内容会经过urlRewriter.processRequest 的处理，然后在UrlRewriter 下处理URL的重写规则
notion image
继续跟进到doRuleProcessing 函数，此时这里的rule是个列表内容，内容是从urlrewrite.xml 读取出来的，也是就是url重写的规则
notion image
一个是通过CachingResourceDownloadRewriteRule 去处理，另外一个是处理issues 开头的path
notion image
也就是从这里到达触发漏洞类的matches函数，最终通过request.getRequestDispatcher触发文件读取，参数finalToUrl是传入的path内容（也就是构造poc的地方）
notion image
前提是需要满足这个类规则定好的正则
private static final Pattern NON_WEB_INF_RESOURCES_URI_PATTERN = Pattern.compile("^/s/(.*)/_/((?i)(?!WEB-INF).*)");
这个正则并没有拦截META-INF目录下的内容，所以网上流传的poc都是读取该目录下的内容
GET /s/anthing/_/META-INF/maven/com.atlassian.jira/atlassian-jira-webapp/pom.xml HTTP/1.1
Host: 10.211.55.11:8080
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
Connection: close
后面版本的正则加上了对该目录的限制，但是还是不安全的
Pattern.compile("^/s/(.*)/_/((?i)(?!WEB-INF)(?!META-INF).*)")
 

CVE-2020-29453

notion image
同样也是这个类出现了问题，对比v8.13.2和v8.13.3版本，多出了decodeURLSafely函数进行处理
notion image
说明这个漏洞点是在编码的问题上，这个点应该就是上一个CVE的绕过了
这里又涉及到request.getRequestDispatcher 的一些小知识点了
这个函数也是可以触发文件读取的漏洞的，只要是getRequestDispatcher 后面的内容可控的话，而且是非jsp结尾的文件的话，但是危害有点鸡肋，这个如果使用/ 根目录的话代表的是这个web项目的根目录，而且这个东西不能跳出根目录，所以读取的内容会比较鸡肋
notion image
而且这个函数支持../ 这样的操作，也能读取内容
notion image
如果是URL编码过后的内容会出现两种情况，如果是在路径上的 ../ 进行编码的话，会返回500的错误
notion image
如果是非../ 里面的内容进行编码的话，也是可以触发文件读取的
notion image
为什么会出现上述问题，从Tomcat层面分析，跟进之后可以看出tomcat在org.apache.catalina.core.ApplicationContext#getRequestDispatcher这个函数处理的时候，会经过两次normalize的处理
nomalize对于url编码的字符并不处理
nomalize对于url编码的字符并不处理
在第二次normalize前会经过一轮urldecode，然后进行一次对比，如果不相同的内容会导致抛出异常，这也是为什么会出现500报错的原因
所以到这里可以考虑../ 或者编码进行绕过，但是第一种的话不可行，因为代码中存在normalize函数，会将../ 此类字符消去，这种方法不太可行，从补丁的情况来看，这个应该是使用编码的方法进行漏洞的触发
notion image
也就是说可以使用编码方式去触发漏洞，因为在漏洞触发之前编码的内容都没有改变
notion image
GET /s/anthing/_/%4dETA-INF/maven/com.atlassian.jira/atlassian-jira-webapp/pom.xml HTTP/1.1
Host: 10.211.55.11:8080
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
Connection: close
notion image
 

CVE-2021-26086

CNVD是这样描述的
notion image
同样也是CachingResourceDownloadRewriteRule 这个类出了问题，就是对上一版CVE的绕过，diff一下修复版本
notion image
在上一个版本的正则基础上添加了新的正则，分成了两步去匹配内容，并且处理的流程上也发生了变化，从之前的URI request normalize → decodeURLSafely → Pattern Match到当前版本decodeURLSafely → URI request normalize → Pattern Match
观察之前处理URI的流程，URI request normalize → decodeURLSafely → Pattern Match
这个流程是有问题的，因为normalize之前的内容如果是经过URL编码的内容，并不会被处理掉，所以可以利用这个点，在decodeURLSafely之后去绕过正则，因为正则这几个版本下来只是限制/s/xxx/_/WEB-INF/xxx类似的格式，并没有限制像/s/xxx/_/yyyyy/WEB-INF/xxx 这样的格式，所以可以这样处理一下之前的payload
GET /s/anthing/_/xxxx/%2e%2e/META-INF/maven/com.atlassian.jira/atlassian-jira-webapp/pom.xml HTTP/1.1
Host: 10.211.55.11:8080
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
Connection: close
这里也可以使用; 进行一个绕过，这个分号在第一次URI normalize的时候并没有被处理掉，注意这里的normalize跟Tomcat里面的normalize处理是不一样，所以..; 这一块并没有被处理掉，导致后续进入到getRequestDispatcher中
notion image
GET /s/anthing/_/xxxx/..;/META-INF/maven/com.atlassian.jira/atlassian-jira-webapp/pom.xml HTTP/1.1
Host: 10.211.55.11:8080
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
Connection: close
修复的版本就不允许那几个关键字的前面再出现除了数字字母其他内容了，无法在前面构造类似../ 的字符了
 

© 4me 2021 - 2024