跳到主要內容
CVE漏洞經驗及分析
CVE漏洞經驗及分析
作者：Noth
前言 :
Noth 平時喜歡挖掘 Web 漏洞，以及研究相關漏洞知識，前些日子挖掘到CVE漏洞 (CVE-2020-15600，CSRF)，發現 CVE 漏洞之後，接下來就是要去分析漏洞發生成因，去判斷哪行程式碼是出現問題，導致漏洞產生，知道漏洞發生的來龍去脈，將來對修補漏洞上也是有幫助的，於是寫這一篇文章和大家分享。
介紹 CSRF 漏洞 :
CSRF(跨站請求偽造)，One-Click Attack 或者 Session Riding，通常縮寫為 CSRF 或者XSRF， 是一種挾制用戶在目前已登入的Web應用程式上執行非本意操作的攻擊方法。
基礎原理：
用戶登入原網站，瀏覽器會紀錄 Cookies，如果用戶未登出或 Cookies 並未過期(用戶關閉瀏覽器不代表網站已登出或Cookies會立即過期)。在這期間，如果用戶造訪其他危險網站(第三方)如果用戶點擊了攻擊者的連結，便會向原網站發出某個個功能請求（增加刪除修改)，原網站的伺服器接收後會被誤會以為是用戶合法操作。
可以總結一個核心價值 : CSRF 是基於網站對於瀏覽器的信任
示意圖 :
(圖:取自網路圖庫)
內文 :
一般 CSRF 危害性能夠利用使用者的 Cookie 進行非預期的操作(增加、刪除、修改)
這次挖掘的 CVE-2020-15600 是屬於登入點的 CSRF，危害性相對比較低。
上圖是前端表單登入頁面，下圖是表單的 HTML 程式碼，筆者看到這個程式碼時直接猜想可能存在 CSRF 漏洞，因為通常表單必須要有 Token (令牌) 去做相關的使用者身分驗證，判斷是否為相同使用者。
接下來我們直接跟進去 uno.php 檔案，查看相關的程式碼，去驗證是否的確是如我們所猜想的存在 CSRF 漏洞，33 行判斷user、pass變數是否存在，34行進行生成新的 Session ID 並替換原有舊的 Session ID，並保留當前會話，發生漏洞的點是在第 37 行，首先他先判斷文件是否可寫，由使用者輸入的帳號、密碼與資料庫做匹配，但過程中並沒有做額外的 CSRF 防禦機制，導致漏洞產生。
繼續追一下 f_check_pass 函式
f_check_pass 函式定義了3個參數，169行檢查指定函數是否被定義及引入uno/includes/password_hashing.php 檔案，接下來以substr函式判斷從變數b返回的字符串是否等於 $ 及長度是否等於 60，password_verify函式用來驗證密碼及hash值是否匹配，$a 是我們傳入變數 pass的值，$b 這裡指的是處理過的 hash，但如果 $b 不是hash且值與$a相同，他會把 $b 進行 PASSWORD_BCRYPT 加密，173行把字串寫入 uno/password.php 檔案，通過分析 f_check_pass 函式，我們可以知道是用來確認使用者密碼是否正確。
接下來我們構造表單PoC進行驗證 :
結論 :
在做白箱 Code Review 時，需要去想是否有可控點(可利用)，從不一樣的思維去想是否有漏洞的可能，並進一步大膽猜測並實際驗證，從防禦的角度來看，防禦CSRF漏洞可以去驗證Referer，判斷請求的域是否相同以及增加 CSRF_Token 令牌去做使用者的身分驗證。
Reference :
留言
張貼留言