早在2月，我曾寫過有關(guān)瀏覽器密碼管理器的文章，并提到在決定如何實施功能及其安全保護時了解攻擊模型非常重要。

如果你將解密密鑰存儲在攻擊者可以訪問的地方，則純屬浪費時間和精力。這就是為什么物理上本地攻擊和感染了惡意軟件的計算機通常不在瀏覽器攻擊模型范圍之內(nèi)的原因之一：如果攻擊者可以訪問密鑰，則使用加密密鑰將無法保護你的數(shù)據(jù)。

Web瀏覽器會存儲各種高度敏感的數(shù)據(jù)，包括密碼和cookie(通常包含功能上與密碼等效的身份驗證令牌)。當存儲此特別敏感的數(shù)據(jù)時，Chromium使用AES256對其進行加密，并將加密密鑰存儲在OS存儲區(qū)中，以上過程就是本地數(shù)據(jù)加密。并非所有瀏覽器的數(shù)據(jù)存儲都使用加密，例如，瀏覽器緩存不使用加密。如果你的設(shè)備有被盜的危險，則應(yīng)使用操作系統(tǒng)的全盤加密功能，例如Windows上的BitLocker。

配置文件的加密密鑰受OSCrypt保護：在Windows上，“操作系統(tǒng)存儲”區(qū)域為DPAPI;在Mac上是鑰匙串;在Linux上，它是Gnome Keyring或KWallet。

值得注意的是，所有這些存儲區(qū)均使用可作為用戶運行的(某些或全部)進程可訪問的密鑰對AES256密鑰進行加密。這意味著，如果你的PC感染了惡意軟件，則攻擊者可以解密訪問瀏覽器的存儲區(qū)。

但是，這并不是說本地數(shù)據(jù)加密完全沒有價值，例如，我最近遇到了一個配置漏洞的網(wǎng)絡(luò)服務(wù)器，該網(wǎng)絡(luò)服務(wù)器允許任何訪問者瀏覽服務(wù)器所有者的個人資料(例如c：\ users \ sally)，包括其Chrome個人資料夾。由于配置文件中的瀏覽器密鑰是使用存儲在Chrome配置文件外部的密鑰加密的，因此它們最敏感的數(shù)據(jù)仍保持加密狀態(tài)。

同樣，如果筆記本電腦未受到全盤加密保護，則本地數(shù)據(jù)加密將使攻擊者的攻擊更加艱難。

好的，因此本地數(shù)據(jù)加密可能很有用。那不利之處是什么?

顯而易見的攻擊是簡單溫和的：加密和解密數(shù)據(jù)最終會降低性能。但是，AES256在現(xiàn)代硬件上非?？?> 1GB /秒)，并且cookie和憑據(jù)的數(shù)據(jù)大小相對較小。但更大的風險是復(fù)雜性，如果兩個密鑰(用于加密數(shù)據(jù)的瀏覽器密鑰或用于加密瀏覽器密鑰的操作系統(tǒng)密鑰)中的任何一個出問題，則用戶的Cookie和憑據(jù)數(shù)據(jù)將無法恢復(fù)。用戶將被迫重新登錄每個網(wǎng)站，并將所有憑據(jù)重新存儲在其密碼管理器中或使用瀏覽器的同步功能從云中恢復(fù)其憑據(jù)。

在Mac上，研究人員最近在Edge發(fā)現(xiàn)了一個漏洞，即瀏覽器無法從OS鑰匙串獲取瀏覽器密鑰。由于瀏覽器將提供刪除鑰匙串(丟失所有數(shù)據(jù))的功能，但是忽略漏洞消息并重新啟動通?？梢越鉀Q問題，不過最近該漏洞的修復(fù)程序已經(jīng)發(fā)布了。

在Windows上，DPAPI漏洞通常是隱蔽進行的。通常受害者的數(shù)據(jù)消失，并且沒有消息框。

當我于2018年首次加入Microsoft時，AAD中的一個漏洞意味著我的OS DPAPI密鑰已被破壞，導(dǎo)致基于Chromium的瀏覽器在啟動時會導(dǎo)致lsass永遠保留CPU內(nèi)核，解決此漏洞需要花費數(shù)月的時間。

最近，研究人員從Windows 10上的一些受害者那里聽說Edge和Chrome經(jīng)常刪除他們的數(shù)據(jù)，在其他使用DPAPI的應(yīng)用程序中也看到了類似的效果。

處于此狀態(tài)的用戶在瀏覽器會話中首次發(fā)現(xiàn)其敏感數(shù)據(jù)丟失的情況下，在Chrome或Edge中訪問了chrome://histograms/OSCrypt的用戶將在OSCrypt.Win.KeyDecryptionError中看到值為-2146893813(NTE_BAD_KEY_STATE)的條目，表明OS API無法使用當前登錄用戶的憑據(jù)來解密瀏覽器的加密密鑰：

如果你發(fā)現(xiàn)系統(tǒng)處于這種狀態(tài)，請嘗試在PowerShell中運行以下命令：

Get-ScheduledTask | foreach { If (([xml](Export-ScheduledTask -TaskName $_.TaskName -TaskPath $_.TaskPath)).GetElementsByTagName("LogonType").'#text' -eq "S4U") { $_.TaskName } } 

這將列出懷疑使用S4U功能的所有計劃任務(wù)，這些任務(wù)可能會導(dǎo)致漏洞的DPAPI憑據(jù)：

Windows Crypto小組正在積極研究此問題，希望我們會盡快修復(fù)。

總結(jié)

進程可以要求操作系統(tǒng)解密瀏覽器的密鑰確實是一個很有趣的問題，在Windows上，Chromium使用DPAPI的CryptProtectData允許任何以用戶身份運行的進程發(fā)出請求。沒有嘗試使用附加的熵來進行更好的加密，這主要是因為沒有地方可以安全地存儲該附加的熵。在現(xiàn)代Windows上，還有一些其他機制可以提供比原始CryptProtectData更高的隔離度，但是完全信任的惡意軟件總是能夠找到獲取數(shù)據(jù)的方法。

在Mac上，鑰匙串保護功能會限制對數(shù)據(jù)的訪問，因此，以用戶身份運行的每個進程都無法訪問該數(shù)據(jù)，但這并不意味著該數(shù)據(jù)可以免受惡意軟件的攻擊。惡意軟件必須改為將Chrome用作偽造的身份，使其執(zhí)行所有數(shù)據(jù)解密任務(wù)，并通過可擴展性接口或其他機制來驅(qū)動它。

進程隔離的機制和約束進一步使針對本地攻擊者的總體攻擊模型更加復(fù)雜：例如，如果一個管理進程并轉(zhuǎn)儲用戶級進程的內(nèi)存，或者向該進程注入線程，惡意軟件也可以在瀏覽器解密后竊取數(shù)據(jù)。

本文翻譯自：https://textslashplain.com/2020/09/28/local-data-encryption-in-chromium/