type
status
date
slug
summary
tags
category
icon
password
小白(me)第n次复习这些java漏洞（初步只写反序列化）
shiro
shiro550影响版本：Shiro <= 1.2.4
shiro721影响版本：Shiro < 1.4.2
原理博客看一堆，找不到了，总结下来是下面的描述。
shiro550原理：
Apache Shiro框架提供了记住密码的功能（RememberMe），用户登录成功后会生成经过加密并编码的cookie。在服务端对rememberMe的cookie值，先base64解码然后AES解密再反序列化，就导致了反序列化RCE漏洞。
- 那么，Payload产生的过程：
命令=>序列化=>AES加密=>base64编码=>伪造RememberMe Cookie值
shiro721原理：
shiro中cookie
rememberMe已通过AES-128-CBC模式加密，攻击者可以使用有效的RememberMe cookie作为Padding Oracle Attack的前缀，然后制作精心制作的RememberMe来执行Java反序列化攻击。二者区别：
Shiro550是硬编码秘钥，只需要通过碰撞key，爆破出来密钥，就可以进行利用。
Shiro721的ase加密的key一般情况下猜不到，是系统随机生成的，并且当存在有效的用户信息时才会进入下一阶段的流程，所以我们需要使用登录后的rememberMe Cookie，当登陆页面登录失败后响应只有rememberMe=delete me，成功后会存在rememberMe字字段后才存在有效的用户信息。
721爆破成功才会有cookie；
shiro721是shiro框架中的身份验证过程中的一个漏洞，该漏洞允许攻击者通过填充信息的不同响应时间来确定身份验证过程中的错误。通过不断尝试不同的填充方式，攻击者可以逐步推断出加密秘钥，并最终获取访问权限。
检测：
人工：
在登陆点输入任意账号密码抓包，请求的cookie中或者返回包中包含rememberMe=deleteMe这个字段。就可能存在这个漏洞。
burp插件：shiroscanner，Hae
利用：
ShiroExploit工具。
shiro_attack工具
weblogic
t3协议反序列化
（代码审计文章给忘了记了）
RMI通信传输反序列化数据，接收数据后进行反序列化，正常RMI通信使用的是JRMP协议，而在Weblogic的RMI通信中使用的是T3协议。
发送t3协议的时候，在t3协议头后可发送多个序列化数据，替换其中一个正常的序列化对象为恶意对象即可实现反序列化攻击。
本质是resolveClass方法将类的序列化描述转化为类的class对象的过程中，未做过滤或过滤不严格可绕过。
xml反序列化
（代码审计文章给忘了记了）
XMLDecoder/XMLEncoder 是在JDK1.4版中添加的 XML 格式序列化持久性方案，使用XMLEncoder 来生成表示 JavaBeans 组件(bean)的 XML 文档，用 XMLDecoder 读取使用 XMLEncoder 创建的XML文档获取JavaBeans。
FileSystemXmlApplicationContext类是spring框架的一部分，用于加载和处理xml配置文件，攻击者构建一个恶意的 XML 配置文件，其中包含特制的Spring Beans定义，而Spring Beans 可以包含代码或引用其他类。此时，只需要构造一个恶意XML文件通过java.lang.ProcessBuilder启动一个外部进程进行代码执行即可。
和我的某一篇详细博客一起理解：https://blog.kongbaimeng.xyz/vuln/ysoserial
log4j
log4j2 反序列化（CVE-2021-44228）
Apache log4j2是一个就Java的日志记录工具，它的原理是jndi注入。
jndi注入通过lookup方法向ldap，rmi，dns等等远程服务中请求资源，格式是
${jndi:服务:ip:port/资源地址}，如果此资源地址是一个短链接，服务器访问下载它最终下载了一个java的恶意class文件，就会自动加载这个恶意的class文件，从而实现注入。攻击者通过它可以实现任意的代码执行。Log4j1.2.X反序列化漏洞（CVE-2019-17571）
本质就是对从socket流中获取的数据没有进行过滤，而直接反序列化。
代码层面是一个类的main方法调用了SocketNode类，此类从socket流中获取数据，且在构造方法中将其存储为ObjectInputStream对象，并在run方法中通过readObject方法进行反序列化而未过滤。（此处readObject就是把字节序列转换为java对象，相当于php的unserialize）
Log4j2.X反序列化漏洞（CVE-2017-5645）
程序在8888端口处接收socket数据流，将接收到的数据转换成ObjectInputStream对象数据，最终此数据传入了某类的logEvents方法，调用了readObject方法进行反序列化。
fastjson判断
fastjson不出网！！！！！！！！！！！！！！小白落泪（看不懂） 文章地址
- 报错回显
web页面抓包，burp右键改get为post方法，改请求头为
Content-Type:application/jsonPOST请求体为：
{"test":",看回显
- dnslog测试
使用如下payload，这里的dnslog使用dnslog获得的网址进行替换即可
漏洞检测：fastjson漏洞批量检测工具（JsonExp）
修复思路：
- 升级到安全版本
- 开启safeMode配置完全禁用autoType
由于autotype开关的限制可被绕过，请受影响用户升级到FastJSON 1.2.68及以上版本，通过开启safeMode配置完全禁用autoType。