分析下原生的Java序列化与反序列化流程,为了尽量覆盖各种情况,需要找一个比较复杂的对象进行调试,这里选择CC1链。没有覆盖到的情况结合文档分析。 more >>
分析下原生的Java序列化与反序列化流程,为了尽量覆盖各种情况,需要找一个比较复杂的对象进行调试,这里选择CC1链。没有覆盖到的情况结合文档分析。 more >>
shiro反序列化漏洞中有个经典的现象,就是不能用ysoserial自带的链去打commons-collections3的依赖。有很多文章分析过,但总觉得没完全看懂,差了点什么。那么调试源码详细分析下这个问题。 more >>
闲来无事,反制ysoserial (
之前分析RMI的时候,发现对于客户端的反序列化攻击都是没有被修复的,也就是说如果调用了原生jdk的rmi客户端相关调用,连接恶意JRMP服务端就会触发反序列化。
攻击客户端的场景不多,除了反打服务器,打真正客户端的场景可能就是反制了,或者叫蜜罐也行。那么看下常见的攻击RMI的安全工具有没有这种问题。
上来先看看Java安全神器ysoserial里和RMI有关的exp。yso里面大部分都是本地生成payload,但也有一些打远程服务的,比如RMIRegistryExploit
1 | public static void main(final String[] args) throws Exception { |
看到了registry.list和registry.bind,这两处就是调用的原生的RegistryImpl_Stub,会触发UnicastRef#invoke->StreamRemoteCall#executeCall导致反序列化,这里就有反序列化点了。 (实际上只有list那里可以触发,下面的bind是在yso的沙箱保护下的。在18年的一次更新才引入了这处list,也就是说老的版本是不会被攻击的。 )
调用链自然也没啥问题,毕竟ysoserial算是天底下反序列化链最多的地方了。感觉就像个弹药库把自己给炸了。
所以攻击很简单,就用JRMPListener在1099端口(RMI注册中心默认端口)起一个恶意服务端,原汤化原食了属于是:
1 | java -cp ysoserial.jar ysoserial.exploit.JRMPListener 1099 CommonsCollections6 calc.exe |
然后客户端扮演jb小子,nmap扫完看见1099开了直接打:
1 | java -cp ysoserial.jar ysoserial.exploit.RMIRegistryExploit ip 1099 CommonsCollections6 whoami |
喜提计算器。
很奇怪的是在另一个攻击rmi的脚本ysoserial/exploit/JRMPClient.java里
1 | /** |
注释里特意写了not deserializing anything,说明开发者是想到过反打的问题的,但不知道为什么没有注意到另一处。
顺带一提,恶意服务器如果在实现时触发了反序列化一样是会被攻击的,只不过这种场景少了点。
ysomap是wh1t3p1g大师傅开发的Java反序列化辅助工具,和ysoserial相比可以更细化的修改payload,但是用着比较麻烦,研究了半天也没咋用明白。
同样这个工具也提供了攻击RMI registry的功能,看一下这部分实现,在ysomap/exploits/rmi/component/Naming.java
1 | public static Remote lookup(Registry registry, Object obj) |
重写了lookup,调用了JDK原生的ref.invoke,那么一样是有反打的问题的。
没太用明白,大概是这么用吧:
1 | use exploit RMIRegistryExploit |
服务端一样是JRMPListener,一样打cc就行。计算器x2。
RMIScout也是一个攻击RMI的工具,看了下这个工具重点支持攻击服务端的方式,也就是通过爆破远程方法签名攻击服务端,portswigger也宣传过这个工具https://portswigger.net/daily-swig/rmiscout-new-hacking-tool-brute-forces-java-rmi-servers-for-vulnerabilities
在rmiscout/RMIConnector.java一样是看到了原生的registry.list
1 | public RMIConnector(String host, int port, String remoteName, List<String> signatures, boolean allowUnsafe, boolean isActivationServer) { |
这个工具的攻击实际是依赖ysoserial实现的,那么一样会被反打
1 | java -jar rmiscout-1.4-SNAPSHOT-all.jar list ip 1099 |
计算器x3
常见的攻击RMI的还有个经典工具BaRMIe,实际上它的攻击流程也会触发反序列化,但是这个工具并不是用加载依赖的方式来生成payload的,而是直接写死的。那么没有依赖库,反序列化也很难打本地的链了。
另外metasploit也有对应的exp,完全基于ruby实现的,自然不会有Java反序列化的问题,还是msf懂安全。
https://github.com/frohoff/ysoserial
https://github.com/wh1t3p1g/ysomap
https://github.com/BishopFox/rmiscout
https://github.com/NickstaDB/BaRMIe
搞安全的总是要赛博考古,找找被遗忘的角落。这两年的漏洞偶尔会出现CORBA这个东西,这玩意好像比RMI还老,得有二十多年历史了,但很多框架还支持它,简单分析一下。 more >>
前面总结了几种针对RMI的攻击方式,包括以下几种:
客户端攻击注册中心
服务端攻击注册中心
注册中心攻击客户端
服务端攻击客户端
客户端攻击服务端
DGC客户端攻击DGC服务端
DGC服务端攻击DGC客户端
JRMP服务端攻击JRMP客户端
但是在jdk8u121之后,java引入了新的安全机制JEP290,这篇文章分析下该机制对RMI相关攻击的影响以及后续的绕过方法
more >>
前一篇文章整理了RMI调用的流程,大致分析了其中可能存在的反序列化攻击点,这篇来具体实现下这些攻击。但注意这些都是demo,存在被反打的风险,谨慎使用。 more >>
最近分析了下RMI相关的反序列化漏洞,查资料时发现许多分析文章都只关注漏洞点,对功能本身语焉不详。所以这篇文章先具体分析下RMI整体的调用流程,并且点出一些可能出现反序列化问题的地方。下篇写具体的漏洞利用。 more >>
缺失模块。
1、请确保node版本大于6.2
2、在博客根目录(注意不是yilia根目录)执行以下命令:
npm i hexo-generator-json-content --save
3、在根目录_config.yml里添加配置:
jsonContent: meta: false pages: false posts: title: true date: true path: true text: false raw: false content: false slug: false updated: false comments: false link: false permalink: false excerpt: false categories: false tags: true