0x01、環境搭建
下載地址：https://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、漏洞復現
復現文章https://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牛部落格](https://zeo.cool/2020/09/03/Shiro 550 反序列化漏洞 詳細分析+poc編寫/#解密過程：)