Apache Spark RPC協議中的反序列化漏洞分析 | 網藤能力中心
前言
在前一陣，Spark官方釋出了標題為《CVE-2018-17190: Unsecured Apache Spark standalone executes user code》的安全公告。
公告中指明漏洞影響版本為全版本，且沒有標明已修復的版本，只有相關緩解措施。
官方緩解措施如下：在任何未受到不必要訪問保護的Spark單機群集上啟用身份驗證，例如通過網路層面限制。使用spark.authenticate和相關的安全屬性。
查詢了相關文件，spark.authenticate是RPC協議中的一個配置屬性，此引數控制Spark RPC是否使用共享金鑰進行認證。
Spark RPCS
park RPC 是一個自定義的協議。底層是基於netty4開發的，相關的實現封裝在spark-network-common.jar和spark-core.jar中，其中前者使用的JAVA開發的後者使用的是scala語言。
協議內部結構由兩部分構成header和body，header中的內容包括:整個frame的長度（8個位元組），message的型別（1個位元組），以及requestID（8個位元組）還有body的長度（4個位元組）
body根據協議定義的資料型別不同略有差異.
RpcRequest訊息型別的body大致由兩部分構造，前半部分包含通訊雙方的地址和埠以及名字資訊，接下來就是java序列化後的內容ac ed 00 05開頭。
訊息型別為RpcResponse的body就直接是java反序列後的內容。
搭建Spark單獨叢集伺服器
從官網下載，然後通過-h指定IP地址，讓埠監聽在所有的網絡卡上./start-master.sh -h 0.0.0.0 -p 70774.
證明服務端存在反序列化過程
spark_exploit.py 通過第一個引數和第二個引數指明遠端spark叢集的連線資訊，第三個引數為JAVA反序列化漏洞payload。
通過呼叫 build_msg 函式將 payload 構建到訊息中再發送給服務端，過程比較簡單。
反向操作客戶端
evil_spark_server.py 指令碼通過繼承BaseRequestHandler類完成了一個簡單的TCP服務，對傳送過來的資料提取出request_id, 然後再呼叫build_msg，將request_id和payload構成合法的RPC響應資料包傳送給客戶端。
啟動服務
使用spark客戶端進行連線
總結
通過抓包看請求資料以及閱讀相關程式碼,逐步確定RPC協議中的請求資料。客戶端和服務端都使用了JAVA序列化來傳輸資料，兩邊都可以進行利用。
當反過頭來想利用反序列化來執行系統命令時，查詢ysoserial發現除利用低版本jdk構造利用鏈外，並無其他合適的gadget。
隨著時間的推移，各個庫中的漏洞都將被修復和升級，已有的gadget將不再起作用。java 反序列化漏洞終將成為歷史。
參考
1、 https://spark.apache.org/security.html
2、 https://zhuanlan.zhihu.com/p/28893155
*本文作者：鬥象能力中心TCC-星光，轉載請註明來自FreeBuf.COM