论文中展示了一种针对使用OpenPGP和S/MIME协议的电子邮件的攻击。攻击利用了电子邮件中支持的MIME标准和HTML语法,通过一些手段对用户隐藏邮件的实际内容。攻击通过欺骗用户回复一个看起来正常的邮件,来让用户的邮件客户端成为密码学中的预言机(解密和签名)。通过这种攻击,数百封加密邮件可以被一次泄漏。另外,论文中还展示了如何通过编写特定的CSS条件规则来诱骗用户签署任意文本内容。实验测量表明有17(总样本19)个OpenPGP邮件客户端以及21(总样本22)个邮件客户端至少被攻击成功一次。

文章目录

  1. 作者介绍
  2. 引言
  3. 背景知识
  4. 正文
    1. 研究问题描述
    2. 攻击模型
    3. 解密预言机
      1. 直接使用明文混合
      2. 使用HTML和CSS隐藏加密信息
        1. 如何使用*引用* 来攻击带有隔离机制的邮箱
    4. 签名预言机
    5. 实际测量结果
  5. 结束语
  6. 引用

作者介绍

Jens Müller 于2016年获得德国波鸿鲁尔大学计算机信息安全/网络与系统硕士学位。曾为网络渗透测试和安全审计方面的自由职业者,业余开发免费开源软件,目前在做网络打印机安全相关工具开发。当前就任于波鸿鲁尔大学网络和数据安全主席。

引言

论文中展示了一种针对使用OpenPGP和S/MIME协议的电子邮件的攻击。攻击利用了电子邮件中支持的MIME标准和HTML语法,通过一些手段对用户隐藏邮件的实际内容。攻击通过欺骗用户回复一个看起来正常的邮件,来让用户的邮件客户端成为密码学中的预言机(解密和签名)。通过这种攻击,数百封加密邮件可以被一次泄漏。另外,论文中还展示了如何通过编写特定的CSS条件规则来诱骗用户签署任意文本内容。实验测量表明有17(总样本19)个OpenPGP邮件客户端以及21(总样本22)个邮件客户端至少被攻击成功一次。

背景知识

OpenPGP和S/MIME是提供邮件端到端加密的两个主要标准。这两个标准设计目标都是为了保护邮件的机密性、完整性以及真实性。

早期,电子邮件只支持ASCII文本,但是这远远无法满足用户的需要。在1992年,MIME(Multipurpose Internet Mail Extensions)协议出现,让电子邮件可以包含多种内容类型。后来,比如支持HTML格式的邮件中可以包含文字、图片、附加文件等等。一个带有PDF附件的邮件结构如下(图片摘来自论文):

1

目前绝大部分电子邮件客户端都支持HTML格式,一些甚至支持执行脚本代码。本文中就是利用了这种特性来进行攻击。

正文

研究问题描述

OpenPGP和S/MIME都是基于非对称加密的,只有用户本身拥有私钥。用户可以利用公钥对信息进行加密和签名。邮件在使用过程中,客户端经常需要和多方进行通信,甚至会包含恶意的攻击者。

我们举一个简单的例子:假设一个邮件服务器的管理员王二麻子截获了张三发给李四的加密邮件,在这种情况下,王二麻子可以简单的把邮件的发送者改为自己,然后把这封邮件再发送给李四,这样李四的邮件客户端就会将内容解密。如果李四回复了邮件并且引用了之前的邮件内容,那么王二麻子就可以看到之前邮件中加密的内容。这种类型的攻击在之前的论文中已经有过研究。但是这种方式的攻击很容易被识破,一般的邮件用户会在邮件结尾附上署名,接受者只要简单的看下署名和发送者的邮箱是否一致就可以发现是否存在异常。

因此,本文的研究问题是:是否可以在隐藏原始内容的情况下,让用户的客户端在无意识的情况下充当一个解密预言机?图示如下:

2

攻击模型

在本文的攻击模型中,需要攻击者通过某种方式获取PGP或者S/MIME加密邮件。比如:在实际网络中,可能出现邮件服务器被黑的情况。虽然这个假设很强,但是PGP或者S/MIME这类加密邮件的协议设计的初衷就是为了解决信道不安全的问题。

王二麻子在获取加密邮件之后,就可以进行一些修改,将发送者改为自己,然后将邮件发送给张三或者接受者李四。发送和接受双方都可以解密邮件。王二麻子还可以将加密内容包含在邮件支持的其它格式中。

解密预言机

之前提到过王二麻子截获邮件之后,如果将发送者改为自己,然后将邮件发送给接受者,很容易被识破。在这部分中,我们展示如何利用MIME标准邮件内支持的HTML格式的内容来隐藏加密内容,让一封攻击邮件看起来和正常的邮件一样。

邮件加密部分的内容可以是MIME格式树中的一个叶子结点,并且MIME格式树中还可以混合包含未加密的内容。虽然在实际生活中几乎没有什么场景会使用到部分加密类型的邮件。但是这种混合使用的特性对于攻击来说是一种有效的特性。这可以让攻击者将加密之后信息的内容包含在MIME树中,经过精心设计之后发送给受害者。一个包含攻击者控制信息的邮件的MIME树结构如下:

3

直接使用明文混合

如果一个邮件客户端在接收到一封包含多部分的邮件(比如上图中的application部分、multipart部分、text部分等等)之后,它会将加密部分解密,然后将不同部分合并到一个文档里面。这种实现非常危险,比如王二麻子在他的邮件内容之后加许多换行符号,然后附上被攻击者的加密邮件,这样解压之后,李四只看到了王二麻子写的邮件内容,而下面是一堆换行符,如果李四不向下滑动,那么就可能看不到原来加密的邮件内容。一旦李四回复邮件内容就会泄漏邮件信息。再比如,王二麻子可以将加密邮件的内容包含到一个有许多交互上下文的历史信息中,一般用户不会去看邮件的交互上下文的所有信息,这样同样会泄漏秘密信息。

使用HTML和CSS隐藏加密信息

在支持HTML邮件的环境中,攻击比使用ASCII码的邮件中更严重。攻击者可以利用HTML和CSS的特性将自己写的一些明文内容设置为可见的,然后将加密的内容设为不可见的,比如可以将加密的内容包含到一个高度为1的iframe中。邮件内容如下图所示:

From: 王二麻子@attack.com
To: 李四@normal.com
Content-Type: multipart/mixed; boundary="BOUNDARY"

--BOUNDARY
Content-Type: text/html

<b> 你好,李四!</b>
最近有点想你了,你能来看看我吗?
<iframe height="1" frameborder="0">

--BOUNDARY
Content-Type:application/pkcs7-mime; smime-type=envelooped-data
Content-Transfer-Encoding: base64

[... 加密内容 ... 加密内容 ...]

--BOUNDARY

那么解压重组后的HTML代码为:

<b> 你好,李四!</b>
最近有点想你了,你能来看看我吗?
<iframe height="1" frameborder="0">
[解密后的内容,原来只有李四可以看到...]

回复邮件中的HTML代码为:

亲爱的王二麻子,我待会去看你!

On 05/02/2021 02:34, 王二麻子 wrote:
> <b> 你好,李四!</b>
> 最近有点想你了,你能来看看我吗?
<iframe height="1" frameborder="0">
[解密后的内容,原来只有李四可以看到...]

如何使用*引用* 来攻击带有隔离机制的邮箱

有些邮箱的客户端不会自动将邮件的不同部分组合到一个文档中。在这种情况下,我们可以添加 multpart/related 标签来通过 cid: URI来引用加密部分的内容。这种内容-ID资源定位的方式,经常被用来在HTML中内嵌图片(将图片的二进制数据编码到文本中)。内嵌图片这种方式通常被看作比从远程服务器获取图片资源更能保护用户的隐私。下面的文本展示了一封攻击邮件,加密内容被当作图片的内容,由于加密内容本身不是图片,因此不能被显示出来,但是,解密之后的内容还是会被回复给发送者。

From: 王二麻子@attack.com
To: 李四@normal.com
Content-Type: multipart/mixed; boundary="BOUNDARY"

--BOUNDARY
Content-Type: text/html

<b> 你好,李四!</b>
最近有点想你了,你能来看看我吗?
<img src="cid:target" width="1" height="1".
<style>fieldset,br{display:none}</style>

--BOUNDARY
Content-ID: <target>
Content-Type: multipart/encrypted; protocol=“application/pgp-encrypted”; boundary=“PGPMIME”

--PGPMIME
Content-Type: application/pgp-encrypted 18

Version: 1
--PGPMIME
Content-Type: application/octet-stream; name=“encrypted.asc”
Content-Disposition: inline; filename=“encrypted.asc

-----BEGIN PGP MESSAGE-----
[... 加密的内容 ...]
-----END PGP MESSAGE-----
--PGPMIME
--BOUNDARY

在上面邮件的文本内容中,我们可以看到,王二麻子的邮件内容中包含了一个内嵌图片的引用(第10行),其src为cid:targettarget的主体内容在第14~28行定义,在第14行中,我们可以看到ID为target。第16行为加密内容本体,它被放置在原本作为图片的数据的位置。

签名预言机

数字签名可以保证邮件的完整性、真实性以及不可否认性。我们举个例子,比如张三是个司令员,他非常重视信息安全,他所有的电子邮件都是经过签名的。因此,攻击者很难伪造司令员的签名来发动攻击。王二麻子现在想借张司令的签名来调动李四的部队来发动战斗。由于只有张司令员才拥有签名的私钥,因此只有张司令员可以充当签名预言机。比如下面的邮件对话:

王二麻子:

张三司令,你让李四发动一个战斗吧!

张三司令:

滚蛋!

在 2021年2月5日 03:03,王二麻子写:
> 张三司令,你让李四发动一个战斗吧!

在上面的回复中,张三司令在无意识的情况下给他自己回复的内容,和之前王二麻子的邮件内容一起进行了签名。

虽然张三司令对邮件签了名,但是显然,发动战斗的申请被张司令一口拒绝!

下面我们展示,如何将恶意的内容包含在看起来正常的内容中,但是不让看邮件的用户觉察到异常内容,从而骗取其签名。这是通过CSS条件规则来实现的,这个功能只有在第三方的客户端实现中才会被实现。

如果张三司令在这类第三方邮件客户端中回复了王二麻子精心设计的邮件内容,那么王二麻子就获得了张司令发动战斗的签名。这时候他就可以把邮件发送给李四,让他发动战斗!示意如图下图所示:

4

要实现这种效果,我们可以通过条件CSS规则来实现,比如我们可以通过屏幕的大小来设定显示规则。假设我们知道张司令经常坐办公室,他一般使用大屏幕电脑来工作。而李四通常在外面跑,因此一般适用手机来工作,回复电子邮件。在这种情况下可以使用CSS设定规则,在大屏幕中让邮件客户端只显示文字张司令你好吗?,在小屏幕中只显示李四去战斗吧!

下面我们展示一个攻击邮件样例:

From: 王二麻子@attack.com
To: 张三@normal.com
Content-Type: text/html

<style>
/* 在桌面级显示器上隐藏内容 */
@media (min-device-width:835px) {
	.covert {visibility: hidden;} // 隐藏 .covert 元素
}

/* 在小屏幕上显示内容 */
@media (max-device-width:835px) {
  *{ visibility: hidden;}					// 隐藏所有元素
  .covert {
    visibility: visible !important;  // 只显示 .covert 元素
    position: absolute;
    top: 8px;
    left: 8px;
  }
}
</style>

张司令你好吗?
<div class="covert" style="visibility: hidden">李四去战斗吧!</div>

那么在张司令的邮件客户端上看到的是:

张司令你好吗?

张司令收到邮件后正常回复并签名,这样在李四的手机上,除了 .covert 修饰的元素之外,都不可见,因此,李四看到的是:

李四去战斗吧!

除了 @media这个标签可以用来构造条件规则外,其他只有许多,具体可参考论文附录。

实际测量结果

论文中测量了19个广泛使用的支持OpenPGP的邮箱以及22个支持S/MIME的邮箱,这些邮箱横跨各个平台:Window/Linux/iOS/macOS/Android/Web 等等。所有被测试的客户端回复邮件的时候都会引用原邮件内容。在测试的24个客户端中,默认设置下,20个直接展示了HTML内容而无需任何用户交互。但是只有16个在回复中附带了HTML格式的内容。其中有5个下载了外部的CSS样式表,所有客户端都支持内联的CSS样式。具体结果摘录如下:

5

结束语

除了微软的产品以及"The Bat!"之外所有的邮件客户端都将ASCII文本内容和HTML部分的内容合并到了一个文档中去,这就导致了隐藏内容攻击成为可能。但并不是所有的客户端都会去解密混合了明文和密文信息的MIME树中的加密部分。在这种情况下攻击会失败。作者与邮箱开发者也进行了交流,在OpenPGP和S/MIME的标准中,并没有规定在混合明文密文的情况下邮箱应该是一个什么行为,邮箱为了更多的灵活性、适应性,一般会选择支持混合模式。

在邮件上构建一个安全的加密协议非常具有挑战性,作者在文中给出了一些最佳实践,针对解密预言机:

  • All-or-Nothing 加密
  • 只接收包含ASCII文本的邮件
  • 强制使用签名

针对签名预言机:

  • 不支持CSS
  • 在回复中仅支持ASCII文本

引用

* 论文: Re: What's Up Johnny? -- Covert Content Attacks on Email End-to-End Encryption : https://arxiv.org/abs/1904.07550


[本]通信工程@河海大学 & [硕]CS@清华大学
这个人很懒,他什么也没有写!

1
685
0

更多推荐


2022年11月30日