聊城网站建设首选天成网络,市场营销策略概念,个人做网站的好处,计算机网络设计是干什么的工作概述 Apache Shiro是一个强大且易用的Java安全框架,执行身份验证、授权、密码和会话管理。使用Shiro的易于理解的API,您可以快速、轻松地获得任何应用程序,从最小的移动应用程序到最大的网络和企业应用程序。 它的原理比较简单#xff1a;为了让浏览器或服务器重启后用户不丢失…概述
Apache Shiro是一个强大且易用的Java安全框架,执行身份验证、授权、密码和会话管理。使用Shiro的易于理解的API,您可以快速、轻松地获得任何应用程序,从最小的移动应用程序到最大的网络和企业应用程序。 它的原理比较简单为了让浏览器或服务器重启后用户不丢失登录状态Shiro支持将持久化信息序列化并加密后保存在Cookie的rememberMe字段中下次读取时进行解密再反序列化。但是在Shiro 1.2.4版本之前内置了一个默认且固定的加密Key,导致攻击者可以伪造任意的rememberMe Cookie,进而触发反序列化漏洞。
Shiro反序列化漏洞目前为止有两个Shiro-550(Apache Shiro 1.2.5)和Shiro-721( Apache Shiro 1.4.2 )。这两个漏洞主要区别在于Shiro550使用已知密钥撞后者Shiro721是使用登录后rememberMe{value}去爆破正确的key值进而反序列化对比Shiro550条件只要有足够密钥库条件比较低、Shiro721需要登录要求比较高鸡肋。
Apache Shiro 1.4.2默认使用AES/CBC/PKCS5Padding模式
Apache Shiro 1.4.2默认使用AES/GCM/PKCS5Padding模式
shiro反序列化漏洞成因
概述
Apache Shiro是一个强大且易用的Java安全框架,执行身份验证、授权、密码和会话管理。使用Shiro的易于理解的API,您可以快速、轻松地获得任何应用程序,从最小的移动应用程序到最大的网络和企业应用程序。 它的原理比较简单为了让浏览器或服务器重启后用户不丢失登录状态Shiro支持将持久化信息序列化并加密后保存在Cookie的rememberMe字段中下次读取时进行解密再反序列化。但是在Shiro 1.2.4版本之前内置了一个默认且固定的加密Key,导致攻击者可以伪造任意的rememberMe Cookie,进而触发反序列化漏洞。
Shiro反序列化漏洞目前为止有两个Shiro-550(Apache Shiro 1.2.5)和Shiro-721( Apache Shiro 1.4.2 )。这两个漏洞主要区别在于Shiro550使用已知密钥撞后者Shiro721是使用登录后rememberMe{value}去爆破正确的key值进而反序列化对比Shiro550条件只要有足够密钥库条件比较低、Shiro721需要登录要求比较高鸡肋。
Apache Shiro 1.4.2默认使用AES/CBC/PKCS5Padding模式
Apache Shiro 1.4.2默认使用AES/GCM/PKCS5Padding模式
Shiro-550Hard Code-Deserialize-RCE
Shiro 550 反序列化漏洞存在版本
shiro 1.2.4产生原因是因为shiro接受了Cookie里面rememberMe的值然后去进行Base64解密后再使用aes密钥解密后的数据进行反序列化。
这个aes密钥是硬编码简称写死也就是他密钥是写死在jar包里面的众所周知AES 是对称加密即加密密钥也同样是解密密钥那如果我们能知道了这个密钥就可以伪造恶意cookie
接下来我们从Cookie的加密和解密过程来了解shiro-550
Cookie加密过程
直接来看shiro的CookieRememberMeManager在org.apache.shiro.web.mgt.CookieRememberMeManager#rememberSerializedIdentity里面存在一个将serialized数据Base64加密然后作为Cookie返回的行为 我们看下哪些地方调用了这个方法狂摁CtrlB: org.apache.shiro.web.mgt.CookieRememberMeManager#rememberSerializedIdentity-org.apache.shiro.mgt.AbstractRememberMeManager#rememberIdentity-org.apache.shiro.mgt.AbstractRememberMeManager#rememberIdentity(重载)-org.apache.shiro.mgt.AbstractRememberMeManager#onSuccessfulLogin 看到这个函数名都知道是登陆成功调用的如果继续跟下去的话会有 org.apache.shiro.mgt.DefaultSecurityManager#rememberMeSuccessfulLogin -org.apache.shiro.mgt.DefaultSecurityManager#onSuccessfulLogin-org.apache.shiro.mgt.DefaultSecurityManager#login-……
会追溯到Filter之类的大概就是
登陆-登陆成功-设置Base64编码后的AES加密的Cookie
在onSuccessfulLogin方法这里下个断点 在调用rememberIdentity之前先调用isRememberMe判断了用户是否选择了RememberMe选项如果选了进入rememberIdentity方法 这个方法先创建一个PrincipalCollection对象包含了登录信息。
随后进入rememberIdentity方法 这个方法调用convertPrincipalsToBytes把序列化后的PrincipalCollection对象加密然后返回 而这个seriallize方法调用org.apache.shiro.mgt.AbstractRememberMeManager#getEncryptionCipherKey去获取加密的key 跟进发现直接返回了一个属性 转到定义这个属性貌似是预先定义好的虽然没看出究竟是哪里定义的不过我们可以看到一个叫做DEFAULT_CIPHER_KEY_BYTES的东西这个就是传说中的硬编码的shirokey 之后就是调用rememberSerializedIdentity返回base64加密的cookie了。
接下来康康解密过程
Cookie解密过程
我们其实可以猜测加密解密的功能实际上都是由这个
org.apache.shiro.web.mgt.CookieRememberMeManager类来实现的在这个类里面四处找一找可以找到getRememberedSerializedIdentity方法里面有一行 这个很像获取Cookie然后去读取值的操作在这里下个断点带着Cookie访问服务果然就断下来了
单步跟进发现他获取到了我们的Cookie 随后判断了一下我们Cookie的值是不是等于DELETED_COOKIE_VALUE (deleteMe)如果不是则进行decode并且返回 返回到了这里 并且调用convertBytesToPrincipals这个函数名字是不是很熟悉将Cookie的结果转化为凭据PrincipalCollection对象
因为之前加密过程调用convertPrincipalsToBytes是一个序列化过程那这里显然就是一个反序列化过程跟进 解密而后反序列化
跟进触发点在
org.apache.shiro.io.DefaultSerializer#deserialize 1.2.5 版本修复
修改了org.apache.shiro.mgt.AbstractRememberMeManager的硬编码方式并且去掉了默认key采用随机生成的shiro AES key 但是这个key是可以自定义的
private static final String ENCRYPTION_KEY 3AvVhmFLUs0KTA3Kprsdag;
public CookieRememberMeManager rememberMeManager() {CookieRememberMeManager cookieRememberMeManager new CookieRememberMeManager();cookieRememberMeManager.setCookie(rememMeCookie());// remeberMe cookie 加密的密钥 各个项目不一样 默认AES算法 密钥长度128 256 512cookieRememberMeManager.setCipherKey(Base64.decode(ENCRYPTION_KEY));return cookieRememberMeManager;
}
或者
spring-shiro.xml
在安全管理器SecurityManager中加入rememberMeManager 添加rememberMeManager调用getCipherKey()随机生成密钥。 理论上只要AES加密钥泄露都会导致反序列化漏洞也就是说只要你硬编码就有可能有爆破的风险
Shiro-721Padding Oracle Attack-Shiro AES key-shiro550
这个就不是重点了shiro721本来利用需要先登陆获得有效的rememberMe{value}去爆破正确的key值进而反序列化利用十分鸡肋。
关于Padding Oracle Attack看这篇
padding oracle和cbc翻转攻击
大概过程是这样
比如我们的明文为admin 则需要被填充为 admin\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b 一共11个\x0b 如果我们输入一个错误的iv依旧是可以解密的但是middle和我们输入的iv经过异或后得到的填充值可能出现错误 比如本来应该是admin\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b 而我们错误的得到admin\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x3b\x2c 这样解密程序往往会抛出异常(Padding Error) 应用在web里的时候往往是302或是500报错 而正常解密的时候是200 所以这时我们可以根据服务器的反应来判断我们输入的iv 如果发送的rememberMe可以正确解析 否则会抛出异常返回deleteMe 通过这一点的不同我们可以向服务发出一个oracle“我这个iv解密出的padding对不对”
如果是对的正确解析如果是错的返回deleteMe基于此反复发出Oracle来爆破iv再控制iv来控制解密后的明文也就是不需要key了
这里还有一点为什么需要一个合法用户的rememberMe因为Shiro会获取用户信息如果不是合法用户也会返回异常从而抛出deleteMe这样Oracle就没办法实现了。
