挖洞經(jīng)驗(yàn) | PayPal驗(yàn)證碼質(zhì)詢(xún)功能（reCAPTCHA Challenge）存在的用戶(hù)密碼泄露漏洞

近期，安全研究者Alex Birsanl對(duì)PayPal登錄界面的身份驗(yàn)證機(jī)制進(jìn)行分析，發(fā)現(xiàn)了其中一個(gè)隱藏的高危漏洞，可以通過(guò)請(qǐng)求其驗(yàn)證碼質(zhì)詢(xún)服務(wù)端（reCAPTCHA challenge），在質(zhì)詢(xún)響應(yīng)消息中獲取PayPal受害者的注冊(cè)郵箱和明文密碼，危害嚴(yán)重，漏洞最終獲得了PayPal官方$15,300的獎(jiǎng)勵(lì)。

漏洞前言

當(dāng)我們?cè)谧雎┒礈y(cè)試時(shí)，相對(duì)于那些顯而易見(jiàn)的功能應(yīng)用來(lái)說(shuō)，我們還會(huì)去關(guān)注那些未知資產(chǎn)或模糊端點(diǎn)的服務(wù)，有時(shí)候這種犄角旮旯服務(wù)產(chǎn)生的漏洞同樣至關(guān)重要，影響關(guān)鍵。

在面對(duì)測(cè)試目標(biāo)時(shí)，如果你是第一個(gè)關(guān)注它并對(duì)它開(kāi)展測(cè)試評(píng)估的人，那么細(xì)致全面的檢查無(wú)疑會(huì)發(fā)現(xiàn)一些安全問(wèn)題，尤其是一些代碼已經(jīng)成型且處于持續(xù)運(yùn)轉(zhuǎn)的應(yīng)用，若能在這種應(yīng)用功能中發(fā)現(xiàn)安全漏洞，將會(huì)是非常重要非常危急，且收獲頗豐的。本文中，作者就在PayPal用戶(hù)經(jīng)常用到的功能點(diǎn) - 登錄框架中發(fā)現(xiàn)了一個(gè)高危漏洞，我們一起來(lái)看看。

最初研究

我在研究PayPal的驗(yàn)證機(jī)制時(shí)，發(fā)現(xiàn)其auth驗(yàn)證頁(yè)面的一個(gè)javascript腳本文件（recaptchav3.js）中，包含了一個(gè)CSRF token和一個(gè)會(huì)話(huà)ID（Session ID），如下：

這馬上引起了我的注意，因?yàn)樵谟行avascript文件中存在的任何類(lèi)型的會(huì)話(huà)數(shù)據(jù)，都有可能被攻擊者以各種方式檢索獲取到。如用跨站腳本包含（cross-site script inclusion，XSSI)，攻擊者可以用一個(gè)嵌入了HTML<script>的Web頁(yè)面包含進(jìn)惡意跨域腳本，然后通過(guò)該惡意跨域腳本繞過(guò)邊界竊取用戶(hù)存儲(chǔ)在網(wǎng)站中的敏感信息。

由此，我進(jìn)行了一個(gè)簡(jiǎn)單測(cè)試，測(cè)試發(fā)現(xiàn)我猜測(cè)的跨站腳本包含漏洞（XSSI）是確定存在的。盡管每個(gè)Request請(qǐng)求中都會(huì)有一個(gè)javascript混淆方法去隨機(jī)化變量名，但其中敏感的用戶(hù)token還是一樣會(huì)響應(yīng)出現(xiàn)在了之前我們預(yù)計(jì)的位置，如果額外加點(diǎn)料，完全能實(shí)現(xiàn)對(duì)其中敏感信息的檢索提取。

然而，一個(gè)安全問(wèn)題的好壞在于你能用它來(lái)實(shí)現(xiàn)怎樣的安全威脅。因此，有了以上 _csrf 和 _sessionID的發(fā)現(xiàn)，我立即著手對(duì)它們進(jìn)行分析，想搞清楚它們的具體用途和可利用之處。

深入分析

經(jīng)過(guò)無(wú)數(shù)次對(duì)上述PayPal身份驗(yàn)證請(qǐng)求中的CSRF token值（_csrf ）的替換，之后，我認(rèn)為用這個(gè)CSRF token不可能實(shí)現(xiàn)經(jīng)典的跨站請(qǐng)求偽造攻擊（CSRF），同樣，替換_sessionID值也不能實(shí)現(xiàn)對(duì)受害者的冒充。

接下來(lái)，我回到了之前的recaptchav3.js中繼續(xù)分析 _csrf 和 _sessionID的具體用途，之后，我順藤摸瓜來(lái)到了PayPal主要安全機(jī)制之一的安全質(zhì)詢(xún)發(fā)起功能點(diǎn)的防暴力枚舉處，雖然該功能用于大多數(shù)PayPal服務(wù)中，但我還是把關(guān)注點(diǎn)聚集到了PayPal的主登錄框架中。

因?yàn)椋喝绻?jīng)過(guò)數(shù)次的登錄失敗嘗試，之后，在繼續(xù)登錄之前，PayPal會(huì)向用戶(hù)發(fā)起一個(gè)驗(yàn)證碼質(zhì)詢(xún)（reCAPTCHA challenge），以驗(yàn)證當(dāng)前嘗試登錄的主體是否是人還是暴力枚舉的Robot。然而，就是這樣一個(gè)功能實(shí)現(xiàn)，卻讓我發(fā)現(xiàn)了其中隱藏的信息，讓我有點(diǎn)吃驚。

如果PayPal一旦檢測(cè)到可能的暴力登錄嘗試，那么，在下次登錄嘗試之前，PayPal登錄界面會(huì)彈出一個(gè)Google驗(yàn)證碼（Google Captcha）輸入提示，如果最終該驗(yàn)證碼由用戶(hù)輸入完成，那么就會(huì)向PayPal服務(wù)端/auth/validatecaptcha發(fā)起一下如下的HTTP POST請(qǐng)求：

可見(jiàn)，其請(qǐng)求體中包含了我們熟悉的_csrf 和 _sessionID， 除此之外，還有jse和captcha兩個(gè)數(shù)值比較大的參數(shù)。

發(fā)起上述驗(yàn)證碼質(zhì)詢(xún)（reCAPTCHA challenge）請(qǐng)求后，其后續(xù)的響應(yīng)旨在將用戶(hù)重新引入身份驗(yàn)證流程，為此，響應(yīng)消息中包含了一個(gè)自動(dòng)提交表單，其中存有用戶(hù)最新登錄請(qǐng)求中輸入的所有數(shù)據(jù)，包括相關(guān)的電子郵件和純文本密碼（Plain Text Password）?。〗?jīng)解析后的HTML如下：

OMG，有了這些，攻擊者可以通過(guò)社工或釣魚(yú)方式，在正確時(shí)機(jī)范圍內(nèi)對(duì)受害者形成一些交互，就能獲取上述的_csrf 和 _sessionID等token信息，有了這些token信息，再向/auth/validatecaptcha發(fā)起驗(yàn)證碼安全質(zhì)詢(xún)，如果受害者登錄成功，最終質(zhì)詢(xún)響應(yīng)回來(lái)的信息中就會(huì)包含受害者的注冊(cè)郵箱和明文密碼信息。在真實(shí)攻擊場(chǎng)景中，攻擊者只需制作一個(gè)惡意頁(yè)面（類(lèi)似釣魚(yú)頁(yè)面），迷惑受害者點(diǎn)擊訪(fǎng)問(wèn)，以模擬PayPal身份驗(yàn)證的反復(fù)嘗試，去調(diào)用PayPal的驗(yàn)證碼質(zhì)詢(xún)（Google Captcha），然后在其質(zhì)詢(xún)響應(yīng)消息中即可實(shí)現(xiàn)對(duì)受害者PayPal登錄密碼的獲取。

最后，我又回到對(duì)/auth/validatecaptcha的HTTP POST請(qǐng)求中，想看看jse和captcha兩個(gè)參數(shù)的實(shí)際作用，分析發(fā)現(xiàn)：

jse根本沒(méi)起到驗(yàn)證作用；

recaptcha是Google提供過(guò)來(lái)的驗(yàn)證碼質(zhì)詢(xún)（reCAPTCHA challenge）token，它與特定的用戶(hù)會(huì)話(huà)無(wú)關(guān)，無(wú)論人機(jī)驗(yàn)證，只要與其匹配的任何有效輸入token，它都會(huì)接受。

漏洞利用

綜上所述，除去Google的驗(yàn)證碼質(zhì)詢(xún)解決方案以外，為了對(duì)以上漏洞進(jìn)行成功利用，我把所有東西組合起來(lái)，制作了一個(gè)PoC驗(yàn)證。整個(gè)PoC驗(yàn)證包含兩個(gè)步驟：

1、用跨站包含漏洞（XSSI）獲取受害者會(huì)話(huà)中的_csrf 和 _sessionID等token信息，之后，利用這些token信息在受害者瀏覽器端發(fā)起針對(duì)PayPal身份驗(yàn)證服務(wù)端/auth/validatecaptcha的POST請(qǐng)求，形成暴力猜解登錄嘗試的模擬，以觸發(fā)PayPal的驗(yàn)證碼安全質(zhì)詢(xún)機(jī)制；

2、一旦受害者成功登錄到PayPal之后，之前對(duì)/auth/validatecaptcha的請(qǐng)求響應(yīng)消息中，將會(huì)包含受害者的注冊(cè)郵箱和登錄PayPal的明文密碼。在我設(shè)計(jì)的PoC中，這些敏感信息會(huì)顯示在頁(yè)面中。整個(gè)PoC的最后步驟是去請(qǐng)求Google獲取一個(gè)最新的reCAPTCHA token。

利用此方法，我又發(fā)現(xiàn)，在PayPal的一些未經(jīng)用戶(hù)授權(quán)的支付頁(yè)面中，同樣存在該漏洞，可以用上述方法獲取到用戶(hù)的明文***數(shù)據(jù)信息。

漏洞上報(bào)及處理進(jìn)程

2019.11.18 我將PoC驗(yàn)證資料連同其它敏感信息一并提交給了PayPal在HackerOne上的眾測(cè)項(xiàng)目；

2019.12 PayPal確認(rèn)了漏洞的有效性；

2019.12.10 PayPal官方獎(jiǎng)勵(lì)了我$15,300，同時(shí)漏洞被PayPal評(píng)定為CVSS 8.0 (高危) ；

2019.12.11 PayPal及時(shí)修復(fù)了漏洞

漏洞修復(fù)及建議

現(xiàn)在，PayPal的驗(yàn)證碼質(zhì)詢(xún)功能點(diǎn)/auth/validatecaptch加入了CSRF token，已經(jīng)不能實(shí)現(xiàn)之前的跨站腳本包含攻擊。雖然漏洞是可以修復(fù)的，但如果遵循信息安全最古老的建議：永遠(yuǎn)不要以純文本方式存儲(chǔ)密碼，那么這一切原本都是可以避免的。

*參考來(lái)源：medium，clouds編譯整理