Apache Shiro 1.2.4反序列化漏洞實例分析

Apache Shiro 1.2.4反序列化漏洞實例分析，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

0x00 Apache Shiro

這個組件的漏洞很久之前就爆出來了，但是最近工作中又遇到了，剛好最近也在看Java反序列化的東西，所以決定拿出來再分析一下，期間也遇到了一些奇怪的問題。

網上的分析文章中大部分都是手動添加了commons-collections4-4.0的依賴，目的是為了使用ysoserial生成的CommonsCollections2這個payload，然而我遇到的情況是使用了CommonsBeanutils1就可以直接打成功，所以這里我們不再重復網上對CommonsCollections2的分析了。

0x01 調試分析

調試環境：

JDK 1.8.0_72

Tomcat 8.0.30

首先我們把shiro的源碼clone回來，并切到有問題的分支上去。

git clone https://github.com/apache/shiro.git shiro-rootcd shiro-root
git checkout 1.2.0

為了能讓shiro自帶的sample跑起來，要對samples/web/pom.xml文件做一些修改，需要將jstl的版本改為1.2，并且刪掉servlet-api的scope字段。同時將jstl-1.2.jar放置在WEB-INF/lib下面。然后應該就可以跑起來并且調試了。

我們將斷點打到org.apache.shiro.mgt.DefaultSecurityManager中的resolvePrincipals方法，并且發送一個帶有rememberMe Cookie的請求，應該就可以斷下來了。

我們繼續跟進這個getRememberedIdentity方法： 

繼續一直跟到getRememberedSerializedIdentity方法： 

在這個方法中，讀出了我們傳入的Cookie，并且進行了base64解碼： 

接下來shiro會調用convertBytesToPrincipals并將base64解碼后的字節數組作為參數傳入：

這里通過函數名也能猜出來，進行了兩個操作，分別是解密和反序列化，我們先來看解密部分，經過簡單的調試后，發現是一個AES解密，并且存在一個預設秘鑰Base64.decode("kPH+bIxk5D2deZiIxcaaaA==");，在shiro自帶的sample中，并沒有通過其他的方式設置這個秘鑰，所以這里用的就是這個預設值。

而AES解密中遇到的IV也是從我們傳入的Cookie中的前幾個字節中獲取的，于是我們可以輕易的構造出包含任意內容的Cookie值，解密好的明文就是序列化的內容，調用了deserialize進行反序列化。

最終會調用到org.apache.shiro.io.DefaultSerializer#deserialize方法進行反序列化：    

整個流程十分簡單，簡要概括一下就是：讀取cookie -> base64解碼 -> AES解密 -> 反序列化

所以我們的payload構造起來也是十分的簡單，完整的PoC我會放到我的GitHub上。

0x02 疑點解惑

在調試的過程中，遇到了一些問題，并沒有成功的彈出計算器，這里記錄一下。

1. 為什么本地搭建環境，使用CommonsBeanutils1打不成功，總是提示ClassNotFound異常？

這個問題我當時調試了好久，一度以為是payload有問題或者shiro的代碼因為年代久遠有了變化，因為當時遇到的case就是這個payload一發入魂的，表示十分的迷茫。后來發現了關鍵問題，我們從github上clone到的sample中，commons-beanutils這個依賴的版本是1.8.3，而ysoserial生成的payload的版本是1.9.2，所以在默認的sample中是無法打成功的。于是我修改版本號到1.9.2，一發入魂。

所以遇到的那個案例中，實際的依賴環境版本可能也是這樣的吧，所以才能直接打成功。

2. 假如我的依賴中就是沒有高版本的commons-beanutils和commons-collections之類的包，怎么利用？

這個項目clone下來之后，可以看到是存在一個commons-collections的包的： 

但是使用ysoserial提供的CommonsCollections1是無法成功的，會爆出一個異常：

這就十分的奇怪了，為什么偏偏無法反序列化byte array類型，調試了一下發現是在這里拋出的異常：

查了一下Java中Class.forName()以及ClassLoader.loadClass()的區別，發現forName()總是使用調用者的ClassLoader()，而loadClass()則是可以自己指定一個不同的ClassLoader。那shiro中的ClasssLoader是怎么來的？是通過Thread.currentThread().getContextClassLoader();獲取的，也就是WebappClassLoader。但是為啥提示無法加載byte array呢，搜索了一番看到了orange博客下面的討論，了解到了整個事情的真相：

Shiro resovleClass使用的是ClassLoader.loadClass()而非Class.forName()，而ClassLoader.loadClass不支持裝載數組類型的class。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。