安全認證相關漏洞挖掘：高級攻防01 - 網安 - 專業的網絡安全產業、社區、知識平臺

拿到一個系統后，很多情況下只有一個登錄入口。如果想進一步得到較為高危的漏洞，只能去尋找權限校驗相關的漏洞，再結合后臺洞，最終得到一個較為滿意的漏洞。

這里列出一些較為常見的安全認證配置：

Spring Security
Apache Shiro
服務器本身(Tomcat、Nginx、Apache）401 認證
Tomcat 安全認證(結合Web.Xml) 無需代碼實現
JSON Web Token

以上只是簡單列出了一些筆者見過的、常見的安全認證配置組件。不同的鑒權組件存在異同的審計思路。

1 尋找未授權

這是筆者首先會入手去看的點，畢竟如果能直接從未授權的點進入，就沒必要硬剛鑒權邏輯了。

1.一些第三方組件大概率為未授權應用

Druid、Webservice、Swagger等內置于程序中的應用大多被開發者設計為無需權限校驗接口。

第三方組件本身又存在歷史漏洞，且以jar包的形式內置于應用中，低版本的情況很常見。

利用Druid的未授權獲取了管理員session：

2.安全認證框架配置中存在的未授權接口

出于業務需要或者開發失誤，開發者會對外開放一些接口，這些接口無需訪問權限。

細心查看配置文件中各個Filter、Servlet、Listener，可能有意想不到的收獲。

Web.Xml

這里是以攔截器的方式，對外開放了未授權請求處理：

Spring-mvc.Xml

Tomcat 安全配置

Apache Shiro、Spring Security等支持以@Configuare注解方式配置權限認證——只要按照配置去尋找。當然以上框架也支持配置文件方式配置，尋找思路一樣。

配置類

3.未授權訪問接口配合ssrf獲取localhost本身需鑒權服務

一些多服務組件中，存在服務之間的相互調用。服務之間的相互調用或許不需要身份校驗，或者已經配置了靜態的身份憑證，又或者通過訪問者IP是否為127.0.0.1來進行鑒權。

這時我們需要一個SSRF漏洞即可繞過權限驗證。很經典的為Apache Module mod_proxy場景繞過：SSRF CVE-2021-4043。

2 安全認證框架本身存在鑒權漏洞

1.Apache Shiro

Shiro相關的權限繞過漏洞，我覺得可以歸類到下面的路徑歸一化的問題上。

2.Spring Security

某些配置下，存在權限繞過——當配置文件放行了/**/.js時。

3.JWT 存在的安全風險

敏感信息泄露
未校驗簽名
簽名算法可被修改為none
簽名密鑰爆破
修改非對稱密碼算法為對稱密碼算法
偽造密鑰(CVE-2018-0114)

jwt測試工具：

https://github.com/ticarpi/jwt_tool

3 靜態資源訪問

靜態資源css、js等文件訪問往往不需要權限，開發者可能將鑒權邏輯放在Filter里。當我們在原有路由基礎上添加.js后綴時，即可繞過驗證。

這里可能會有一個問題，添加了.js后綴后是否還能正常匹配到處理類呢？

答案是，在spring應用里是可以的。默認配置下的spirng configurePathMatch支持添加后綴匹配路由，如果想開啟后綴匹配模式，需要手動重寫configurePathMatch方法：

4 路徑歸一化問題

1.簡單定義

兩套組件對同一個URI解析，或者說處理的不一致，導致路徑歸一化問題的產生。

orange 的 breaking parser logic是他在2018黑帽大會上的演講議題，后續許多路徑歸一化的安全問題，都是延伸自他的PPT。

2.Shiro權限繞過漏洞

一個很經典的路徑歸一化問題，導致權限的繞過，比如Shiro CVE-2020-1957。

針對用戶訪問的資源地址，也就是URI地址，shiro的解析和 spring的解析不一致。

shiro的Ant中的*通配符匹配是不能匹配這個URI 的/test/admin/page/。shiro認為它是一個路徑，所以繞過了/test/admin/*這個ACL。

而spring認為/test/admin/page和/test/admin/page/是一樣的，它們能在spring中獲取到同樣的資源。

3.CVE-2021-21982 VMware CarbonBlack Workstation

算是一個老1day了，組件本身身份驗證通過Spring Security + JWT來實現。且存在兩套url的處理組件：Envoy以及Springboot。

PS：Envoy是專為大型現代SOA（面向服務架構）架構設計的L7 代理和通信總線。

通過diff可以定位到漏洞點，一個本地獲取token的接口：

但是我們通過外網直接訪問無法獲取到token：

簡單了解一下組件的基本架構：

抓一下envoy 與本機服務的通信。rr師傅yyds：

“./tcpdump -i lo -nn -s0 -w lo1.cap -v”

envoy本身起到一個請求轉發作用，可以精確匹配到協議ip端口 url路徑等，指定很詳細的路由轉發規則，且可以對請求進行轉發和修改：

url編碼即可繞過envoy的轉發規則，POC如下：

由于envoy轉發規則不能匹配URL編碼，但Springboot可以理解，兩個組件對url的理解不同，最終導致漏洞產生。

3.Other

擴展一下思路，當存在一個或者多個代碼邏輯處理url時，由于對編碼、通配符、"/"、";" 等處理的不同，極有可能造成安全問題。

5 Apache、Nginx、Jetty、HAProxy 等

Chybeta在其知識星球分享了很多：

Nginx 場景繞過之一: URL white spaces + Gunicorn

https://articles.zsxq.com/id_whpewmqqocrw.html

Nginx 場景繞過之二：斜杠(trailing slash) 與 #

https://articles.zsxq.com/id_jb6bwow4zf5p.html

Nginx 場景繞過之三：斜杠(trailing slash) 與 ;

https://articles.zsxq.com/id_whg6hb68xkbd.html

HAProxy 場景繞過之一: CVE-2021-40346

https://articles.zsxq.com/id_ftx67ig4w57u.html

利用hop-by-hop繞過：結合CVE-2021-33197

https://articles.zsxq.com/id_rfsu4pm43qno.html

Squid 場景繞過之一: URN bypass ACL

https://articles.zsxq.com/id_ihsdxmrapasa.html

Apache Module mod_proxy 場景繞過：SSRF CVE-2021-4043。

6 簡單的fuzz測試

造成權限繞過的根本原因可能有多種，但是不妨礙我們總結出一些常見的繞過方式——編碼、插入某些特定字符、添加后綴等。遠海曾公布一個權限繞過的fuzz字典：

最后，放上參考鏈接，大家可以自行學習。

https://wx.zsxq.com/dweb2/index/group/555848225184

https://www.vmware.com/security/advisories/VMSA-2021-0005.html

https://cloud.tencent.com/developer/article/1552824