實戰 | 記錄一次JWT的越權滲透測試
簡單介紹：
在一次某行動暫停之后，某單位重新對自身的業務進行了評估，系統業務使用SSO進行登錄，而這個SSO登錄后的子系統訪問采用JWT進行認證，因此有了這一個漏洞的發生，漏洞利用較為簡單，各位師傅請見諒。
Oracle WebCenter
?在這個業務中，登陸口的校驗是采用Oracle WebCenter進行認證的，也就是說在系統最初的登錄，流量是走到Oracle WebCenter中進行認證的。
Oracle WebCenter是面向社交業務的用戶參與平臺。其上下文相關的協作工具可優化人員、信息和管理軟件間連接，幫助員工更高效地協作，并可確保用戶在其所處的業務流程環境下訪問適當的信息。簡單的來說它有點像一個簡單的OA系統。
JWT
?JTW全程是Json Web Token,是目前最流行的跨域認證解決方案。之前遇到的JWT漏洞情況，可能大多數都是在一開始的登錄驗證下，通過修改token字段以三個點分割的BASE64字符串。
第一個字符串為JWT頭，一般base64解碼后長這樣
{“kid”:”keys/3c3c2ea1c3f213f649dc9389dd71b851",”typ”:”JWT”,”alg”:”RS256"}
第二個字符串為賬戶
第三個字符串為簽名
簽名一般不能直接用base64解出來，因為它可能常帶有下劃線，簽名獲取的過程稍微比較復雜，不過我們可以知道簽名是為了防止數據被篡改，而簽名使用的算法就是我們的哥字符串JWT頭的Json字段alg。
大部分JWT常用的三種關于利用Token的攻擊方式：未校驗簽名，禁用hash，爆破弱秘鑰
此部分內容可以參考https://xz.aliyun.com/t/2338
其中，未校驗簽名的情況，我們可以直接修改的那個賬戶字符串，既
{"sub":"xxxx11111這里修改，然后重新生成Token，如果沒有校驗簽名則可以進行越權"}
禁用Hash,既第一個JWTheader頭的alg值為None,我們可以將HS256篡改為None，然后使用Python pyjwt進行Token的生成。
最后爆破弱秘鑰是最常見的，也是比較現實的一種情況
利用腳本來進行爆破 https://github.com/ticarpi/jwt_tool
本次的場景
首先打開網頁，需要通過SSO的oracle webcenter認證，在進入系統中，存在許多業務，而對于子業務系統的認證，則采用的是JWT的認證。接下來將從流程來講解此次漏洞的挖掘。
1、因為這里沒有截圖了，所以只能用文字描述。首先，在進入系統后，很多業務選項按鈕，比如物流系統，金融系統。我們點擊金融系統的時候，會發出第一個包，通過Oracle Webcenter來校驗當前賬戶是不是有效，如果有效，則返回一個Json格式的S。
2、在驗證了當前的賬戶有效的時候，會發出第二個包，請求一個OAM接口想獲取一個JWT token，這個OAM接口會帶上Cookie字段的Sessionid值，證明自己賬戶現在的狀態真的是有效的，當這個OAM接口后接受SessionId的值后，就會返回一個JWT authorizationToken值。
3、當獲取了JWT authorizationToken值后，證明JWT認可了你這個賬戶了，那么此時系統在第三個包發生的時候自動帶上JWT authorizationToken字段放到header頭去請求資源，此時系統返回UID等敏感信息
4、沒錯！越權來了。第三個包返回的信息其中的UID和JWT authorizationToken作為憑證來對這個子業務系統進行訪問。但是這里的UID和JWT authorizationToken并沒有做嚴格校驗，導致可以通過遍歷UID來實現越權訪問
看到這個是不是就是我們非常熟悉的JWT認證Token值，以點分割三個成三個的base64編碼字符串，這個User Token作為這個子系統訪問認證的最后一關
5、其實到第4步的時候，漏洞利用就結束了，其實就是一個簡單的越權而已，但是我想把后面的幾個過程也簡單一下。既然成功越權了，那么這一步系統就開始逐漸返回屬于這個系統原本的東西了。這里利用UID和Token獲取系統的分組權限信息。
6、獲取此賬戶在這個系統中未讀取得信息
7、在get請求處獲取了UID值，為了獲取菜單信息。而我們也可以通過此處的越權，更方便的爆破ID。
8、獲取baseinfo，賬戶的基本信息，內容
9、最后一個包，獲取剩余信息，例如按鈕，選項之類。
因此整個利用的漏洞非常簡單，通過第7步的API來進行爆破，然后再逐步放入第4步的UID修改包中，那么就可以實現對此子業務系統的任意用戶登錄了。
越權前后的兩個截圖比較，多了兩個功能，并且兩張圖的賬戶名都為AAA，原因是因為auth Token記錄的第二個base64字符串記錄的就是賬號信息，而這個賬號信息從始至終都未改變，因此賬戶名不變，而權限管控在UID部分。也是比較不應該了。
修復
恢復authorizationToken，同時校驗uid、user、authorizationToken中的用戶是否一致
在滲透測試的時候，盡量不要放過每一個包，多看看抓包的history的記錄。
對于菜雞來說，滲透就在于細心與更細心罷了
