[JavaWeb]Shiro漏洞集合——程式碼審計

M發表於2022-01-24

Shiro漏洞集合

Shiro其實就是一組Filter,他會進行驗證,鑑權,會話 Management,再把請求轉到web過濾器。所以最好先去對Shiro有個整體性的瞭解。

復現環境:https://github.com/ttestoo/java-sec-study/tree/main/sec-shiro/java-shiro-bypass
全部的基於這個專案改下shiro的版本就好啦

全文是基於已知spring/tomcat的路徑轉發規則URI處理(漏洞),訪問/x/s/==/x/s。有機會再去跟下tomcat的處理邏輯,這裡一個問題很容易跑偏

Shiro682

這個漏洞感覺更像是springweb的漏洞,我也不知道為啥叫shiro的洞。請求路徑為 /x/s/ ,正常情況下,不就應該是訪問不到該檔案嘛,我的shiro沒匹配到也是很正常啊,結果spring直接允許 /x/s/===/x/s,導致了這個漏洞,最後還讓shiro背鍋。雖然說吧Shiro確實就是起防護的作用的,但我還是心不甘。。。

image
這裡直接訪問/admin/index是會重定向到/login的

image
但是訪問/admin/index/後卻會成功繞過驗證

漏洞分析

image

在這裡主要是拿著url路徑去匹配過濾器的路徑規則,用以判斷是否需要進入驗證\鑑權等Filters

image

直接跟到AntPathMatcher#doMatch操作,進行路徑分析

說一下簡要的匹配規則:就是先以/分隔符將匹配串和路徑串切割成陣列,然後將每個陣列裡的字串進行比較,知道匹配完或者出現不一致,然後進入結果判定,對於因為**而產生不一致,導致比較結束的,都返回匹配成功,如果是完全一樣也會匹配成功,而完全成功匹配的就會進入對於的FilterChain,例如LoginFilter進行驗證。看下圖中可以發現,它還會對最後是否有/進行判斷,當我們使用/admin/index/時,匹配到/admin/index時,由於最後沒有/所以顯示不匹配,既然不匹配,那就不會進入FilterChain。但可惡的是/admin/index/到了web中卻會被fix下,變為/admin/index,Shiro確實做到了嚴格匹配,但web卻瞎搞,所以我才覺得這個洞屬於Shiro有點。。

image

所以最終就可以利用/admin/index/進行繞過了

漏洞修復

image

官方就直接加了一種判斷,會把路徑後面多的/給刪了;但是個人覺得可以將原來程式碼的判定是否都有/ 刪除就好,只要/中間的字元不匹配,就返回false,反之則返回true,應該就可以解決問題

CVE-2020-1957

漏洞簡介

  • 當使用http://127.0.0.1:9091/;admin/index 會跳轉到/index介面;而當使用http://127.0.0.1:9091/;/admin/index,又可以直接跳到/admin/index介面從而造成未授權訪問漏洞
    image
    image

漏洞分析

image

  • 直接訪問/;/admin/index
    image

  • 可以看到,到FilterChain時的字串還是傳進入的/;/admin/index,但經過getPathWithinApplication()處理後的卻只有/,說明是無法識別分號。而/肯定是無法滿足需要進行過濾的匹配串,所以就不會進入指定的登陸驗證
    image
    可以看到其中以分號進行了截斷

在對getPathWithinApplication()進行跟入分析的時候,直接發現了另外一個二次URL解碼+用原資料驗證的漏洞。也就是後續的CVE-2020-11989。
image

image

  • 等判斷鏈結束後,卻發現傳入的是原來的/;/admin/index,這也就導致了後續的解析漏洞

Shiro的驗證繞過原理已經搞清楚了,接下來是弄清楚,為什麼像 /;/admin/index這種路徑,在後端會被成功解析為/admin/index,並進行了拼接(測試盲猜又是對其進行了分號截斷,但擷取的是後面的部分)

漏洞修復

image

由原來直接獲取,到後來利用上下文獲取。 統一了request.getServletPath()來處理路徑再進行比較,這裡是Shiro主動去相容Spring和tomcat

image

CVE-2020-11989

在上面的過程中已經發掘了,就不再分析了

漏洞修復

image

image

下面是1.5.2版本之前的,又給改了回來。

image

修改後採用的和tomcat後端獲取的方式一樣,這樣就統一了。

本來先想著不研究為什麼惡意payload的到了web端可以被解析為正常的資源路徑,因為那是後面的事,我們的目標就是繞過Shiro。但轉頭一想繞過Shiro不簡單,直接/;;;??一通,這樣Shiro不就可以繞過了。畸形路徑好弄,解釋不了的是為什麼伺服器可以處理畸形路徑到正確的路徑資源???,否則上面講的都是無意義的。(其實我就不喜歡那種說一半的文章,總是讓人琢磨不清,很多細節的東西都不講明白,不過我也是菜鳥,我只是儘量解釋清盲點)

這裡可以另外一篇文章進行分析:Tomcat URL解析差異性導致的安全問題(本來想自己寫,後面發現這篇文章講的很詳細,已經可以把上述的問題解釋清楚了)

相關文章