標題：在Chromium瀏覽器的內存Dump中提取輸入的明文密碼

憑證數據（URL/用戶名/密碼）以明文格式存儲在Chrome的內存中。除了登錄特定Web應用程序時動態輸入的數據外，攻擊者還可以使瀏覽器將存儲在密碼管理器(“登錄數據”文件)中的所有密碼加載到內存中。

Cookie的數據（cookie的值+屬性）以明文格式存儲在Chrome的內存中（當相關應用程序被急活時），這包括敏感的會話cookie。

這些信息可以通過在本地設備上運行的標準（非提升）進程有效地提取，並直接訪問Chrome的內存（使用OpenProcess+ReadProcessMemoryAPI）。

提取的數據可用於劫持用戶的帳戶，即使它們受到MFA機制的保護（使用“會話cookie”數據）。

Gmail、OneDrive和GitHub的示例會話劫持是“POC-ed”。

在MicrosoftEdge瀏覽器中發現了類似的漏洞（據推測，其他基於Chromium引擎的瀏覽器也會出現）。

本文描述了對瀏覽器的直接內存訪問攻擊。還有其他公開的竊取這些敏感數據的方法。

為什麼這是一個重要問題：如果一個人接受“假設違規”範式，那麼基於Chromium的瀏覽器處理敏感憑證數據的方式中的漏洞都應該被視為主要的安全風險。緩解措施應處理所有這些漏洞。

ProcessHacker工具（由WenJiaLiu編寫）在這項研究中被證明非常有用。如果你懷疑某個特定字符串存儲在進程的內存中，那麼查找它的快速方法是：

在ProcessHacker.exe中打開該進程；

選擇“內存”選項；

激活“字符串”子選項；

選擇“過濾器”選項並在“包含.”框架中輸入你要查找的字符串；

這是我查找已知密碼時生成的輸出示例（為了保密，我更改了它）：

ProcessHacker.exe在Chrome內存中識別的已知密碼

如果你返回顯示的內存佈局（當你選擇“內存”選項時），你會發現該字符串位於Private類型的內存部分中：

查找已知密碼存儲在Chrome內存中的內存塊

深入查看該內存塊，密碼存儲在Private:Commit類型的內存部分中：

查找已知密碼存儲在Chrome內存中的特定內存部分

根據MSDN，私有內存（MEMORY_BASIC_INFORMATIONType=MEM_PRIVATE）意味著：

MSDN中的MEM_PRIVATE內存屬性定義

人們可能會認為存儲在此類內存頁面中的數據不能被任何其他進程訪問。令人驚訝的是，這些頁面不能成為“共享內存”的一部分，但其他進程讀取其中的數據沒有問題（通過ReadProcessMemoryAPI）。

可以看到，上述ProcessHacker.exe作為標准進程運行，訪問這些數據沒有問題！

如果這些頁面真的是私有的，那麼這裡描述的攻擊向量將是不可能的。我想知道Chromium的創建者是否（在某些時候）認為敏感數據在存儲在私有內存中時是安全的。

當然，在瀏覽器內存中查找已知字符串並不是什麼大問題。尋找未知字符串怎麼樣？我決定只通過查看進程內存來嘗試找到敏感數據（不嘗試分析程序的開源代碼）。

Chromium內存佈局看起來像是被設計成一個“乾草堆（haystack）”，因此很難找到和“理解”存儲的數據（特別是密碼和cookie值等敏感字符串）。我還遇到了各種蜜罐，它們看起來像是故意創建的，用於生成明文密碼的誤報識別。其中的困難包括：

1.相對大量的瀏覽器進程（例如chrome.exe）。

2.每個進程都分配了大量的虛擬內存（有些超過230GB）。

3.每個進程的內存由許多（有時數百個）“脫節”的小型已提交內存部分組成，這些部分由“保留”部分分隔。

4.大內存“組合”部分，包括許多如上所述的不相交的部分，這些部分實際上是“空的”（不是“真正”使用的）。

5.看起來像密碼或cookie值的字符串（實際字符串的子字符串）。

6.將屬於一個邏輯“記錄”的項目（例如URL+用戶名+密碼）分散到遠程存儲位置。

這可能是所有看起來像是隱藏(“混淆”)的嘗試，而只是正常操作的結果。如上所述，我沒有查看代碼，但我認為他們試圖隱藏敏感數據。

從Chrome內存中提取的明文憑證數據類型

事實證明，通過標準的非特權進程可以很容易地從瀏覽器的內存中有效地提取明文憑證數據。實際上，這意味著：

1.它使用了合理數量的計算機資源（CPU能力、內存）。

2.執行在合理的時間內完成。

3.誤報現象較少。

注意：當描述POC程序的部分時，我知道大多數讀者會期望關鍵功能的技術細節和源代碼片段。由於本博文結尾部分解釋的原因，此信息不會被披露。已開發POC程序以提取以下類型的信息：

1、登錄目標Web應用程序時使用的用戶名+密碼該程序等待用戶登錄特定的Web應用程序（例如Gmail、OneDrive、GitHub等），然後分析捕獲的內存快照以識別用於登錄應用程序的用戶名和密碼。

這有點像一個有效的鍵記錄程序可以實現的功能，但重要的區別是，之前存儲的密碼(例如，在瀏覽器的密碼管理器工具中)，它完全繞過了最初定義時沒有運行的鍵記錄程序，將被我們的程序發現。

該程序查看登錄之前和之後立即拍攝的快照之間的差異，並查找僅出現在“after”內快照中並且看起來像潛在的用戶名和密碼字符串的新字符串。

注意：這是本研究中開發的最複雜的POC程序，它產生了相當多的誤報結果，因為相當多的新字符串出現在“after”內存快照中。

排除這些假陽性案例是可能的（例如，通過識別出現在登錄過程中的常見“單詞”），並且如果想要努力，可以不斷改進。具有諷刺意味的是，密碼越強，就越容易從“噪音”假陽性案例中分離出來(例如，由小寫和大寫字符、數字和特殊符號組成的10個字符的字符串比只有小寫字符的7個字符的字符串更有可能是密碼)。

2、URL+用戶名+密碼在瀏覽器啟動時自動加載到內存中當瀏覽器啟動時，“登錄數據”文件（Chromium存儲保存的密碼）中的一些條目會自動加載到內存中。雖然並非“登錄數據”中的所有條目都必須加載，但最近使用的條目是必須加載的。

“登錄數據”數據庫中的密碼是DPAPI加密的，但是當它們“分散”到內存中時，它們會以明文格式保存。

與前一種情況（上面的“a”）不同，這里分析一組快照就足夠了，因為加載的憑證數據靜態地保留在內存中。

我們開發了一個有效的POC程序，可以從內存中提取這些數據。可能會生成少量誤報項目。同樣，過濾掉誤報情況的算法可以得到顯著和持續的改進。

3、登錄數據中存儲的所有URL+用戶名+密碼記錄可以使瀏覽器的密碼管理器功能將其所有存儲的記錄加載到內存中。我們開發的POC程序可以提取所有加載的記錄。在這種情況下，敏感數據以易於識別的結構排列。

因此，程序對提取的數據有很高的信心，並且在大多數情況下，幾乎沒有誤報條目。

在這種情況下，所有保存的密碼記錄都加載到了Chrome的內存中。他還幫助我發現和分析了各種Chromium內存佈局。

4.屬於特定Web應用程序的所有cookie（包括會話cookie）

該程序等待用戶登錄到一個特定的應用程序(例如，Gmail, OneDrive, GitHub等)。當應用程序會話處於活動狀態時，程序可以從Chrome的內存中提取屬於該會話的所有cookie。這些被盜的cookie可以上傳到不同設備上的瀏覽器中，並且會話可以被盜（繞過任何MFA機制）。

當竊取的cookie被用於劫持會話時，典型的應用程序（例如Gmail）無法識別連接是從新設備還是從新位置建立的。這是因為完全繞過了登錄過程。根據cookie的內容，應用程序假定這是先前經過身份驗證的會話的延續。

值得注意的是，某些應用程序鼓勵其用戶不要退出應用程序。例如，Gmail的會話cookie的有效期為自首次生成之日起兩年。同樣，MicrosoftOneDrive最近開始向其網絡用戶建議他們無需退出會話。在這些情況下，竊取會話cookie的攻擊者可能會在很長一段時間內與真正的所有者“共享”該帳戶。

誤判極為罕見。

負責任的披露和供應商響應我於2021年7月29日向Google報告了此問題：

谷歌回應

該報告包括Gmail會話劫持的詳細POC，包括從Chrome內存中提取cookie的程序的源代碼。

Chromium.org的回复(WontFix)很快：

Chromium.org以WontFix狀態關閉問題

這種回應並不令人驚訝，因為其他類似“假設違規”漏洞的報告也收到了類似的回應。

14週後，Chromium公開了我的報告：

谷歌向公眾發布問題細節

總的來說，Chromium.org表示他們不會修復與物理本地攻擊相關的問題，因為Chrome(或任何應用程序)沒有辦法防禦一個以你的身份登錄你的設備的惡意用戶。雖然這種說法總體上可能是正確的（特別是如果你假設攻擊者可以獲得管理員權限），但我相信竊取敏感憑證應該不像今天這樣容易。因此，如上所述，我的下一篇文章將提出幾種緩解技術，使攻擊更難執行。

在披露後大約一個月，我的程序未能提取cookie數據。事實證明，一般內存佈局已被修改（在Chrome和Edge中）。大約兩個月後，它再次失敗。這一次，“敏感”數據的位置已經改變（同樣，同時針對Chrome和Edge）。

最初的POC程序是為Chrome版本91.0.4472.164開發的：

原始POC程序的Chrome版本

演示視頻中的POC程序正在訪問Chrome的96.0.4664.45版本：

演示視頻中用於POC程序的Chrome版本

如上所述，自從我們負責任地披露了這個漏洞以來，已經發現了內存佈局以及cookie值在內存中存儲方式的修改。但是，這些修改非常普遍，並沒有使“憑證竊取”行文變得更加困難。

由於供應商未計劃修復該漏洞，因此共享POC或源代碼不會促進問題的解決，而是可能造成傷害或提升相關威脅。因此，我們決定不發布POC。