Recall 安全神话破灭？TotalRecall Reloaded 无需管理员权限即可提取所有私密数据

Windows Recall（回忆）功能的安全争议，随着安全研究员 Alexander Hagenah 发布 TotalRecall Reloaded 工具，再次被推向了风口浪尖。

尽管微软在经历了最初的强烈反对后，为 Recall 引入了基于 VBS Enclaves（虚拟安全内核隔离区）、AES-256-GCM 加密和 Windows Hello 生物识别验证的“钛合金保险库”，但 Hagenah 证明：只要数据被解密用于显示，它就处于极度危险之中。

🔓 核心发现：信任边界结束得太早

Hagenah 指出，Recall 的安全架构存在一个根本性的逻辑断层：

存储层（安全）：数据在静态存储时确实受到严密保护，密钥永不离开 VTL1（虚拟信任级别 1）。
渲染层（脆弱）：一旦用户通过 Windows Hello 验证，数据会被解密并发送给 AIXHost.exe 进程进行渲染。
致命弱点：AIXHost.exe 没有受保护进程轻量级（PPL）保护，也没有 AppContainer 隔离。任何以同一用户身份运行的进程（包括恶意软件）都可以轻易注入代码，拦截解密的明文数据。

正如 Hagenah 所言：“保险库门是钛合金的，但旁边的墙是石膏板。”

🛠️ TotalRecall Reloaded 是如何工作的？

该工具完全在标准用户权限下运行，无需管理员权限，无需内核漏洞，无需破解加密。它利用了 Windows 进程间通信的正常机制：

DLL 注入：通过经典的 CreateRemoteThread 技术，将负载 DLL 注入到 AIXHost.exe 进程中。由于默认的安全描述符允许同一用户的进程相互访问，这一步毫无阻碍。
“搭便车”认证：
- --launch 模式：模拟 Win+J 快捷键打开 Recall，触发 Windows Hello 验证。一旦用户完成验证，注入的代码立即开始提取数据。
- --stealth 模式：静默注入并修补 DiscardDataAccess 函数，阻止认证状态在关闭 Recall 时被清除。即使用户关闭了界面，授权依然有效，攻击者可随时后台提取。
COM 接口滥用：
- 利用未正确实施访问控制的 COM 接口（如 IResponse4.get_UnfilledItems），绕过搜索限制，获取所有实体数据。
- 调用 TryGetBitmapCaptureAsync 获取全分辨率截图，并通过 OCR 接口提取文本、NER（命名实体识别）数据。

⚠️ 更令人担忧的“预认证”漏洞

除了需要用户验证的攻击，Hagenah 还发现了无需任何 Windows Hello 验证即可利用的漏洞：

最新截图泄露：RecallPrivacyIndicatorSettings.GetRecentCaptureThumbnail 接口本意是显示任务栏小缩略图，但未限制分辨率。攻击者可请求 4K 全分辨率截图，直接获取屏幕上最后显示的内容。
活动监控：通过 GetSecureStorageInfo 接口，攻击者可实时监控 Recall 捕获的数量和存储大小，推断用户行为。
数据销毁：IDataStoreManager::DeleteEvents() 接口缺乏授权检查。任何同一用户的进程均可一键清空所有 Recall 历史，实现完美的防取证破坏。

🏛️ 微软的回应：这是“设计特性”，不是 Bug

面对披露，微软安全响应中心（MSRC）将此事结案为**“非漏洞”**。

微软表示：“观察到的行为在 Recall 当前的、已记录的安全设计范围内运行……演示的访问模式与预期的保护措施和现有控制措施一致。”

换言之，微软认为：只要用户通过了生物识别验证，系统就信任该会话中的所有操作。如果恶意软件能在你的用户会话中运行，那么游戏已经结束了，Recall 不需要为此负责。

💡 对用户的启示

微软的逻辑在技术上或许成立，但在现实威胁模型中却显得苍白无力：