挖洞經驗 | 從負載均衡或CDN應用中發現的配置類漏洞
- 2020 年 3 月 31 日
- 筆記
本文分享的Writeup是作者在測試一些目標服務相關的負載均衡或CDN應用時發現的錯誤配置型漏洞，這些漏洞有些發生服務端犄角旮旯的響應消息中，可能很少會引人注意，我們一起來看看。
前言
當針對一個Web應用測試目標進行漏洞分析時，我通常最後都會檢查兩件事：
1、在HTTP響應的Burp歷史記錄中查找一些涉及到的用戶賬戶相關信息，如用戶名、郵箱地址、手機號碼等等； 2、通過Burp被動掃描收集分析HTTP響應中所有郵箱地址。
這樣做的目的是為了尋找更多的攻擊面，特別是針對IDOR或訪問控制類型漏洞時尤為有用。然而這種習慣卻逐漸成了我挖掘奇怪漏洞過程中必不可少的操作，此處我就分享一些類似漏洞安全，希望能對大家起到借鑒作用。
漏洞1：奇怪的負載均衡錯誤配置漏洞（$400）
這個漏洞以前我從沒見過，當我在分析Burp被動掃描收集的HTTP響應消息郵箱地址時，我發現其中一個並不屬於我的Gmail郵箱地址，於是，我就查找這個郵箱的具體歸屬，之後我在其HTTP響應消息中的的某個服務端HTML腳本源碼中發現了它的身影，可見這是一個包含了用戶ID和郵箱的響應：
它看上去非常奇怪，原因在於，當我把這個HTTP響應的主請求重新切換到Repeater中進行請求重發時，響應回來的卻又是我自己相關的郵箱地址、用戶ID和其他賬戶設置，剛剛那個Gmail郵箱地址又神奇的不見了！這是怎麼回事，難道是我收集到了其他用戶的郵箱地址了？
經過一番分析驗證，原來是這樣的，如果當前用戶在沒有特定的用戶「Cookie」信息時，若他對目標服務端發起了請求，那麼就會導致前端的負載均衡應用出現響應錯亂，錯把其他用戶的用戶個人響應到了那個JS腳本中，顯示到了當前用戶的響應消息中。
所以，如果當前用戶把自己的所有Cookie信息刪除後，對目標服務端發起請求，就會在HTTP響應中獲取到其他用戶包括個人郵箱在內的用戶信息。而且，每次執行不同的請求，負載均衡應用就會響應給客戶端不同的其他用戶信息。因此，如果不停的Repeat重放請求，那麼將會以此方式獲取到目標網站中的大量註冊用戶敏感信息。如下變換請求獲得其他用戶的個人註冊信息：
漏洞2：白名單用戶信息泄露漏洞（$800）
有了上個漏洞的基礎，在後續的測試中我就多了一些心眼。這不，幾天之後，我又在一次網站測試中發現了類似漏洞，在某個請求涉及的whitelistExternalUserEmails參數中，服務端響應回來了一個腳本文件，其中包含了17個奇怪的郵箱地址，如下：
於是乎，我在目標網站上對這些郵箱進行了分析，之後發現這些郵箱對應的賬戶都是一些已經存在的有效賬戶。後續我搞明白了，原來這是一些目標網站應用的白名單用戶，用以排除在某種安全限制之外之用（有可能是WAF），但是卻錯誤地配置到了響應的腳本頁面中了。
漏洞3：負載均衡的淺拷貝緩存漏洞
在某次滲透測試中，我發現與第一個漏洞類似的信息泄露問題，同樣是我在查找Burp被動掃描記錄時發現的：
這個漏洞與第一個漏洞的不同之處在於，我無法通過它來收集獲取其他用戶的相關個人信息，但由於這是一個滲透測試項目，我就直接和客戶方進行了交流溝通，之後，客戶方經過調查給我的解釋為：
由於服務後端存在某個對象實體的淺拷貝（Shallow Copy），當對象實體引用了其他用戶數據時就會發生暫時的緩存，當該對象實體返回後，存在該漏洞問題的頁面將會在其中渲染加載**實例信息。
之後驗證發現，這種情況在目標服務端每小時都會發生一次的事，非常難以定位復現，但在我多了個心眼的情況下，好在幫助客戶發現了這個問題。
漏洞4：用戶授權Authorization Header頭信息泄露漏洞
同樣的，在測試某個目標API應用時，當我在檢查HTTP響應中我自己的註冊用戶名時，我發現它竟然包含在了其中一個JS腳本中，該腳本中還包含了我對訪問該API的授權Authorization Header頭信息，這是不是一個跨站腳本包含(XSSI)漏洞呢？
之後，我發現即使把我賬戶相關的會話Cookie刪除之後，發起該請求，一樣還會返回我的用戶名和授權Authorization Header頭信息：
我根本想不到會如此，所以我又接着進行了以下測試：
1、如果更改其中的loc參數，JS腳本響應的消息就會會包括上述用戶相關泄露信息； 2、如果以第二個用戶身份訪問目標API應用，JS腳本中響應的就會是該用戶相關的個人信息； 3、同樣，在第二個用戶會話環境下，即使刪除所有會話Cookie，JS腳本返回的信息依然是第二個用戶的個人信息。
現在來看，由於這是一個JS腳本文件，它由目標API服務的前端CDN執行了緩存，其中包含了loc參數上。有兩種利用方式，一是即使loc參數無效，那麼目標API服務端將會返迴響應用戶的授權頭信息，利用這個點可以構造釣魚鏈接，以無效的loc為參數，發送給受害者，誘惑其點擊，那麼就會把其授權Authorization Header頭信息緩存在JS腳本中。
另一種為有效的loc參數環境下，可以通過loc參數樣式構造字典，對API服務端進行枚舉請求，那麼，將會獲取到一些有效loc參數相關的註冊用戶個人信息。
該漏洞上報後只收穫了$300的獎金，原因在於廠商認為用戶授權頭信息不怎麼敏感，但我認為漏洞還是被低估了。但不管怎麼說，總比三年前發現這種漏洞時要好得多。
總結
漏洞眾測是個特別的行業，除了XSS、CSRF、SQLi等其它通用漏洞的分析外，嘗試進行上述邏輯錯誤配置漏洞的測試，說不定會發現一些獨特的攻擊面。有些測試起初看似沒有意義，但仔細深入就會發現更多隱藏的線索。
*參考來源：medium，clouds 編譯整理，轉載請註明來自 FreeBuf.COM
