除非启用了FileVault,否则将略过M1 Macs SSD的“加密”

2020-12-30 00:25:46

如果未启用Filevault,则具有物理访问权限的攻击者可以轻松绕过内置Mac SSD加密

如果您在2020年购买一台现代Mac,它将配备一个称为Secure Enclave的特殊物理组件。此组件使Apple能够继承许多流行的iOS功能,这些功能需要额外的硬件安全性,例如Touch ID和Apple Pay到Mac。

Secure Enclave鲜为人知的功能之一是,它对Mac的内置SSD执行基于硬件的自动加密。这意味着,无需任何用户干预,新Mac便会从包装中进行加密。考虑到这一事实,您可能想知道是否仍然需要采取额外的步骤来启用FileVault?我在这里告诉你,是的,这是绝对必要的。

不带FileVault的经过加密的Mac,可以使对您的设备具有物理访问权限的任何人都能轻松读取您的个人数据。他们甚至不需要知道您的密码。更糟糕的是,一些用于检测FileVault状态的工具(例如osquery)可能会混淆Encrypted和FileVault之间的差异,导致您认为Mac上的数据是安全的,而实际上,在我们所依赖的最常见情况下,它是不受保护的加密来拯救我们。

在本文中,我们将回顾当前的情况,确保正确轮询此信息应采取的步骤以及如何为osquery打补丁以解决这种混乱。

截至2020年12月20日的osquery disk_encryption表报告所有T2和M1 Mac的加密值= 1,无论FileVault状态如何。该信息在技术上是正确的,但可能导致对FileVault状态的错误解释。

Kolide确定不使用FileVault的Encrypted Macs的SSD可以通过对设备的简单物理访问来轻松访问。

Kolide为自己的客户提供了带有新启动器表kolide_filevault_status的修补程序,并修改了其检查以解决此问题。

Kolide为osquery disk_encryption表提供了一个补丁,其中包括一个新列:filevault_status

30年来,Apple在其操作系统中包含了一种称为“目标磁盘模式”的工具。该实用程序允许用户将一个Apple设备的磁盘作为网络卷安装在另一台设备上。此功能有用的原因有多种,最常见的原因是在Mac上无法成功启动的数据检索。

但是,使用macOS的目标磁盘模式,对设备进行物理访问的攻击者可以通过将磁盘物理连接到另一台计算机并以恢复模式启动磁盘来轻松访问磁盘的内容。因此,尽管借助Secure Enclave,该磁盘在静态时可以“实际上”被加密,但只要未配置FileVault,它就完全容易受到数据泄露的攻击。

您可能想知道这有多容易?在我们的测试中,您可以在不到3分钟的时间内开始提取目标设备的文件:

关闭目标设备并将其引导到恢复模式(按住⌘+ R或在M1 Mac上按住电源按钮)

在2018年,苹果推出了一系列配备了新的安全协处理器T2的Mac。借助这种新的Secure Enclave CPU,Apple从软件加密(FileVault2)模式转变为自动硬件加密。 2020年,在新推出的Apple Silicon Mac上,M1 SoC中内置了类似的Secure Enclave。

T2和M1 Secure Enclave均安全地存储无法直接访问并被烧入芯片的256位AES密钥(UID),从而保护SSD的数据和TouchID传感器存储的指纹,并禁用设备的相机和麦克风(当计算机锁定时)。

实际上,这意味着一旦将磁盘与Mac物理分离,或者基本的加密密钥丢失,就无法访​​问Mac磁盘上的数据。实际上,如果您的Secure Enclave损坏或擦拭,则此加密将阻止您访问驱动器的任何内容。这是另一种必须与备份无效的失败模式(备份具有其自身的加密注意事项)

在引入T2安全芯片之前,磁盘加密与macOS上的FileVault配置同义。但是,通过硬件加密,这种区别变得多方面的。对于无法区分“加密”磁盘和配置了FileVault的设备的安全代理来说,这种细微差别尤其成问题。

不幸的是,osquery陷入了这个阵营,它的disk_encryption表仅返回了加密列的布尔值,从而导致许多人得出错误的结论,从而产生了错误的安全感。

当常见的macOS终端实用程序的输出(diskutil apfs列表和fdesetup状态)返回的信息不同于使用osquery查询设备时所观察到的信息时,便发现了此问题。

由于假阴性性质,最初证明此问题难以追查。通常更容易找出产生假阳性的编码问题,但是间歇性假阴性确实令人发疯。因为在安装过程中会鼓励用户在新设备上配置FileVault,所以很少看到没有该设备的设备,再加上该表在较旧的硬件上按预期工作,从而导致难以建立模式并随后出现延迟在发现中。

幸运的是,Kolide进行了一些其他的逆向工程,从而更新了自己的代理和Osquery本身,以准确地报告此数据。在撰写本文时,Osquery核心团队尚未发布包含此修复程序的正式版本,但是您自己构建代理应该将您需要的新列扣除。