shiro<1.2.4反序列化分析
0x01、環境搭建
下載地址：//codeload.github.com/apache/shiro/zip/shiro-root-1.2.4
環境：Tomcat 8.5.27 + idea 2020.2 + jdk 1.8 +maven 3.6
下載之後之後直接打開，並open這個web文件夾即可，其他自行百度就行，其中還需要導入一些jstl的jar等等
0x02、漏洞原理
shiro默認使用了CookieRememberMeManager，其處理cookie的流程是：
得到rememberMe的cookie值 --> Base64解碼 --> AES解密 --> 反序列化
然而AES的密鑰是硬編碼的，就導致了攻擊者可以構造惡意數據造成反序列化的RCE漏洞。
payload 構造的順序則就是相對的反着來：
惡意命令-->序列化-->AES加密-->base64編碼-->發送cookie
在整個漏洞利用過程中，比較重要的是AES加密的密鑰，該秘鑰默認是默認硬編碼的，所以如果沒有修改默認的密鑰，就自己可以生成惡意構造的cookie了。
shiro特徵：
- 未登陸的情況下，請求包的cookie中沒有rememberMe字段，返回包set-Cookie里也沒有deleteMe字段
- 登陸失敗的話，不管勾選RememberMe字段沒有，返回包都會有rememberMe=deleteMe字段
- 不勾選RememberMe字段，登陸成功的話，返回包set-Cookie會有rememberMe=deleteMe字段。但是之後的所有請求中Cookie都不會有rememberMe字段
- 勾選RememberMe字段，登陸成功的話，返回包set-Cookie會有rememberMe=deleteMe字段，還會有rememberMe字段，之後的所有請求中Cookie都會有rememberMe字段
0x03、漏洞復現
復現文章//blog.csdn.net/weixin_43571641/article/details/108182722
0x04、漏洞分析
簡單介紹利用：
- 通過在cookie的rememberMe字段中插入惡意payload，
- 觸發shiro框架的rememberMe的反序列化功能，導致任意代碼執行。
- shiro 1.2.24中，提供了硬編碼的AES密鑰：kPH+bIxk5D2deZiIxcaaaA==
- 由於開發人員未修改AES密鑰而直接使用Shiro框架，導致了該問題
4.1、加密
那既然我們要分析，那入口點在哪呢？Shiro≤1.2.4版本默認使用CookieRememberMeManager
而我們看看這邊CookieRememberMeManager類繼承了AbstractRememberMeManager，我們進去看看是什麼梗
我們可以看到這邊這個類裏面有硬編碼。然後它又繼承了RememberMeManager接口；我們繼續進去看看是怎麼回事
看名字的話可以知道這些是登陸成功，登陸失敗，退出的一些service；既然如此，肯定會調用這個登陸成功的接口，然後再去實現這個接口。所以我們直接在這個接口下個斷點，看看是怎麼個流程；
這裡看到調用了isRememberMe()可以發現這個就是一個判斷用戶是否選擇了RememberMe選項。而我們是勾選了的
所以我們我們條件滿足，這邊判斷返回True，我們則進入this.rememberIdentity(subject, token, info);
subject存儲的一些登陸信息如session等等，而authcInfo存儲的則是用戶名；
而PrincipalCollection是一個身份集合，因為我們可以在Shiro中同時配置多個Realm，所以呢身份信息可能就有多個；因此其提供了PrincipalCollection用於聚合這些身份信息，具體我們不細講，不深入去懂原理。
然後我們再F7繼續跟進this.rememberIdentity(subject, principals);
這我們有點懵，將身份信息幹嘛？我們進入該convertPrincipalsToBytes()方法查看；
看到了serialize()方法，難道這邊開始是進行序列化了還是啥？
通過此處我們可以知道是跳了兩層，到DefaultSerializer類的serialize方法；看到這裡就懂了，這裡先轉為byte，寫入緩衝區；然後進行了一個序列化，最後通過toByteArray()方法返回序列化後的Byte數組。
然後返回到原來的地方convertPrincipalsToBytes()內，接下來if判斷getCipherService()方法不為空，則進入條件裏面裏面。我們f7進去內部看看；
發現又是一個cipherService，這是什麼；我們翻譯一下，因為大部分開發都會用簡稱；
也就是獲取密碼服務？？ 什麼密碼服務？我們再繼續F7跟進發現直接推出了。那我們就 Ctrl+左鍵 繼續進去看。可以，發現是new了一個aes加密服務。
那我們點擊debugger處，回到剛剛那個地方；我們就不用繼續進入了，我們就思考一下，這邊是要獲取到加密服務，如果沒獲取到，則不進入。獲取到的話，則進入該條件；
直接F8下來，進入，然後我們再手動添加變量監視。可以發現正如我們所想的，獲取aes加密服務；
然後調用encrypt()方法，而懂點英文的，都知道這個單詞是加密的意思。那我們初步判斷這是個加密方法。我們f7跟進去看看什麼情況。
我們可以知道這個參數是byte[] serialized，也就是說，此處加密我們剛剛的序列化流的數據。
然後這邊this.getCipherService()我們剛剛手動添加變量查看了，這邊是獲取到了aes加密服務；然後判斷不問空，那肯定不為空啊，剛剛上面分析過了。然後我們進入條件判斷股內部。
ByteSource byteSource = cipherService.encrypt(serialized, this.getEncryptionCipherKey());
這裡調用cipherService.encrypt()方法並且傳入序列化數據，和getEncryptionCipherKey方法。加密過程，我們就應該不怎麼感興趣了；有興趣的可以自己研究
我們通過getEncryptionCipherKey()名字可以知道是獲取key的一個方法。那我們f7進入看看
哦豁，那我們再進一層看一下；發現直接就返回了，emmmmm….怎麼跟別人不一樣。那我們就不追了
第一步有說到，硬編碼存儲在這個地方，而構造方法就在這下面，可以看到這邊設置了key。
我們繼續回到原來的地方，知道這邊是獲取加密的key就ok了。然後這邊使用平台的默認字符集將字符串編碼為 byte 序列，並將結果存儲到一個新的 byte 數組中。那我們加密部分就結束了
4.2、解密
由於此處，我找不到，回溯不到，那咋辦，煩惱；最後想到了我們加密的入口~~
既然自動跳到了這裡，那麼我們就直接在此處下個斷點，重新開始
隨後我們進入這個getRememberedSerializedIdentity()方法，看看是什麼東西。此處我們依然還很懵，沒事；
一直f8，期間倒是沒有什麼有意思或者重點的地方；
直到我們走到這裡，這個有一個this.getCookie().readValue(request, response)，這是要讀取cookice中的數據了，這必須跟入了;
這裡給進到了這個readvalue()方法中了，我們先看看什麼情況。根據名字可以知道是讀取值的一個方法。讀取什麼值？請求包的值。
通過getName()方法得到了key為remeberMe。然後把value置空，再通過getCookie獲取到cookie。最後判斷cookie不為空，則進入內部；隨後獲取到cookie的值；值則為序列化內容。然後再 return回序列化內容；
隨後返回到上一處地方現在remeberMe的值不是delete；而是序列化內容，所以進入到第二個條件分支。
一直到這一步，進行base64解碼，成為二進制數據，給了decoded的byte數組；
得到rememberMe的cookie值 --> Base64解碼 --> AES解密 --> 反序列化
目前只進行了Base64解碼，那還需要aes解碼。我們繼續跟進
返回到了上層，此處我們知道bytes是二進制數據，我們看看條件判斷。當bytes數組不為空且長度大於0時，進入裏面。那我們肯定滿足，所以我們兩步f8加一步F7進入到 convertBytesToPrincipals看看是什麼
可以看出我們接下來的步驟要依依實現了。判斷key不為空，然後進入內部
而從這裡開始，就是進行aes解密的步驟了，我們F7跟進方法查看
這裡重新把惡意的bytes數組重新賦值給serialized，然後再獲取加密服務：AES/CBC/PKCS5Padding
同時到達了下一步；真真正正的開始解密了，其中兩個參數，第一個是加密的bytes數組，第二個是獲取到key，也就是硬編碼；我們 就直接進入decrypt()方法中
解密過程的話，我不擅長密碼學，這種看着我頭暈，涉及到aes啥的加密解密我就會跳過。所以依舊一樣，跳！！！
此處繼續返回到了上一層，我們可以看出這個byteSource是aes解密出來的序列化流，然後再默認字符集將字符串編碼為 byte 序列，並將結果存儲到一個新的 byte 數組serialized中，那接下來我們就差反序列化了
得到rememberMe的cookie值 --> Base64解碼 --> AES解密 --> 反序列化
我們繼續return，返回到上一層
顧名思義，一看名字就知道是反序列化的方法，我們跟進deserialize()方法查看
看到還有一層，我們繼續F7跟進
形成反序列化漏洞的話，沒有readObject()怎麼可能呢？所以我們看到了最後一道光，就這麼愉快的結束了。
0x05、總結
其實這個還是得學習學習加密解密的方法，才能進行編寫poc，但是此處只是了解個思路。具體可參考其他文章；我空餘時間的話，會繼續補全該篇文章，先去搞其他的玩意兒
[P牛博客](//zeo.cool/2020/09/03/Shiro 550 反序列化漏洞 詳細分析+poc編寫/#解密過程：)
//www.anquanke.com/post/id/225442#h2-7
//mp.weixin.qq.com/s/ayZKDVnN7zEbKjo5w8uqxQ
