通過Password Vault的XSS漏洞獲取用戶密碼測試

PS：本文僅作技術討論，禁止用於任何非法用途

前言

大家好！自我上次寫作以來到現在已經有段時間了。今天，我想和大夥分享一些非常有意思的內容。為了存儲及管理的方便，相信大家可能都會選擇使用一些密碼管理器來存儲不同網站的密碼（例如Facebook，Gmail等其他帳戶）。那麼，作為存儲如此敏感數據的管理工具是否應該保證足夠的安全性呢？

場景

在我遇到的這個場景中，其中不僅包含了賬戶密碼它還包含了該公司員工的密碼。令我感到驚訝的是，我在同一域中發現了一個XSS漏洞，並最終利用該漏洞成功竊取了其中的用戶密碼信息。

每當我測試一個應用程序時，我都會首先確定我的目標公司類型。而當前測試的目標則是一個密碼管理器，顯而易見這是一個存儲密碼的地方。而密碼也這正是他們所要保護的敏感數據，我的目標就是捕獲和檢索這些密碼。

應用工作流程

為了更好的理解應用程序，我們需要了解它的功能和流程，以及它是如何檢索數據以及檢索數據的位置。

在仔細觀察應用程序並完成各個請求之後，我發現應用程序會從位於應用程序的/api/的API中檢索不同的信息。

在對應用程序進行一些爬行和抓取後，我發現了一些API端點：

API端點觀察

當應用程序與API完全交互時，每個端點都返回了一些值和信息，其中包括record ID，session token和其他一些內容。讓我來解釋下這些API。

records/all 端點

位於

/api/v3/records/all

的端點，它正在接受GET請求。一旦在進行身份驗證時發送了GET請求，它就會返回具有

record ids

的JSON對象，以及與可用記錄相關的其他信息。

passwords/record 端點

該端點位於

/api/v1/passwords/record

。在

record IDs從record/all

端點被檢索後，該端點用於從這些特定記錄ID中檢索密碼及其完整信息。

在我們的例子中，我們獲取到了以下record IDs：

• 
  

  526882 - 

  「

  Facebook Account

  「 record ID



• 
  

  526883 - 

  「

  Google Email

  「 record ID

如果用戶單擊「 「

Facebook Account

「 記錄，一個使用以下JSON數據以及record ID為

526882

的POST請求，將會被發送到

/api/v1/passwords/record

端點。

這將返回指定ID的以下信息：

現在我們已經知道了ID是如何被檢索的，以及它們是如何返回數據的。但有個問題就是，應用程序在發送給API的每個POST請求中都發送了一個CSRF token。在請求中包含一個 「

token

「，是為了對用戶會話進行驗證。

session/token 端點

為了弄清楚token是如何生成的，我查看了其它的一些端點，最終發現位於

/api/v1/session/token

的API端點是負責生成CSRF tokens的。

發送一個GET請求至該端點，你將會獲取到以下響應：

XSS漏洞

現在，我們開始了解應用程序的流程和用於數據交換的端點。我們需要以某種方式從以下端點獲取信息：

Session Token 來自 

/api/v1/passwords/record

Record IDs 來自 

/api/v3/records/all

Record 信息 來自 

/api/v1/passwords/record

從端點獲取信息，有一個簡單的技巧就是利用一些配置錯誤的CORS，但可惜的是該應用似乎並沒有將它用於資源共享。

另一種可能性是在同一個域的某個地方找到XSS漏洞，繞過同源策略（SOP）。否則，將會因為觸發SOP，導致我們所有的

XHR

調用都被拒絕。

經過一番測試，我成功的在一個電子郵件激活頁面上找到了一個XSS漏洞。如下所示：

現在，我們就不必再擔心SOP了，並可使用與應用程序相同的方式與API進行通信。

利用腳本

首先，我們將使用javascript的

fetch()

函數來向

/api/v3/records/all

發出GET請求，以獲取所有的record ID：

抓取記錄後，接下來就是獲取session token以進行POST請求。這裡我還將記錄的響應轉換為了JSON，並直接從JSON對象調用記錄ID的值。fetch()函數用於發送GET請求，以捕獲令牌並從JSON對象中檢索其值：

現在，我們獲取到了

「session_token」

和

「record IDs」

。接下來我們要做的就是將具有」record ID」的POST請求，發送到

/api/v1/passwords/record

端點。我將使用XHR發送具有指定記錄ID的POST請求。我將遍歷record IDs逐個檢索每條記錄的信息：

如你所看到的第30-34行，我們進行了一些適當配置。在第45行，我們將這些值以 

{「id」:record_ID_here,」is_organization:false}

的形式放置，然後發出請求。

請求完成後，將解析響應並從響應中獲取值，例如

標題，URL，用戶名，密碼

。然後將這些值添加到虛擬變數

「data_chunks」

進行最終的處理。

在使用收集的數據填充虛擬變數之後，它將轉換為base64以避免錯誤字元衝突，並將其發送至攻擊者的主機上。

注意：還有許多其他方法可以用來正確發送抓取的數據，但出於演示目的我使用的方法很簡單，例如直接發送base64編碼數據。其實，通過POST將數據發送至特定文件也是一個不錯的選擇。

漏洞利用

現在，我們的漏洞利用腳本已經編寫完成。那麼我們該如何進行利用呢？這裡有兩個簡單的XSS利用技巧。

在外部主機上託管你的javascript利用腳本（你可能必須要設置CORS才能成功訪問）；

直接用eval和atob包含payload。

對於第一種技術，需要通過來載入外部JS。這種方法在處理大型漏洞利用代碼時非常有效，並且還有一個好處就是利用代碼不會被記錄在伺服器中。

第二種方法可用於處理一些較簡短的payload。我使用的payload如下：

現在用我們的base64編碼的源代碼替換atob()的值。首先，我們的payload將由atob解碼，然後由eval()執行。

最終的payload如下：

這裡或許有人會說這並不是一個簡短的payload，而是一個較大的payload。其實它也可以從外部主機被載入，但這裡我為了避免CORS設置所帶來的麻煩，所以才使用了這種方法。

現在我將託管一個內容如下的exploit.html文件：

現在只需為exploit.html提供一個URL，攻擊者就可以將用戶重定向到一個注入了payload的頁面上。

成功利用後，我們將獲取到以下數據：

可以看到，存儲在Password Vault中的記錄成功被我們檢索了出來，並且我們也放大了該XSS漏洞帶來的安全影響。

漏洞利用代碼我已經發布在了https://gist.github.com/shawarkhanethicalhacker/e40a7c3956fdd24b9fb63d03d94c3d34，有興趣的可以自行下載測試。

*參考來源：shawarkhan，FB小編 secist 編譯，轉載請註明來自FreeBuf.COM

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

本站內容充實豐富，博大精深，小編精選每日熱門資訊，隨時更新，點擊「搶先收到最新資訊」瀏覽吧！

請您繼續閱讀更多來自 FreeBuf 的精彩文章: