CVE-2017-14322 登錄認證繞過分析

安全脈搏SecPulse.Com獨家發文，如需轉載，請先聯繫授權。

首先這並不是一篇翻譯文章，是看了原文之後我對這個漏洞的一點分析和理解。

https://security.infoteam.ch/en/blog/posts/narrative-of-an-incident-response-from-compromise-to-the-publication-of-the-weakness.html

Interspire Email Marketer 是一款商業軟體，在6.1.0之後的版本由於錯誤使用邏輯運算符和忽視弱類型特點產生了安全問題，並在6.1.6做了修復，但中間竟然相隔了5年之久，最坑的是好像更新版本還需要支付額外的費用～

作者是在對客戶進行應急響應時發現了這個0day，其應急過程和思路很值得學習和思考。

深入分析：

先是客戶發現某個賬戶發郵件異常，作者通過排查Web日誌定位問題，注意到藍色框是referer欄位，表示這條訪問記錄是從Google過來的，非常像是 Google Hacking 手法，

這個IP使用GET訪問了管理後台頁面大小是5197，緊接著又一個GET訪問這時響應變成了302並且頁面大小變成了33478，這表明已經登錄成功進入後台了，

非常奇怪，因為並沒有通過表單驗證帳密，僅使用兩個GET是不足以完成正常的登錄認證流程。

這時應急就要考慮可能是身份憑證泄漏或者認證繞過等漏洞，因為種種跡象表明肯定和cookie有關係，但是使用Google Hacking這種撒網式攻擊並不符合XSS之類的攻擊流程，

雖然我也去看了一下cookie也沒有加HttpOnly。

既然判斷前者可能性較低那就著重排查一下是不是有認證繞過之類的漏洞吧

作者也是很有經驗，首先就去看了處理cookie認證那部分代碼，有幸我在網上找到了6.1.2版本的源代碼，可以一窺究竟。

在./admin/com/init.php:484~509行，這是出現漏洞的代碼，有兩個問題

1、使用 == 進行判斷，會受PHP弱類型特性影響，進行強轉

2、整套源碼中多處使用 ! 寫法，猜測這裡開發者可能錯誤理解了 ! 的作用，原意可能是對比 $tempUser->settings["LoginCheck"] == $tempCookie["rand"] ，如果相等則為真，然後用 ! 取反，這樣就不會進入到這個 if 判斷里，但是用法錯誤，因為 ! 的優先順序比 == 要高

下面這個測試就是很好的證明

首先 "1" === 1，必然是False，因為類型不同 然後 !"1"===1，結果也是False，可見並不是先進行"1"===1的判斷再取反

先看一下 $tempCookie 來源是 IEM::requestGetCookie("IEM_CookieLogin", array())

requestGetCookie函數在./admin/com/lib/IEM.class.php:242~249行，是 IEM_CookieLogin base64解碼後在反序列化

在./admin/functions/login.php:200~207行，調用requestSetCookie()設置兩個cookie

$_COOKIE["IEM_CookieLogin"]的值是 usercookie_info 傳參到 requestSetCookie 函數進行序列化然後base64編碼。

既然知道了cookie的演算法，我們就可以控制 IEM_CookieLogin 的值

再來看一下 $tempUser->settings["LoginCheck"] 是從哪裡過來的，跟進 Load 函數，發現是從資料庫里取出的數據

還記得這些代碼嗎?

$tempUser->settings["LoginCheck"] 值為 15aee9a0b0cd9b ，取反後為 False，然後$tempCookie是IEM_CookieLogin經過base64_decode後反序列化，得到是一個數組，取出數組中的rand做對比

所以只要設置$tempCookie["rand"]值是 True 就可以了，利用PHP弱類型的特點，$tempCookie["rand"] 可以是任何值，當然不能為空或者0

Payload:

原作者則是利用序列化可以設置key數據類型，將rand設置一個布爾型，這樣即使用 === 全等也可以繞過

新版是怎麼修復的呢？拿到 6.16 的代碼 diff 一下，哈哈，這樣判斷應該就萬無一失了，除非 $tempUser->settings["LoginCheck"] 能返回假，但是在 ./admin/com/init.php 也做了判斷應該繞不過了。

應急處理:

在遭到這類漏洞攻擊的情況下，我們首先要做的是更改相關服務的登錄憑據以限制攻擊。

然後當然是修復漏洞，加固應用啦。

相關參考:

https://github.com/joesmithjaffa/CVE-2017-14322 http://php.net/manual/zh/language.operators.precedence.php https://blog.csdn.net/iamduoluo/article/details/8491746

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！