G.O.S.S.I.P 阅读推荐 2023-01-04

有点不太习惯日期一下子跳到了2023，在这个崭新的年份，不变的仍然是我们每日的阅读，今天给大家分享的论文 Content-Type: multipart/oracle Tapping into Format Oracles in Email End-to-End Encryption 目前已被USENIX Security 2023接收。在这篇论文中，作者介绍了一项攻击技术，利用邮件协议头中的 Content-Type 对 S/MIME 加密邮件实现所谓的format oracle attack，那具体细节是什么呢，请接着阅读：

基于解密错误的提示信息来进行攻击，是一种安全领域典型的攻击手法。近年来，很多研究者不断复现 Daniel Bleichenbacher 提出的 Million Message Attack 和 Vaudenay 在2002年EuroCrypt上提出的 CBC padding oracle attack 来攻击 TLS 等协议，但是很少有人考虑过电子邮件协议也会受到这种安全威胁。研究认为，由于电子邮件通常采用端到端加密（End-to-End Encryption，主要有S/MIME 和 OpenPGP 两种方式），攻击者无法获知解密状态，而无法进行上述攻击。

在本文中，作者通过构造 MIME 协议头中的特定 Content-Type 信息，使得客户端在不同的解密状态下，能发送不同的网络通信流量到自己的服务器。作者详细介绍了从网络流量中泄露电子邮件客户端（Mail User Agent）解密状态的侧信道，受害者在打开电子邮件客户端时，会产生特定的网络流量，使得特定的format oracle attack得以实施。同时，作者调查了19个支持OpenPGP和S/MIME的电子邮件客户端和4个加密库，并发现其中一个客户端中确实存在侧信道，泄露了S/MIME消息的解密状态。

作者假设攻击者可以发送（恶意构造的）邮件给受害者，同时能够观察邮件服务器和客户端之间的（加密）通信流量，攻击模型如下图所示

本文提出的format oracle attack，核心是利用了电子邮件协议支持所谓的多加密消息部分（multipart）来进行攻击：通过构造一个具有multipart的特定格式的邮件，发送给受害者，并观察其使用的电子邮件客户端的行为，来分析并完成format oracle attack行为。下图是一个包含了多个加密MIME（也就是Multipurpose Internet Mail Extensions，能包含文本、图像、音频、视频以及其他应用程序专用的数据）部分的邮件。在收到这种结构的邮件时（使用IMAP），不同的邮件客户端实现会表现出不同的行为，特别地，有些客户端会根据某一个MIME的解密成功与否这一条件，来处理其余的部分，这就潜在地包含了一个解密的oracle，也就可能导致format oracle attack！

作者首先利用了一个特定的Content-Type——Multipart/alternative 来实现第一种format oracle attack，构造邮件消息如下图所示

针对这种格式的邮件，使用IMAP协议的电子邮件客户端并不一定一次性下载邮件的所有部分，而是会有选择性地下载某个部分。此外，客户端也不一定会一次性将邮件内容全部渲染出来，而是根据用户选择哪部分而显示哪部分。这些特性被称为lazy fetching和lazy rendering，而攻击者刚好可以利用这种特性来进行侧信道分析！

作者分析表明，由于邮件客户端会逆序分析邮件中的各个消息部分，那么在处理上图的加密 S/MIME 消息时，根据解密的成功与否，会产生不同的执行状态：

具体地，如果电子邮件客户端对加密的部分（第二部分）解密成功，则会先处理加密部分，同时由于lazy fetching和lazy rendering的存在，对未加密部分（第一部分）的处理则会延迟。而如果解密失败，客户端则会立即处理未加密部分（第一部分），而第一部分中预先埋设了攻击者部署的相关脚本（例如让邮件客户端访问攻击者控制的服务器），从而使得攻击者能够观察到相关的侧信道状态。

另一种更复杂的攻击利用了 Multipart/mixed 这种Content-Type来实现, 构造的消息如下图所示

在这种攻击中，如果第二部分的加密消息被解密成功，那么三部分消息都会按顺序显示。如果没有解密成功，且客户端启用了lazy fetching，那么攻击者可以通过分析捕获到的 FETCH 请求的间隔时间来确认解密状态。作者表示，这种间隔时间完全是可观测的——要么是经过公钥加密的session key没法解密导致电子邮件客户端不会执行解密操作产生时间差异，要么是对（正确解密的）结果进行渲染产生的时间差异。假设正常解密成功需要时间 $ t_{suc}$，下面的执行状态差异就可以被利用起来：

作者发现， Multipart/related 这种Content-Type也可用于攻击，构造的消息如下图所示。将明文部分和加密部分连接起来，也能用上述类似的方式通过时间差获取解密状态。

为了评估对电子邮件端到端加密的format oracle attack是否真实存在，作者对19个真实世界的电子邮件客户端进行了结构化分析。作者指出，Million Message Attack 对 OpenPGP 的攻击几乎是不现实的（下表所示，复杂度太高），而S/MIME加密标准使用了带填充的CBC mode，因此面临攻击，故而作者只测试了那些支持 S/MIME 的邮件客户端。

针对这些客户端的分析结果如下图所示。其中一些主要的特性包括：

• 10/19个邮件客户端不支持多个加密消息部分（multipart）；

• 在大多数情况下，电子邮件客户端将附加部分显示为附件或根本不显示消息；

• 10个邮件客户端在后台下载消息，9个邮件客户端在用户打开邮件时下载消息；

• 除了 eM Client、Trojitá 和 macOS Mail，其余所有桌面邮件客户端都仅从 IMAP 服务器获取完整消息。

在作者提出的攻击中，一个比较重要的因素是邮件客户端是否使用了lazy fetching和lazy rendering，作者的观察表明，移动客户端更喜欢lazy fetching和lazy rendering，这可能是考虑到移动数据连接的流量限制和不稳定性而特别设计的。而对于macOS Mail，当消息包含至少20个消息部分且同时大于5MB时，它会从标准模式切换到lazy fetching模式。

实际上，从分析结果中我们不难看出，只有一个客户端——iOS Mail——满足了各种作者提出的标准，从而存在安全风险。虽然iOS和macOS Mail都会对邮件部分进行即时解密。只有iOS Mail支持单个电子邮件中的multipart，因此它是唯一可能被攻击的的客户端。

针对iOS Mail，作者成功使用 multipart/mixed 实现了攻击，通过不断优化搜索方法，最终仅需12分钟，至少224封邮件来解密16字节的加密字符串。

针对加密邮件的 Oracle 攻击还有一种特殊的 Empty Line Oracle Attack，具体细节可以阅读原文。

---

论文: https://www.usenix.org/system/files/sec23summer_217-ising-prepub.pdf

原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2023-01-04