声明
出品|先知社区(ID:alter99;
以下内容;来自先知社区的alter99作者原创;由于传播;利用此文所提供的信息而造成的任何直接或间接的后果和损失;均由使用者本人负责;长白山攻防实验室以及文章作者不承担任何责任。
什么是Shiro
blog.csdnimg.cn/img_convert/4bfeca413896e9fbe5889b69e78f403d.png)
Apache Shiro is a powerful and easy-to-use Java security Framework that performs authenticat-ion(身份验证), authorization(授权), crypto-graphy(加密), and session management(会话管理). With Shiro’s easy-to-understand API, you can quickly and easily secure any application – from the smallest mobile applications to the largest web and enterprise applications.
相关CVE
根据官方网站上的漏洞通报;Shiro 在历史上共通报了 11 个 CVE;以及最新披露的CVE;;其中包含认证绕过、反序列化等漏洞类型;接下来我们来依次学习。
CVE-2010-3863
漏洞信息
**漏洞编号;**CVE-2010-3863 / CNVD-2010-2715
**影响版本;**shiro < 1.1.0 和JSecurity 0.9.x
**漏洞描述;**Shiro进行权限验证前未进行路径标准化;导致使用时可能绕过权限校验
**漏洞补丁;**Commit
漏洞分析
先分析一下Shiro身份验证的流程;Shiro使用org.apache.shiro.web.filter.mgt.PathMatchingFilterChainResolver#getChain 方法获取和调用要执行的 Filter
逻辑如下;
在getPathWithinApplication()方法中调用 WebUtils.getPathWithinApp-lication()方法;用来获取请求路径。其中getContextPath(request)方法获取 Context 路径
getRequestUri(request) 方法获取URI 的值;并调用 decodeAndCleanUriString() 处理。
在decodeAndCleanUriString()中对
; 进行了截取。
此时contextPath值为/samples_web_war;requestUri值为/samples_web_war/login.jsp
然后判断requestUri是否以contextPath开始;是的话将其替换为/
处理之后的请求URL将会使用AntPathMat-cher#doMatch进行权限验证。此时发现;Shiro中对URI并没有进行路径的标准化处理;这样当URI中存在特殊字符时;就存在绕过风险
复现
[urls] /login.jsp = authc /logout = logout /account/** = authc /remoting.jsp = authc, perms[;audit:list;] /** = anon
有了上面的配置;直接访问;/remoting.jsp;会因为没有权限而跳转至登陆界面。
当访问 /./remoting.jsp;由于其不能与配置文件匹配;导致进入了 /** 的匹配范围;导致可以越权访问
漏洞修复
Shiro 在 Commit 更新中添加了标准化路径函数。
对 /、//、/./、/…/ 等进行了处理。
CVE-2014-0074
漏洞信息
漏洞编号;
CVE-2014-0074/CNVD-2014-03861/SHIRO-460
**影响版本;**shiro 1.x<1.2.3
**漏洞描述;**当程序使用LDAP服务器并启用非身份验证绑定时;远程攻击者可借助空的用户名或密码利用该漏洞绕过身份验证。
**漏洞补丁;**Commit
漏洞分析
当使用了未经身份验证绑定的LDAP服务器时;允许远程攻击者通过空用户名或空密码绕过身份验证。
漏洞修复
Shiro 在 f988846 中针对此漏洞进行了修复
CVE-2016-4437
漏洞信息
漏洞编号;
CVE-2016-4437/CNVD-2016-03869/S
HIRO-550
**影响版本;**shiro 1.x < 1.2.5
**漏洞描述;**利用硬编码的密钥构造rememberMe参数;进行反序列化攻击
**漏洞补丁;**Commit
参考; Shiro 550反序列化漏洞分析
漏洞分析
关键代码处于
AbstractRememberMeManager#getRememberedPrincipals 方法中;参数是用户的身份Context信息;如下图
这个方法主要是把SubjectContext转化成Princi-palCollection。该方法调用了getRemembered-SerializedIdentity和convertBytesToPrincipals方法。
其中CookieRememberMeManager 的getRemem-beredSerializedIdentity的实现是获取Cookie并Base64解码
将解码后的byte数组传入convertBytesToPrincipals中进行;decrypt和deserialize。decrypt是使用AesCipherService进行解密。
deserialize调用deserialize()方法反序列化解密后的数据。
反序列化得到的PrincipalCollection会被set到SubjectContext 。
解密的调用栈入下图所示
此时就可以想象;如果我们有了加密密钥;使用密钥加密一个恶意序列化的payload;将rememberMe的值替换成base64后的payload传入服务器;那这样就可以触发漏洞了。关键点在于;我们如何获取加密密钥?
这就要提到AbstractRememberMeManager类;它是RememberMeManager 接口的实现。类中有几个关键变量;
DEFAULT_CIPHER_KEY_BYTES;对称密钥;使用Base64加密之后直接存在代码中
serializer;Shiro 提供的序列化器
cipherService;用来对数据加解密的类
漏洞利用
编写一个poc
package com.alter.Shiro;
import com.alter.Deserialize.CommonsCollections6;
import org.apache.shiro.crypto.AesCipherService;
import org.apache.shiro.util.ByteSource;
public class test {
public static void main(String[] args) throws Exception {
byte[] payloads = new CommonsCollections6().getPayload(;/System/Applications/Calculator.app/Contents/MacOS/Calculator;);
AesCipherService aes = new AesCipherService();
byte[] key = java.util.Base64.getDecoder().decode(;kPH;bIxk5D2deZiIxcaaaA==;);
ByteSource ciphertext = aes.encrypt(payloads, key);
System.out.printf(ciphertext.toString());
}
将生成的payload赋值给rememberMe,但是发送过去后;服务器报错。
下面根据p师傅的分析复现一下报错原因;发现是这个类;
org.apache.shiro.io.ClassResolvingObjectInputStream的问题。可以看到这是一个ObjectInputStream的子类;其重写了resolveClass方法;resolveClass是反序列化中用来查找类的方法;;
对比一下它的父类;也就是正常的ObjectInputStream 类中的resolveClass 方法;
区别就是前者用的是org.apache.shiro.util.Class-Utils#forName(实际上内部用到了org.apache.-catalina.loader.ParallelWebappClassLoader#loadClass);而后者用的是Java原生的Class.forName
调试发现出现异常时加载的类名为[Lorg.apache.comm-ons.collections.Transformer;这个类名看起来怪;其实就是表示org.apache.-commons.collections.Transformer的数组。
所以;网上很多文章就给出结论;Class.forName支持加载数组;ClassLoader.loadClass不支持加载数组;这个区别导致了问题。但p师傅在Java漫谈中否定了这一观点;并写出结论;如果反序列化流中包含非Java自身的数组;则会出现无法加载类的错误。这就解释了为什么CommonsCollections6无法利用了;因为其中用到了Transformer数组。
p师傅在漫谈中分析讲解了两种poc;一个是使用TemplatesImpl改造的无数组CCShiro反序列化链;这个链需要有CC依赖;另一个是CB的无依赖Shiro反序列化链,这两个poc都可以测试成功了。
漏洞修复
Shiro 在 1.2.5 的 Commit 中对此漏洞进行了修复。系统在启动的时候会生成一个新key;用户也可以手动配置一个cipherKey。
其实在 SHIRO-441;就有人提出了硬编码可能带来的问题。
CVE-2016-6802
漏洞信息
**漏洞编号;**CVE-2016-6802 / CNVD-2016-07814
**影响版本;**shiro < 1.3.2
**漏洞描述;**Shiro未对ContextPath做路径标准化导致权限绕过
**漏洞补丁;**Commit
参考 ; su18师傅
漏洞详解
本漏洞类似 CVE-2010-3863;依旧是路径标准化导致的问题;不过之前是在 RequestURI 上;本漏洞是在 ContextPath 上。
之前提到;Shiro 调用 WebUtils.getPathWithin-Application() 方法获取请求路径。逻辑如下;
public String getPathWithinApplication(HttpServletRequest request) {
String contextPath = this.getContextPath(request);
String requestUri = this.getRequestUri(request);
String path = this.getRemainingPath(requestUri, contextPath, true);
if (path != null) {
return StringUtils.hasText(path) ? path : ;/;;
} else {
return requestUri;
}
}
其中调用getContextPath()方法;获取contextPath;
调用getRequestUri()方法;获取uri ;
在getContextPath()方法调用decodeRequest-String进行URLDecode。
由于获取的 ContextPath 没有标准化处理;如果出现一些特殊字符使ContextPath与实际不符;都会导致在 StringUtils.startsWithIgnoreCase() 方法判断时失效;直接返回完整的RequestURI。
复现
登录账户lonestarr;该账户对页面remoting.jsp没有访问权限;在跟路径前加任意路径;再加…/即可实现绕过
漏洞修复
Shiro 在 1.3.2 版本的 Commit 中对此漏洞进行了修复。
通过代码可以看出;在 WebUtils.getContextPath 方法进行了更新;使用了修复 CVE-2010-3863 时更新的路径标准化方法 normalize 来处理 ContextPath 之后再返回。
