Duo Security 研究人員對PayPal雙重驗證的繞過

wyzsk發表於2020-08-19
作者: Fireweed · 2014/07/09 16:31

from: https://www.duosecurity.com/blog/duo-security-researchers-uncover-bypass-of-paypal-s-two-factor-authentication

0x00 簡介


來自Duo Security高階研究團隊Duo Labs的人員,發現有可能繞過PayPal的雙重驗證機制(用PayPal自己的話來說是Security Key機制)。研究人員發現在PayPal的API web service(api.paypal.com)裡存在一個認證方面的缺陷,包括PayPal自己官方的移動應用和很多第三方應用都會用到這個API。

截至到這篇文章釋出(6月25日),Paypal還只是暫時採取了規避措施,官方也在努力修復此問題。為了讓PayPal的使用者意識到他們賬戶的安全性,我們決定將漏洞公開。

在漏洞研究過程中,我們也要感謝來自EverydayCarry 的Dan的幫助。

0x01 影響


攻擊者只需要一個賬戶和密碼就可以繞過PayPal的二次驗證機制,導致PayPal的Security Key機制形同虛設。

PayPal的移動端並不支援二次認證賬戶,所以移動端的應用在登陸的時候會忽略第二步驗證,導致攻擊者可以一步登陸成功。

我們在這裡寫了一個POC來說明這個問題,在這個POC裡,我們模擬移動端應用直接去請求PayPal API,但是這些賬戶都是沒有透過二次認證的。這個POC與兩個獨立的PayPal API通訊,一個負責認證(透過基本的憑證),還有一個負責轉賬。

注意,這個漏洞並不影響web端的介面。但是攻擊者依然可以直接透過API獲取資訊,所以影不影響web端無所謂。

0x02 技術細節


這個漏洞主要出在PayPal API的認證上(api.paypal.com),由於此係統主要是透過OAuth來認證和授權的,並沒有強制執行兩步認證,所以出了問題。

從影片裡可以看到,PayPal 的ios客戶端在現實使用者賬戶資訊和歷史交易記錄的時候並沒有強制使用者退出。正是這個特性,我們可以看看背後發生了什麼。利用Burp截獲PayPal客戶端的請求,我們仔細分析了認證過程,重點關注開啟了雙重認證賬戶和沒有開啟雙重認證賬戶之間的區別。

下面的截圖是一個到api.paypal.com的OAuth 請求。請求body 裡面除了其他引數,主要有認證憑證(使用者名稱和密碼)和一些裝置指紋資訊。這個請求與PayPal官方開發者文件中描述的完全一樣,並沒有什麼不對的地方。

enter image description here

但是在下面這個截圖裡,我們看到上面請求的response ,在這個JSON 裡我們看到了一些PayPal web服務url,各種token(主要是跟OAuth相關的),還有雙重認證的屬性。

enter image description here

注意上圖中紅框部分,這裡的雙重認證屬性值是true,因此會導致移動應用跳轉到登陸頁並且會彈出錯誤資訊,比如提醒裝置目前還不支援雙重認證。

enter image description here

android客戶端也是同樣的請求,同樣的錯誤提示。

enter image description here

利用Burp將2fa_enabled屬性值修改為false,

enter image description here

修改了值以後,儘管賬戶並沒有進行第二步認證,但是應用並沒有出錯。儘管漏洞是出在服務端,但是這個問題相當於客戶端已經透過了兩步認證。

enter image description here

回到開始那個認證的請求的response,我們發現JSON裡還有一個session id。

enter image description here

我們都知道,這個session id可以用來授權mobileclient.paypal.com,mobileclient.paypal.com這個站點提供了基於SOAP協議的API服務,可以用來做一些賬戶方面的附加功能,包括但不限於轉賬。

現在我們來模擬移動端的轉賬步驟,可以看到,轉賬是客戶端和服務端基於SOAP封裝的請求來進行的。整個過程可以分解為四個步驟,每個步驟都需要一個獨一無二的值。

下面截圖是一個例子,描述了利用上文中的session id來向mobileclient.paypal.com發起請求:

enter image description here

這裡我們用py寫了一個POC,模擬移動端去利用這個漏洞。這個指令碼的引數包括使用者名稱、密碼、一個美元賬戶、一個接受賬戶。具體有以下步驟:

  1. 在api.paypal.com認證。
  2. 顯示一些受限的賬戶資訊(包括“錢包”,連結的資金賬戶,比如簽帳金融卡和信用卡)
  3. 獲取session_token(session id)的值。
  4. 利用這個session id在mobileclient.paypal.com進行一些賬戶操作,比如轉賬。

下面的截圖是我們利用POC指令碼從一個已經開啟雙重認證的賬戶向一個接受賬戶中轉賬了1美元。

enter image description here

下面的截圖是轉賬證明:

enter image description here

我們在6月23號重新測試了這個漏洞,發現PayPal官方已經在著手修復這個漏洞。開啟了雙重認證的賬戶在請求api.paypal.com的時候已經不會返回session_token了,也避免了直接與mobileclient.paypal.com通訊。

但是錢包資訊依然沒有遮蔽,意味著這個漏洞還是有一些危害。下面這個截圖是我們用POC重新測試的結果,注意session_token已經沒有了。

enter image description here

利用官方的移動客戶端,可以更加明顯的看出PayPal官方已經更改了API服務的認證流程。

enter image description here

在6月24號,我們又測試了這個問題,發現錢包資訊已經遮蔽。下面截圖是測試結果,沒有access_token了也就意味著不能在api.paypal.com進行任何操作,包括檢視錢包資訊。

enter image description here

0x03 結論


雖然說現在的廠商推出雙重驗證機制能更好的保護使用者的資訊和賬戶安全,但是如果一旦被繞過,這些可能就成為浮雲。使用者很有可能會被這些廠商的承諾所麻痺。現在越來越多的使用者資訊在網際網路上傳播,透過一個設計安全的雙重驗證機制來提高賬戶安全已經迫在眉睫。

最後我們希望PayPal官方能很好的修復這個漏洞,並且推動移動客戶端和第三方應用也支援雙重驗證機制。

本文章來源於烏雲知識庫,此映象為了方便大家學習研究,文章版權歸烏雲知識庫!

相關文章