凭证数据（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。

本文翻译自：https://www.cyberark.com/resources/threat-research-blog/extracting-clear-text-credentials-directly-from-chromium-s-memory如若转载，请注明原文地址