Java反序列化漏洞之殤

3.2.2版本之前的Apache-CommonsCollections存在該漏洞（不只該包）
1.漏洞觸發場景
在java編寫的web應用與web服務器間java通常會發送大量的序列化對象例如以下場景：
　　1)HTTP請求中的參數，cookies以及Parameters。
　　2)RMI協議，被廣泛使用的RMI協議完全基於序列化
　　4)JMX 同樣用於處理序列化對象
　　5)自定義協議用來接收與發送原始的java對象

2. 漏洞挖掘
　　(1)確定反序列化輸入點
　　　　首先應找出readObject方法調用，在找到之后進行下一步的注入操作。一般可以通過以下方法進行查找：
　　　　 1)源碼審計：尋找可以利用的“靶點”，即確定調用反序列化函數readObject的調用地點。
　　　　 2)對該應用進行網絡行為抓包，尋找序列化數據，如wireshark,tcpdump等。注： java序列化的數據一般會以標記（ac ed 00 05）開頭，base64編碼后的特征為rO0AB。
　　(2)再考察應用的Class Path中是否包含Apache Commons Collections庫，這一點需要考慮?

如果在頂層容器中例如tomcat/jetty等包含commcollectios3.1,而在業務中引用commcollections3.2,則仍可能觸發漏洞。

關於反序列化漏洞分析及利用研究的文章不少，但鮮有檢測及修復方面的介紹，本文旨站在應用安全的角度，從安全編碼、代碼審計、漏洞檢測及修復方案對反序列化漏洞進行詳細分享。

概述

序列化是讓Java對象脫離Java運行環境的一種手段，可以有效的實現多平台之間的通信、對象持久化存儲。

Java 序列化是指把 Java 對象轉換為字節序列的過程便於保存在內存、文件、數據庫中，ObjectOutputStream類的 writeObject() 方法可以實現序列化。反序列化是指把字節序列恢復為 Java 對象的過程，ObjectInputStream 類的 readObject() 方法用於反序列化。

漏洞成因

序列化和反序列化本身並不存在問題。但當輸入的反序列化的數據可被用戶控制，那么攻擊者即可通過構造惡意輸入，讓反序列化產生非預期的對象，在此過程中執行構造的任意代碼。

漏洞代碼示例如下：

......
//讀取輸入流,並轉換對象
InputStream in=request.getInputStream();
ObjectInputStream ois = new ObjectInputStream(in);
//恢復對象
ois.readObject();
ois.close();

這里特別要注意的是非預期的對象，正因為此java標准庫及大量第三方公共類庫成為反序列化漏洞利用的關鍵。安全研究人員已經發現大量利用反序列化漏洞執行任意代碼的方法，最讓大家熟悉的是Gabriel Lawrence和Chris Frohoff在《Marshalling Pickles how deserializing objects can ruin your day》中提出的利用Apache Commons Collection實現任意代碼執行。此后安全研究人員也陸續爆出XML、Json、Yaml等反序列化的相關漏洞。

除了commons-collections 3.1可以用來利用java反序列化漏洞，還有更多第三方庫同樣可以用來利用反序列化漏洞並執行任意代碼，部分如下：

commons-fileupload 1.3.1
commons-io 2.4
commons-collections 3.1
commons-logging 1.2
commons-beanutils 1.9.2
org.slf4j:slf4j-api 1.7.21
com.mchange:mchange-commons-java 0.2.11
org.apache.commons:commons-collections 4.0
com.mchange:c3p0 0.9.5.2
org.beanshell:bsh 2.0b5
org.codehaus.groovy:groovy 2.3.9
......

Java反序列化詳解

序列化數據結構

通過查看序列化后的數據，可以看到反序列化數據開頭包含兩字節的魔術數字，這兩個字節始終為十六進制的0xAC ED。接下來是兩字節的版本號0x00 05的數據。此外還包含了類名、成員變量的類型和個數等。

這里以類SerialObject示例來詳細進行介紹Java對象序列化后的數據結構：

public class SerialObject implements Serializable{
    private static final long serialVersionUID = 5754104541168322017L;

    private int id;
    public String name;

    public SerialObject(int id,String name){
        this.id=id;
        this.name=name;
    }
    ...
}

序列化SerialObject實例后以二進制格式查看：

00000000: aced 0005 7372 0024 636f 6d2e 7878 7878  ....sr.$com.xxxx
00000010: 7878 2e73 6563 2e77 6562 2e68 6f6d 652e  xx.sec.web.home.
00000020: 5365 7269 616c 4f62 6a65 6374 4fda af97  SerialObjectO...
00000030: f8cc c5e1 0200 0249 0002 6964 4c00 046e  .......I..idL..n
00000040: 616d 6574 0012 4c6a 6176 612f 6c61 6e67  amet..Ljava/lang
00000050: 2f53 7472 696e 673b 7870 0000 07e1 7400  /String;xp....t.
00000060: 0563 7279 696e 0a                        .cryin.

序列化的數據流以魔術數字和版本號開頭，這個值是在調用ObjectOutputStream序列化時，由writeStreamHeader方法寫入：

protected void writeStreamHeader() throws IOException {
     bout.writeShort(STREAM_MAGIC);//STREAM_MAGIC (2 bytes) 0xACED
     bout.writeShort(STREAM_VERSION);//STREAM_VERSION (2 bytes) 5
    }

序列化后的SerialObject對象詳細結構：

STREAM_MAGIC (2 bytes) 0xACED 
STREAM_VERSION (2 bytes) 0x0005
    TC_OBJECT (1 byte) 0x73
        TC_CLASSDESC (1 byte) 0x72
        className
            length (2 bytes) 0x24 = 36
            text (36 bytes) com.xxxxxx.sec.web.home.SerialObject
        serialVersionUID (8 bytes) 0x4FDAAF97F8CCC5E1 = 5754104541168322017
        classDescInfo
            classDescFlags (1 byte) 0x02 = SC_SERIALIZABLE
            fields
                count (2 bytes) 2
                field[0]
                    primitiveDesc
                        prim_typecode (1 byte) I = integer
                        fieldName
                            length (2 bytes) 2
                            text (2 bytes) id
                field[1]
                    objectDesc
                        obj_typecode (1 byte) L = object
                        fieldName
                            length (2 bytes) 4
                            text (4 bytes)  name
                        className1
                            TC_STRING (1 byte) 0x74
                                length (2 bytes) 0x12 = 18
                                text (18 bytes) Ljava/lang/String;

            classAnnotation
                TC_ENDBLOCKDATA (1 byte) 0x78

            superClassDesc
                TC_NULL (1 byte) 0x70
    classdata[]
        classdata[0] (4 bytes) 0xe107 = id = 2017
        classdata[1]
            TC_STRING (1 byte) 0x74
            length (2 bytes) 5
            text (8 bytes) cryin

反序列化過程詳解

Java程序中類ObjectInputStream的readObject方法被用來將數據流反序列化為對象，如果流中的對象是class，則它的ObjectStreamClass描述符會被讀取，並返回相應的class對象，ObjectStreamClass包含了類的名稱及serialVersionUID。

如果類描述符是動態代理類，則調用resolveProxyClass方法來獲取本地類。如果不是動態代理類則調用resolveClass方法來獲取本地類。如果無法解析該類，則拋出ClassNotFoundException異常。

如果反序列化對象不是String、array、enum類型，ObjectStreamClass包含的類會在本地被檢索，如果這個本地類沒有實現java.io.Serializable或者externalizable接口，則拋出InvalidClassException異常。因為只有實現了Serializable和Externalizable接口的類的對象才能被序列化。

反序列化漏洞檢測方案

代碼審計

反序列化操作一般在導入模版文件、網絡通信、數據傳輸、日志格式化存儲、對象數據落磁盤或DB存儲等業務場景,在代碼審計時可重點關注一些反序列化操作函數並判斷輸入是否可控，如下：

ObjectInputStream.readObject
ObjectInputStream.readUnshared
XMLDecoder.readObject
Yaml.load
XStream.fromXML
ObjectMapper.readValue
JSON.parseObject
...

同時也要關注存在漏洞的第三方庫及版本是否安全。

進階審計

對於直接獲取用戶輸入進行反序列化操作這種點比較好審計並發現，目前反序列化漏洞已經被談起太多次了，所以有經驗的開發都會在代碼中有相應的修復。但並不是所有修復都無懈可擊。比如采用黑名單校驗的修復方式，對於這種修復可在工程代碼中嘗試挖掘新的可以利用的’gadget‘。

代碼中有使用到反序列化操作，那自身項目工程中肯定存在可以被反序列化的類，包括Java自身、第三方庫有大量這樣的類，可被反序列化的類有一個特點，就是該類必定實現了Serializable接口，Serializable 接口是啟用其序列化功能的接口，實現 java.io.Serializable 接口的類才是可序列化的。一個典型的示例如下：

public class SerialObject implements Serializable{
    private static final long serialVersionUID = 5754104541168322017L;

    private int id;
    public String name;

    public SerialObject(int id,String name){
        this.id=id;
        this.name=name;
    }

    public void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException{
        //執行默認的readObject()方法
        in.defaultReadObject();
    }
}

所以在代碼審計時對這些類也可進行特別關注，分析並確認是否有可能被發序列化漏洞利用執行任意代碼。發現新的可利用的類即可突破使用黑名單進行校驗的一些應用。

白盒檢測

大型企業的應用很多，每個都人工去審計不現實，往往都有相應的自動化靜態代碼審計工具，這里以ObjectInputStream.readObject()為例，其它原理也相似。在自動化檢測時，可通過實現解析java源代碼，檢測readObject()方法調用時判斷其對象是否為java.io.ObjectOutputStream。如果此時ObjectInputStream對象的初始化參數來自外部請求輸入參數則基本可以確定存在反序列化漏洞了。這是只需確認是否存在相應的安全修復即可。檢測方式可參考lgtm.com對於Deserialization of user-controlled data的實現:

/**
 * @name Deserialization of user-controlled data
 * @description Deserializing user-controlled data may allow attackers to
 *              execute arbitrary code.
 * @kind problem
 * @problem.severity error
 * @precision high
 * @id java/unsafe-deserialization
 * @tags security
 *       external/cwe/cwe-502
 */
import java
import semmle.code.java.security.DataFlow
import semmle.code.java.frameworks.Kryo
import semmle.code.java.frameworks.XStream
import semmle.code.java.frameworks.SnakeYaml

class ObjectInputStreamReadObjectMethod extends Method {
  ObjectInputStreamReadObjectMethod() {
    this.getDeclaringType().getASourceSupertype*().hasQualifiedName("java.io", "ObjectInputStream") and
    (this.hasName("readObject") or this.hasName("readUnshared"))
  }
}

class XMLDecoderReadObjectMethod extends Method {
  XMLDecoderReadObjectMethod() {
    this.getDeclaringType().hasQualifiedName("java.beans", "XMLDecoder") and
    this.hasName("readObject")
  }
}

class SafeXStream extends FlowSource {
  SafeXStream() {
    any(XStreamEnableWhiteListing ma).getQualifier().(VarAccess).getVariable().getAnAccess() = this
  }
}

class SafeKryo extends FlowSource {
  SafeKryo() {
    any(KryoEnableWhiteListing ma).getQualifier().(VarAccess).getVariable().getAnAccess() = this
  }
}

predicate unsafeDeserialization(MethodAccess ma, Expr sink) {
  exists(Method m | m = ma.getMethod() |
    m instanceof ObjectInputStreamReadObjectMethod and
    sink = ma.getQualifier()
    or
    m instanceof XMLDecoderReadObjectMethod and
    sink = ma.getQualifier()
    or
    m instanceof XStreamReadObjectMethod and
    sink = ma.getAnArgument() and
    not exists(SafeXStream sxs | sxs.flowsTo(ma.getQualifier()))
    or
    m instanceof KryoReadObjectMethod and
    sink = ma.getAnArgument() and
    not exists(SafeKryo sk | sk.flowsTo(ma.getQualifier()))
    or
    ma instanceof UnsafeSnakeYamlParse and
    sink = ma.getArgument(0)
  )
}

class UnsafeDeserializationSink extends Expr {
  UnsafeDeserializationSink() {
    unsafeDeserialization(_, this)
  }
  MethodAccess getMethodAccess() { unsafeDeserialization(result, this) }
}

from UnsafeDeserializationSink sink, RemoteUserInput source
where source.flowsTo(sink)
select sink.getMethodAccess(), "Unsafe deserialization of $@.", source, "user input"

黑盒檢測

調用ysoserial並依次生成各個第三方庫的利用payload(也可以先分析依賴第三方包量，調用最多的幾個庫的paylaod即可)，該payload構造為訪問特定url鏈接的payload，根據http訪問請求記錄判斷反序列化漏洞是否利用成功。如：

java -jar ysoserial.jar CommonsCollections1 'curl " + URL + " '

也可通過DNS解析記錄確定漏洞是否存在。現成的輪子很多，推薦NickstaDB寫的SerialBrute，還有一個針對RMI的測試工具BaRMIe，也很不錯～。.

RASP檢測

類的名稱及serialVersionUID的ObjectStreamClass描述符在序列化對象流的前面位置，且在readObject反序列化時首先會調用resolveClass讀取反序列化的類名，所以RASP檢測反序列化漏洞時可通過重寫ObjectInputStream對象的resolveClass方法獲取反序列化的類即可實現對反序列化類的黑名單校驗。

百度的開源RASP產品就是使用的這種方法，具體可參考其DeserializationHook.java的實現:

@Override
    protected MethodVisitor hookMethod(int access, String name, String desc,
                                       String signature, String[] exceptions, MethodVisitor mv) {
        if ("resolveClass".equals(name) && "(Ljava/io/ObjectStreamClass;)Ljava/lang/Class;".equals(desc)) {
            return new AdviceAdapter(Opcodes.ASM5, mv, access, name, desc) {
                @Override
                protected void onMethodEnter() {
                    loadArg(0);
                    invokeStatic(Type.getType(HookHandler.class),
                            new Method("checkDeserializationClass", "(Ljava/io/ObjectStreamClass;)V"));
                }
            };
        }
        return mv;
    }

其中檢測覆蓋的反序列化類黑名單如下:

plugin.register('deserialization', function (params, context) {
    var deserializationInvalidClazz = [
        'org.apache.commons.collections.functors.InvokerTransformer',
        'org.apache.commons.collections.functors.InstantiateTransformer',
        'org.apache.commons.collections4.functors.InvokerTransformer',
        'org.apache.commons.collections4.functors.InstantiateTransformer',
        'org.codehaus.groovy.runtime.ConvertedClosure',
        'org.codehaus.groovy.runtime.MethodClosure',
        'org.springframework.beans.factory.ObjectFactory',
        'xalan.internal.xsltc.trax.TemplatesImpl'
    ]

    var clazz = params.clazz
    for (var index in deserializationInvalidClazz) {
        if (clazz === deserializationInvalidClazz[index]) {
            return {
                action:     'block',
                message:    '嘗試反序列化攻擊',
                confidence: 100
            }
        }
    }
    return clean
})

攻擊檢測

通過查看反序列化后的數據，可以看到反序列化數據開頭包含兩字節的魔術數字，這兩個字節始終為十六進制的0xAC ED。接下來是兩字節的版本號。我只見到過版本號為5（0x00 05）的數據。考慮到zip、base64各種編碼，在攻擊檢測時可針對該特征進行匹配請求post中是否包含反序列化數據，判斷是否為反序列化漏洞攻擊。

xxxdeMacBook-Pro:demo xxx$ xxd objectexp 
    00000000: aced 0005 7372 0032 7375 6e2e 7265 666c  ....sr.2sun.refl
    00000010: 6563 742e 616e 6e6f 7461 7469 6f6e 2e41  ect.annotation.A
    00000020: 6e6e 6f74 6174 696f 6e49 6e76 6f63 6174  nnotationInvocat
    00000030: 696f 6e48 616e 646c 6572 55ca f50f 15cb  ionHandlerU.....

但僅從特征匹配只能確定有攻擊嘗試請求，還不能確定就存在反序列化漏洞，還要結合請求響應、返回內容等綜合判斷是否確實存在漏洞。

Java反序列化漏洞修復方案

通過Hook resolveClass來校驗反序列化的類

通過上面序列化數據結構可以了解到包含了類的名稱及serialVersionUID的ObjectStreamClass描述符在序列化對象流的前面位置，且在readObject反序列化時首先會調用resolveClass讀取反序列化的類名，所以這里通過重寫ObjectInputStream對象的resolveClass方法即可實現對反序列化類的校驗。這個方法最早是由IBM的研究人員Pierre Ernst在2013年提出《Look-ahead Java deserialization》，具體實現代碼示例如下:

public class AntObjectInputStream extends ObjectInputStream{
    public AntObjectInputStream(InputStream inputStream)
            throws IOException {
        super(inputStream);
    }

    /**
     * 只允許反序列化SerialObject class
     */
    @Override
    protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException,
            ClassNotFoundException {
        if (!desc.getName().equals(SerialObject.class.getName())) {
            throw new InvalidClassException(
                    "Unauthorized deserialization attempt",
                    desc.getName());
        }
        return super.resolveClass(desc);
    }
}

通過此方法，可靈活的設置允許反序列化類的白名單，也可設置不允許反序列化類的黑名單。但反序列化漏洞利用方法一直在不斷的被發現，黑名單需要一直更新維護，且未公開的利用方法無法覆蓋。

SerialKiller 是由Luca Carettoni利用上面介紹的方法實現的反序列化類白/黑名單校驗的jar包。具體使用方法可參考其代碼倉庫。

contrast-rO0是一個輕量級的agent程序，通過通過重寫ObjectInputStream來防御反序列化漏洞攻擊。使用其中的SafeObjectInputStream類來實現反序列化類白/黑名單控制，示例代碼如下:

SafeObjectInputStream in = new SafeObjectInputStream(inputStream, true);
in.addToWhitelist(SerialObject.class);

in.readObject();

使用ValidatingObjectInputStream來校驗反序列化的類

使用Apache Commons IO Serialization包中的ValidatingObjectInputStream類的accept方法來實現反序列化類白/黑名單控制，具體可參考ValidatingObjectInputStream介紹；示例代碼如下:

private static Object deserialize(byte[] buffer) throws IOException,
ClassNotFoundException , ConfigurationException {
    Object obj;
    ByteArrayInputStream bais = new ByteArrayInputStream(buffer);
    // Use ValidatingObjectInputStream instead of InputStream
    ValidatingObjectInputStream ois = new   ValidatingObjectInputStream(bais); 

    //只允許反序列化SerialObject class
    ois.accept(SerialObject.class);
    obj = ois.readObject();
    return obj;
}

使用ObjectInputFilter來校驗反序列化的類

Java 9包含了支持序列化數據過濾的新特性，開發人員也可以繼承java.io.ObjectInputFilter類重寫checkInput方法實現自定義的過濾器，，並使用ObjectInputStream對象的setObjectInputFilter設置過濾器來實現反序列化類白/黑名單控制。示例代碼如下:

import java.util.List;
import java.util.Optional;
import java.util.function.Function;
import java.io.ObjectInputFilter;
class BikeFilter implements ObjectInputFilter {
    private long maxStreamBytes = 78; // Maximum allowed bytes in the stream.
    private long maxDepth = 1; // Maximum depth of the graph allowed.
    private long maxReferences = 1; // Maximum number of references in a graph.
    @Override
    public Status checkInput(FilterInfo filterInfo) {
        if (filterInfo.references() < 0 || filterInfo.depth() < 0 || filterInfo.streamBytes() < 0 || filterInfo.references() > maxReferences || filterInfo.depth() > maxDepth|| filterInfo.streamBytes() > maxStreamBytes) {
            return Status.REJECTED;
        }
        Class<?> clazz = filterInfo.serialClass();
        if (clazz != null) {
            if (SerialObject.class == filterInfo.serialClass()) {
                return Status.ALLOWED;
            }
            else {
                return Status.REJECTED;
            }
        }
        return Status.UNDECIDED;
    } // end checkInput
} // end class BikeFilter

上述示例代碼，僅允許反序列化SerialObject類對象，上述示例及更多關於ObjectInputFilter的均參考自NCC Group Whitepaper由Robert C. Seacord寫的《Combating Java Deserialization Vulnerabilities with Look-Ahead Object Input Streams (LAOIS)》

黑名單校驗修復

在反序列化時設置類的黑名單來防御反序列化漏洞利用及攻擊，這個做法在源代碼修復的時候並不是推薦的方法，因為你不能保證能覆蓋所有可能的類，而且有新的利用payload出來時也需要隨之更新黑名單。

但有某些場景下可能黑名單是一個不錯的選擇。寫代碼的時候總會把一些經常用到的方法封裝到公共類，這樣其它工程中用到只需要導入jar包即可，此前已經見到很多提供反序列化操作的公共接口，使用第三方庫反序列化接口就不好用白名單的方式來修復了。這個時候作為第三方庫也不知道誰會調用接口，會反序列化什么類，所以這個時候可以使用黑名單的方式來禁止一些已知危險的類被反序列化，部分的黑名單類如下：

org.apache.commons.collections.functors.InvokerTransformer
org.apache.commons.collections.functors.InstantiateTransformer
org.apache.commons.collections4.functors.InvokerTransformer
org.apache.commons.collections4.functors.InstantiateTransformer
org.codehaus.groovy.runtime.ConvertedClosure
org.codehaus.groovy.runtime.MethodClosure
org.springframework.beans.factory.ObjectFactory
com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl
org.apache.commons.fileupload
org.apache.commons.beanutils
...

安全編碼建議

更新commons-collections、commons-io等第三方庫版本；
業務需要使用反序列化時，盡量避免反序列化數據可被用戶控制，如無法避免建議盡量使用白名單校驗的修復方式；

總結

關於反序列化漏洞分析及利用研究的文章不少，但鮮有檢測及修復方面的介紹，本文旨站在應用安全的角度，從安全編碼、代碼審計、漏洞檢測及修復方案對反序列化漏洞進行詳細分享。希望對從事應用安全的朋友有所幫助。文中若有問題之處歡迎指出交流。