java反序列化漏洞exp

Ⅰ weblogic 10.3.5 java 反序列化漏洞 影響嗎

收到影響的，建議修補。
以下版本的weblogic收到此專漏洞屬影響:
- 9.2.3.0
- 9.2.4.0
- 10.0.0.0
- 10.0.1.0
- 10.0.2.0
- 10.2.6.0
- 10.3.0.0
- 10.3.1.0
- 10.3.2.0
- 10.3.4.0
- 10.3.5.0
- 12.1.1.0

Ⅱ xmldecoder反序列化漏洞分析

java提供了很多xml文檔解析的類庫，包括dom4j，domj，SAX等庫，可以進行xml文檔的解析，這些庫的使用不當，會導致XXE漏洞的發生，但是這些類庫中，SAX庫允許自己去定義整個xml文檔處理的handler，可以在xml文檔解析的過程中，對解析出來的節點進行一些操作

而為java反序列化定義的handler，會導致一些java反序列化的問題的發生

poc：

獲取到文件內容之後，用XMLDecoder解析，在下面調用了readObject方法

進入readObject方法中

這里對文檔進行了解析，而XMLDecoder.this.handler其實就是
DocumentHandler

這個handler很重要，所有反序列化的操作都是在這個類中進行的

之類通過SAXParserFactory實例化了一個SAXParser的實例，並且調用了其中的parse方法

復現過java XXE漏洞的師傅應該看見過SAXParser的用法，它允許用戶自己去定義處理文檔的handler

可以看到，用戶可以將自己定義的Handler，只要這個類繼承了DefaultHandler，可以看一下官網的例子：

自己的Handler可以在解析的不同階段，進行不同的操作，這個特點就讓xml文檔成為了可以進行java序列化的載體，DocumentHandler這個handler就是處理xml文檔反序列化的

接下來，調用SAXParser對xml文檔進行解析，在對一些屬性的設置以後，真正的解析流程在XML11Configuration這個類中的parse方法中開始

首先是對實體的解析：

因為我們的文檔中並沒有xml實體，所以這一步不用關注

之後進行文檔的解析

進入到scanDocument函數中

這里通過next函數，解析了文檔，並且返回當前解析的狀態，整個文檔的具體解析過程在這個類的ContentDriver類中，裡面的解析過程很復雜，具體的解析過程不要過於關注，重點在解析出來的結果的處理上

當發現當前的文檔為根節點的時候，調用fContentDriver的next方法，在這里進行ROOT節點的解析

一直到的scanStartElement方法中

在之類對文檔進行解析，調用scanName解析出來第一個節點名為：java

之後尋找java節點的結束字元在哪，並且解析出來中間的所有屬性

在解析結束以後，會將這個節點中的所有屬性添加到fAttributes中

最後來到startElement函數中，可以認為fElementQName就是我們的節點名稱，fAttributes就是這個節點中所有屬性組成的一個字典

最後調用到DocumentHandler的startElement才到真正反序列化的地方

到這里，一個節點的解析就算結束了，頭都看大了，先附上一張調用棧，再到DocumentHandler中看具體的反序列化過程

在最後，調用了DocumentHandler.startElement函數，我們進入看一下

在這里會根據不同的節點實例化不同的節點Handler

this.handlers中尋找java節點對應的handler，可以看一下this.handlers裡面所有的handler都是什麼，它是一個HashMap，在屬性中有定義 private final Map<String, Class<? extends ElementHandler>> handlers = new HashMap();

在構造方法中，對handlers進行了賦值

這也就是XMLDecoder所有支持的節點類型，不同的節點會調用不同的ElementHandler進行處理，我們的java節點，應該是被JavaElementHandler處理的

回到startElement的方法中

在實例化JavaElementHandler類以後，調用了setParent將上一次的handler保存，這一步相當於將每一個節點的處理類串成了一個鏈

這一步獲取到所有的節點屬性，並且調用處理handler自己實現的addAttribute方法，可以看一下JavaElementHandler的addAttribute

這里通過我們設置的class屬性的內容，獲取了對應的類，也就是java.beans.XMLDecoder類的class

之後調用對應handler的startElement，而java的handler沒有操作，所以進行下一個節點的解析

下一個節點是object，具體解析流程就不再分析

object對應的Handler為ObjectElementHandler，可以發現，startElement中的重點其實就是每個Handler的addAttribute方法和startElement方法

調用父類的addAttribute方法

這一步獲得了ProcessBuilder的class

處理handler：ArrayElementHandler
addAttribute：

這里定義了數組元素的類型和數組大小

startElement：

這里實例化了一個數組元素，並且返回了一個ValueObject對象

void節點比較特殊，void節點其實是object節點的一個子類，它本身沒有定義什麼方法

我們可以不用過多的關注void節點的處理規則，只需要理解它的作用就是聲明一個變數就可以，可以這么理解：

在一個節點處理結束以後，會由內向外依次調用每個節點的endElement方法

比如我們的poc

在解析完touch的string節點的之後，觸發string的endElement，主要就是將將值設置為StringElementHandler的屬性

之後向ArrayElementHandler中的數組添加進去這個String，對每個element都會調用getValueObject方法，而其中

void節點的endElement很有意思

看一下getContextBean方法

這里會獲取上一個Handler的ValueObject的值，而這個ValueObject的value就是我們在屬性中定義的對象，void節點的上一個節點是array節點，我們在array節點中定義了一個大小為2的String數組，所以獲取到的ValueObject就為這個數組

因為我們只設置了void的屬性為index="0"，所以會進入到var4=set的條件中

最後的Express類，相當於是對var3這個對象調用其中的var4的方法，參數為var2，這樣，就為這個String數組賦值了第一個值為touch

來到第二個void標簽

當來到 <void method="start"/>

進入到getContextBean

在這里調用了parent的getValueObject方法，也就是object標簽

獲取了ObjectElementHandler中的ProcessBuilder對象

最後調用start執行命令

Ⅲ 5.java反序列漏洞，涉及到哪些中間件

Boss、Jenkins、OpenNMS這些大名鼎鼎的Java應用，實現遠程代碼執行。
然而事實上，博客作者並不是漏洞發現者。博客中提到，早在2015年的1月28號，Gabriel Lawrence (@gebl)和Chris Frohoff (@frohoff)在AppSecCali上給出了一個報告[5]，報告中介紹了Java反序列化漏洞可以利用Apache Commons Collections這個常用的Java庫來實現任意代碼執行，當時並沒有引起太大的關注，但是在博主看來，這是2015年最被低估的漏洞。
確實，Apache Commons Collections這樣的基礎庫非常多的Java應用都在用，一旦編程人員誤用了反序列化這一機制，使得用戶輸入可以直接被反序列化，就能導致任意代碼執行，這是一個極其嚴重的問題，博客中提到的WebLogic等存在此問題的應用可能只是冰山一角。
雖然從@gebl和@froh

Ⅳ java 反序列化報錯 提示：java.io.StreamCorruptedException 異常

感覺是你while語句那塊的問題，while(ois.readObject() != null)這條語句表明從對象流中讀取一個對象，此時對象流已經從文件中讀取了位元組序列並且創建了一個對象的實例。而你又在while語句中再次調用ois.readObject(),對象流會再次讀取文件中的位元組序列去反序列化對象，如果文件已經到了EOF,就會出現問題。感覺ObjectInputStream還是別用在while循環中

Ⅳ 一個完整的滲透測試流程，分為那幾塊，每一塊有哪些內容

包含以下幾個流程：

信息收集

第一步做的就是信息收集，根據網站URL可以查出一系列關於該網站的信息。通過URL我們可以查到該網站的IP、該網站操作系統、腳本語言、在該伺服器上是否還有其他網站等等一些列的信息。

漏洞探測

當我們收集到了足夠多的信息之後，我們就要開始對網站進行漏洞探測了。探測網站是否存在一些常見的Web漏洞，比如：SQL注入 。

漏洞利用

探測到了該網站存在漏洞之後，就要對該漏洞進行利用了。不同的漏洞有不同的利用工具，很多時候，通過一個漏洞我們很難拿到網站的webshell，我們往往需要結合幾個漏洞來拿webshell。

內網滲透

當我們能跟內網主機進行通信後，我們就要開始進行內網滲透了。可以先使用nmap對內網主機進行掃描，探測在線的主機，並且探測其使用的操作系統、開放的埠等信息。

內網中也有可能存在供內網使用的內網伺服器，可以進一步滲透拿下其許可權。

痕跡清除

達到了目的之後，有時候只是為了黑入網站掛黑頁，炫耀一下；或者在網站留下一個後門，作為肉雞，沒事的時候上去溜達溜達；亦或者掛入挖礦木馬。

撰寫滲透測試保告

在完成了滲透測試之後，就需要對這次滲透測試撰寫滲透測試報告了。明確的寫出哪裡存在漏洞，以及漏洞修補的方法。以便於網站管理員根據我們的滲透測試報告修補這些漏洞和風險，防止被黑客攻擊。

Ⅵ java反序列漏洞，涉及到哪些中間件

目前復oracle還沒有在公開途徑發制布weblogic的JAVA反序列化漏洞的官方補丁，目前看到的修復方法無非兩條：
使用SerialKiller替換進行序列化操作的ObjectInputStream類;
在不影響業務的情況下，臨時刪除掉項目里的 "org/apache/commons/collections/functors/InvokerTransformer.class"文件。
ObjectInputStream類為JRE的原生類，InvokerTransformer.class為weblogic基礎包中的類，對上述兩個類進行修改或刪除，實在無法保證對業務沒有影響。如果使用上述的修復方式，需要大量的測試工作。且僅僅刪除InvokerTransformer.class文件，無法保證以後不會發現其他的類存在反序列化漏洞。