bit4 发布的文章

记一次Java反序列化漏洞的发现和修复

0x00 背景简介

本文是自己对一次反序列化漏洞的发现和修复过程,如有错误请斧正,大神请轻喷。

目标应用系统是典型的CS模式。

客户端是需要安装的windows桌面程序,但是它是大部分内容都是基于Java开发(安装目录有很多Jar包)。

服务端是基于Jboss开发。

客户端和服务端之间的通信流量是序列化了的数据流量。客户端接收和解析数据流量的模式和服务端一样,也是通过http服务,它在本地起了80、81端口,用于接收反序列化对象。

0x01 Java序列化流量特征

特征一

参考特征,反序列化数据看起来就是这个样子: sr 、类名、空白字符

序列化数据特征1.png

特征二

固有特征,是Java的序列化数据就一定是这样,如果是base64编码的,就是以rO0A开头的。

序列化数据特征2.png

特征三

参考特征,有些content-type就说明了它是是序列化数据。

序列化数据特征3.png

0x02 检测工具

当确定是序列化数据后,我使用了2个会主动进行反序列化漏洞扫描的Burp Suite插件:

当时忘记截图了,这是后续在测试环境的截图:

Java_Deserialization_Scanner1.png

Freddy的流量识别截图:

Freddy.png

0x03 复现方法(攻击服务器端)

使用ysoserial生成一个Payload,这里以Jdk7u21为例,由于是内部系统,我知道服务器上JDK的版本。

java -jar ysoserial-master.jar Jdk7u21 "ping jdk.xxx.ceye.io" > Jdk7u21

将生成的Payload通过Burp suite向服务端进行请求,命令执行成功。

server.png

0x04 攻击客户端

晚上回家想了想,返回包也是序列化格式的,是不是可以试试攻击客户端呢?第二天来一试,还真的可以。

对客户端做了一个简单的分析,发现客户端在本地起了80和81端口,也是通过http 服务来接收序列化对象的,反序列化过程和服务端如出一辙。

java -jar ysoserial-master.jar CommonsCollections3 "calc.exe" >CC3-desktop

client.png

这里自己想象了一种攻击场景:当攻击者控制了服务器之后,可以干掉这个服务,自己开启一个恶意的服务端,当反序列化请求过来时,都返回一个恶意的响应包,比如反弹shell之类的,凡是使用了该客户端的用户都可能被攻击。危害还是不容小视的。

0x05 防护思路

到了这里就开始考虑修复了,我给开发提供了2种修复思路。

升级

升级服务端所依赖的可能被利用的jar包,当然还包括JDK。不错所料,开发一听就否了。一来升级需要经过各种功能性测试,耗时较长,二来是JDK的升级可能造成稳定性问题(之前一个AMF的反序列化问题就是如此,升了2个月了还没搞定)。

过滤

另一个思路就是过滤了,需要继承Java.io.ObjectInputStream实现一个子类,在子类中重写resolveClass方法,以实现在其中通过判断类名来过滤危险类。然后在JavaSerializer类中使用这个子类来读取序列化数据,从而修复漏洞。

反序列化防御.png

0x06 失败的修复

我将以上的第二种修复思路给到了开发,并提醒参考SerialKiller项目。过了一段时间,开发告诉我修复了,然而我的验证显示漏洞依然存在。

只好硬着头皮去开发电脑上看代码,后来发现开发将过滤方法用在了下图的方法之后,而且是在判断获取到的对象是不是HashMap实例之后(开发不愿意给我截图了...)。到这里我终于发现了点不对劲,在判断对象类型了,岂不是说明已经反序列化完成了?

通过对这个getRequestData()函数的追踪,确定反序列化过程是在一个底层的Jar包中完成的。

getrequest.jpg

0x07 对底层Jar包的分析

然后我拿到这个Jar进行了分析,它是公司自己开发的框架。最后艰难地理出了其中的调用逻辑:该框架基于struts2开发,从下图的调动逻辑可以看出,所有的请求到达服务端后,都会首先经过DataInterceptor这个拦截器,这个拦截器执行的动作就是反序列化数据然后给到Action。上面的getRequestData()方法,已经是在这个流程之后了,属于Action中的逻辑。故而开发的修复方式无效。

flowofcall.png

DataInterceptor类的实现如下:

public class DataInterceptor
  extends BaseInterceptor
{
  private static final long serialVersionUID = 1L;

  public String intercept(ActionInvocation invocation)
    throws Exception
  {
    HttpServletRequest request = (HttpServletRequest)invocation
      .getInvocationContext().get("com.opensymphony.xwork2.dispatcher.HttpServletRequest");
    Object action = invocation.getAction();
    if ((action instanceof IDataAction))
    {
      IDataAction richAction = (IDataAction)action;
      Serializable model = Toolkit.getSerializer().deserialize(
        request.getInputStream());//这里执行了反序列化操作
      richAction.setRequestData(model);//将对象传递给了Action,getRequestData()方法才能获取到
    }
    else if ((action instanceof IDataBundleAction))
    {
      IDataBundleAction richAction = (IDataBundleAction)action;
      Serializable model = Toolkit.getSerializer().deserialize(
        request.getInputStream());
      richAction.setRequestDataBundle((DataBundle)model);
    }
    return invocation.invoke();
  }
}

JavaSerializer的实现如下:

import java.io.BufferedInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.ObjectInputStream;
import java.io.Serializable;

public class JavaSerializer
  extends AbstractSerializer
{
  public Serializable deserialize(InputStream in)
    throws IOException
  {
    ObjectInputStream oo = new ObjectInputStream(new BufferedInputStream(in));
    try
    {
      return (Serializable)oo.readObject();
    }
    catch (ClassNotFoundException e)
    {
      throw new IOException("序列化类文件找不到:" + e.getMessage());
    }
    finally
    {
      oo.close();
    }
  }

到这里就清楚了,真正有漏洞的代码就在这里。

0x08 成功修复

要修复这个漏洞,就需要将上面的第二种过滤修复方法用到这个类里,具体的实现方法和SerialKiller一样。

需要继承Java.io.ObjectInputStream实现一个子类(SerialKiller),在子类中重写resolveClass方法,以实现在其中通过判断类名来过滤危险类。然后在JavaSerializer类中使用这个子类来读取序列化数据,从而修复漏洞。

通过如上方法修复了该漏洞,验证也是成功修复。修复后的JavaSerializer类:

import com.xxx.xxx.xxx.core.security.SerialKiller;
import java.io.BufferedInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.ObjectInputStream;
import java.io.Serializable;

public class JavaSerializer
  extends AbstractSerializer
{
  public Serializable deserialize(InputStream in)
    throws IOException
  {
    ObjectInputStream ois = new SerialKiller(new BufferedInputStream(in));//SerialKiller是重写了resolveClass方法的子类。
    try
    {
      return (Serializable)ois.readObject();
    }
    catch (ClassNotFoundException e)
    {
      throw new IOException("序列化类文件找不到:" + e.getMessage());
    }
    finally
    {
      ois.close();
    }
  }

0x09 意外之喜 - 另一处XMLDecoder反序列化漏洞

然而,对Java包的分析还发现了另外一处反序列化漏洞。问题出在对XML的反序列化过程中,和weblogic的XMLDecoder RCE如出一辙。

漏洞代码如下:

import java.beans.XMLDecoder;
import java.io.IOException;
import java.io.InputStream;
import java.io.Serializable;

public class XmlSerializer
  extends AbstractSerializer
{
  public Serializable deserialize(InputStream in)
    throws IOException
  {
    XMLDecoder xd = new XMLDecoder(in);//和weblogic的XMLDecoder RCE如出一辙
    try
    {
      return (Serializable)xd.readObject();
    }
    finally
    {
      xd.close();
    }
  }

它的修复方式也是参考了weblogic的,需要实现一个validate 函数,在执行XML解码(XMLDecoder)前,对InputStream对象进行检查过滤。

private void validate(InputStream is){
      WebLogicSAXParserFactory factory = new WebLogicSAXParserFactory();
      try {
         SAXParser parser = factory.newSAXParser();

         parser.parse(is, new DefaultHandler() {
            private int overallarraylength = 0;
            public void startElement(String uri, String localName, String qName, Attributes attributes) throws SAXException {
               if(qName.equalsIgnoreCase("object")) {
                  throw new IllegalStateException("Invalid element qName:object");
               } else if(qName.equalsIgnoreCase("new")) {
                  throw new IllegalStateException("Invalid element qName:new");
               } else if(qName.equalsIgnoreCase("method")) {
                  throw new IllegalStateException("Invalid element qName:method");
               } else {
                  if(qName.equalsIgnoreCase("void")) {
                     for(int attClass = 0; attClass < attributes.getLength(); ++attClass) {
                        if(!"index".equalsIgnoreCase(attributes.getQName(attClass))) {
                           throw new IllegalStateException("Invalid attribute for element void:" + attributes.getQName(attClass));
                        }
                     }
                  }

                  if(qName.equalsIgnoreCase("array")) {
                     String var9 = attributes.getValue("class");
                     if(var9 != null && !var9.equalsIgnoreCase("byte")) {
                        throw new IllegalStateException("The value of class attribute is not valid for array element.");
                     }
                  }
               }
             }
         });

         } catch (ParserConfigurationException var5) {
            throw new IllegalStateException("Parser Exception", var5);
         } catch (SAXException var6) {
            throw new IllegalStateException("Parser Exception", var6);
         } catch (IOException var7) {
            throw new IllegalStateException("Parser Exception", var7);
         }
}

0x10 总结

零零散散学习反序列化漏洞已经很长时间了,这是第一次在公司自研框架中发现反序列化漏洞,所以总结记录一下,大神请轻喷!也算是对该漏洞知识的一个梳理。学习还是要实践过、做过了才算是学到了,否则永远不是自己的!

0x11 参考

过滤方法的一个开源库,但是这个库需要依赖JDK1.8: https://github.com/ikkisoft/SerialKiller

反序列化漏洞的入口和限制条件+反序列化过滤防御思路:https://www.ibm.com/developerworks/library/se-lookahead/

廖师傅的Weblogic XMLDecoder RCE分析: http://xxlegend.com/2017/12/23/Weblogic%20XMLDecoder%20RCE%E5%88%86%E6%9E%90/

U2C:Unicode转中文的Burp Suite插件

version 0.1-0.5:

前五个版本使用自定义的图形界面,是在原始请求响应的基础上修改数据包,然后进行展示。

这样有个坏处就是可能破坏响应包在浏览器等终端的展示,可能出现乱码。虽然设计了图像界面进行控制,但是也不够灵活简洁。

前五个版本算是走了冤枉路,但也是由于有前五个版本,才有了下面的第六版。

version 0.6:

完全重写,使用新的Tab来展示转码后的响应数据包,不影响原始的响应数据包,更加简洁实用!

值得注意的是:U2C中的显示情况与Burp Suite中User options---Display--- HTTP Message Display & Character Sets有关,目前Burp Suite的API无法完全控制。只能自行设置。

origin.png

u2cTab.png

GitHub: https://github.com/bit4woo/u2c

Download: https://github.com/bit4woo/u2c/releases

测试URL: https://map.baidu.com/?qt=operateData&getOpModules=op1%2Cop2%2Cop3%2Cop4%2Cop5%2Cop6%2Cop7

Knife:一个将有用的小功能加入到右键菜单的Burp Suite插件

项目主页

https://github.com/bit4woo/knife

功能说明

目前有四个菜单:

copy this cookie

尝试复制当前请求中的cookie值到剪贴板,如果当前请求没有cookie值,将不做操作。

get lastest cookie

从proxy history中获取与当前域的最新cookie值。个人觉得这个很有有用,特别是当repeater等请求中的cookie过期,而又需要重放复现时。感谢cf_hb师傅的idea。

add host to scope

将当前请求的host添加到burp的scope中,我们常常需要的时将整个网站加到scope而不是一个具体的URL。

U2C

尝试对选中的内容进行【Unicode转中文的操作】,只有当选中的内容时response是才会显示该菜单。

U2C.png

如有任何小的改进和想要实现的小功能点,都欢迎提交给我,谢谢!

本文内容选自知识星球:

20180613080600.jpg

基于Burp Collaborator的HTTP API

前言

  • 听说你想用Ceye,而又怕认证?
  • 听说你想用CloudEye,而又没有注册码?
  • 听说你想用DNSlog,而又嫌太麻烦?

burp_collaborator_http_api是一个让你可以通过HTTP API调用Burp Suite的Collaborator服务器的插件,让你分分钟用上Burp Suite版本的DNSlog

部署说明

方式一

最简单的方式是运行Burp Suite Pro并安装这个插件

install.png

此方式使用的是Burp Suite官方的Collaborator服务器

方式二

自建Burp Collaborator服务器,这样就能做到完全独立自主了

参考官方文档:https://portswigger.net/burp/help/collaborator_deploying

GitHub上也有Docker版本的部署方法:https://github.com/integrity-sa/burpcollaborator-docker

接口说明

生成Payload:http://127.0.0.1:8000/generatePayload

获取Payload的记录:http://127.0.0.1:8000/fetchFor?payload=e0f34wndn15gs5xyisqzw8nwyn4ds2

目前这个接口是原样返回,数据没有做处理,但足以判断命令是否执行成功。后续会优化

它可以接收的请求类型包括: HTTP\HTTPS\DNS\SMTP\SMTPS\FTP;Demo版本暂不区分,后续有空会继续优化,提供特定类型的查询和数据提取。

接口调用示例

简单的Python调用示例:

# !/usr/bin/env python
# -*- coding:utf-8 -*-
__author__ = 'bit4'
__github__ = 'https://github.com/bit4woo'

import requests

proxy = {"http": "http://127.0.0.1:8888", "https": "https://127.0.0.1:8888"}
url = "http://127.0.0.1:8000/generatePayload"
response = requests.get(url)
payload = response.text
print payload
requests.get("http://{0}".format(payload))
url = "http://127.0.0.1:8000/fetchFor?payload={0}".format(payload.split(".")[0])
res = requests.get(url)
print  res.content

call api.png

尝试在无图形界面的Linux上运行

这部分还在研究中,如果你有好的方法,欢迎提交给我,谢谢!

最简单的部署一个Collaborator服务器的方式:

sudo java -jar burp.jar --collaborator-server

启动Burp Suite Pro并安装指定插件,需要先在json中配置:

java -jar burpsuite_pro_1.7.33.jar --user-config-file=collaborator_http_api.json

不启动图形界面:

java -Djava.awt.headless=true -jar burpsuite_pro_1.7.33.jar --user-config-file=collaborator_http_api.json

Java反序列化漏洞学习实践三:理解Java的动态代理机制

0x01 基础

代理模式:为其他对象提供一种代理以便控制对这个对象的访问(所谓控制,就是可以在其调用行为,前后分别加入一些操作)。

代理模式分类:

  1. 静态代理(其实质是类的继承,比较容易理解)
  2. 动态代理(这是我们需要关注的重点,)比较重要!!

0x02 静态代理Demo和理解

package Step3;

/*
 * 代理模式的简单demo,静态代理
 */

public class proxyTest{
    public static void main(String[] args) {
        Subject sub=new ProxySubject();
        sub.request();
    }
}

abstract class Subject
{//抽象角色:通过接口或抽象类声明真实角色实现的业务方法。
    //类比网络代理,比如http代理,都支持http协议
    abstract void request();
}

class RealSubject extends Subject
{//真实角色:实现抽象角色,定义真实角色所要实现的业务逻辑,供代理角色调用。
    //类比真实的http请求
       public RealSubject()
       {
       }

       public void request()
       {
              System.out.println("From real subject.");
       }
}

class ProxySubject extends Subject//关键是类的继承
{//代理角色:实现抽象角色,是真实角色的代理,通过真实角色的业务逻辑方法来实现抽象方法,并可以附加自己的操作。
    //类比通过代理发出http请求,这个代理当然可以对http请求做出任何想要的修改。
    private RealSubject realSubject; //以真实角色作为代理角色的属性

       public ProxySubject()
       {
       }

       public void request() //该方法封装了真实对象的request方法
       {//所谓的“控制”就体现在这里
        preRequest(); 
              if( realSubject == null )
        {
                     realSubject = new RealSubject();
              }
        realSubject.request(); //此处执行真实对象的request方法
        postRequest();
       }

    private void preRequest()
    {
        //something you want to do before requesting
        System.out.println("Do something before requesting");
    }

    private void postRequest()
    {
        //something you want to do after requesting
        System.out.println("Do something after requesting");
    }
}

运行效果:

1.png

0x03 动态代理Demo及理解

在java的动态代理机制中,有两个重要的类或接口,一个是InvocationHandler(Interface)、另一个则是Proxy(Class),这一个类和接口是实现我们动态代理所必须用到的。

大致逻辑流程就是:

定义一个接口(抽象角色)-->基于以上接口实现一个类(真实角色)-->基于InvocationHandler实现一个处理器类;

接着调用流程:

实现一个真实角色对象-->实现一个处理器对象-->构建一个新的代理对象,这个对象基于已有的处理器 和接口的类-->再把这个代理对象转换为【接口的类型、抽象角色的类型】,不能是真实角色的类型,为什么?

package Step3;

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;

/*
 * 代理模式的简单demo,动态代理,动态代理利用了反射机制
 * 每一个动态代理类都会有一个与之关联的invocation handler。真正的调用是在invocation handler的invoke()方法里完成的。
 * 感谢蝶离飞、廖新喜2为师傅的指导
 */

public class proxyTest2{
    public static void main(String[] args) {
        DynamicSubject sub=new RealDynamicSubject();//之前这里sub的类型是RealDynamicSubject,不对;但是为什么呢?
        Handler handler = new Handler(sub);
        DynamicSubject sub2 = (DynamicSubject)Proxy.newProxyInstance(DynamicSubject.class.getClassLoader(), new Class[]{DynamicSubject.class}, handler); 
        //CLassLoader loader:指定动态代理类的类加载器
        //Class<?> interfaces:指定动态代理类需要实现的所有接口
        //InvocationHandler h: 指定与动态代理类关联的 InvocationHandler对象
        DynamicSubject sub3 = (DynamicSubject)Proxy.newProxyInstance(DynamicSubject.class.getClassLoader(), sub.getClass().getInterfaces(), handler);

        DynamicSubject sub4 = (DynamicSubject)Proxy.newProxyInstance(DynamicSubject.class.getClassLoader(), RealDynamicSubject.class.getInterfaces(), handler);

        System.out.println("sub.getClass() = "+sub.getClass());
        System.out.println("DynamicSubject.class = " +DynamicSubject.class);
        System.out.println(new Class[]{DynamicSubject.class});
        System.out.println(RealDynamicSubject.class.getInterfaces());

        sub2.request();
        sub3.request();
        sub4.request();
    }
}

interface DynamicSubject
{//抽象角色:通过接口或抽象类声明真实角色实现的业务方法。注意:动态代理只能是接口,否则代理类转成该类型事会报错
    //类比网络代理,比如http代理,都支持http协议
    abstract void request();
}

class RealDynamicSubject implements DynamicSubject
{//真实角色:实现抽象角色,定义真实角色所要实现的业务逻辑,供代理handler处理调用。
    //类比真实的http请求
       public RealDynamicSubject()
       {
       }

       public void request()
       {
              System.out.println("From real subject.");
       }
}

/**
 * 处理器
 */
class Handler implements InvocationHandler{
    private Object obj; //被代理的对象,不管对象是什么类型;之前声明成RealDynamicSubject,不应该这么做
    /**
     * 所有的流程控制都在invoke方法中
     * proxy:代理类
     * method:正在调用的方法
     * args:方法的参数
     */
    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {//接口必须实现的方法,也是逻辑核心
        System.out.println("Do something before requesting");
        Object xxx = method.invoke(this.obj, args);
        System.out.println("Do something after requesting");
        return xxx;
    }
    public Handler(Object obj) {
        //构造函数,把真实角色的实例传递进来,这个代理handler的目的就是处理它
        this.obj = obj;
    }
}

运行效果:

2.png

0x03 思考总结

在后续将要学习的反序列化PoC构造过程中,我们需要用到这个动态代理机制,因为它提供一种【方法之间的跳转,从任意方法到invoke方法的跳转】,是我们将参数入口和代码执行联系起来的关键!

本文代码下载地址:

https://github.com/bit4woo/Java_deserialize_vuln_lab/tree/master/src/Step3

0x04 参考