构成杀伤力： 电子邮件发送者认证的案例研究

摘要

基于组件的软件设计是构建现代软件系统的一种主要工程方法。然而，由于不同组件之间对信息的解释可能不一致，这种编程范式产生了安全问题。在本文中，我们利用这种不一致来识别电子邮件系统的漏洞。我们确定了一系列的技术来诱发电子邮件服务器和客户端的不同组件之间的不一致。我们表明，这些不一致可以使攻击者绕过电子邮件认证来冒充任意的发件人，并以合法网站的签名来伪造DKIM签名的电子邮件。使用人工分析和黑盒测试的组合，我们发现了18种类型的规避漏洞，并对10个流行的电子邮件提供商和19个电子邮件客户端进行了测试–所有这些都证明容易受到各种攻击。在不了解我们的攻击的情况下，对于其中的许多攻击，即使是使用最先进的电子邮件提供商服务（如Gmail）的认真的安全专家，在收到电子邮件时也不能自信地轻易确定它是否是伪造的。(译自原文:Composition Kills:A Case Study of Email Sender Authentication 摘要)

基于组件的软件设计：
基于组件的软件设计是一种使用组件化方法来构建软件系统的开发方法。它将系统分解成多个独立的、可重用的模块（即组件），并通过定义它们之间的接口和交互方式，使得这些组件可以进行协同工作以完成特定任务。在基于组件的软件设计中，每个模块都被视为一个独立的实体，并且只公开必要的接口和功能。这样做可以增加代码复用性，提高应用程序开发效率，并降低维护成本。同时，在需要修改或更新时，也能够更加方便地对单个模块进行调整而不影响整个系统。

一、简介

1.起因

基于组件的软件设计被广泛采用，作为管理复杂性和提高可重用性的一种方法，该方法将复杂的系统划分为较小的模块，这些模块可以独立创建并在不同的系统中重复使用，人们将这些组件组合在一起以实现所需的功能。

2.存在的问题

现代的软件系统通常是使用由独立工作的不同开发者制作的组件构建的。虽然有广泛的好处，但安全研究界已经认识到，这种做法也带来了安全问题。特别是，当面对精心设计的对抗性输入时，不同的组件在依次对输入进行操作时，会有不一致的解释。攻击者可以利用这种不一致来绕过安全策略，颠覆系统的运行。本文中提供了一个关于电子邮件（SMTP）发件人认证背景下的这种组成问题的案例研究。攻击者可以利用这种不一致来绕过安全策略，颠覆系统的运行。
SMTP的原始设计缺乏确保电子邮件的所谓发件人（和消息内容）的完整性的机制。为了打击电子邮件欺骗行为，现代电子邮件服务器采用了几个SMTP扩展–SPF、DKIM和DMARC–来认证发件人的所谓身份，作为在用户阅读邮件时在电子邮件客户端显示有效性保证的基础。
本文表明，构建这些有效性保证的不同软件组件的组合具有广泛的漏洞，使攻击者能够破坏决策过程。图1展示了我们的一个攻击，即在Gmail上冒充facebook.com。Gmail用户看到了明显的保证，即发件人确实是security@facebook.com，而事实上却不是。(转自原文Composition Kills:
A Case Study of Email Sender Authentication 图1)

除非另有说明，我们在本文中提出的所有攻击都有类似的表现：当使用一个有漏洞的电子邮件系统时，检查电子邮件是否有效的读者会收到一个表面上但不正确的保证。我们将这些攻击分为三类。
1)第一类（“服务器内”）是利用单个电子邮件服务器内不同组件之间的不一致，使电子邮件
服务器产生 "通过 "认证结果的欺骗性邮件。
2)第二类（“用户界面不匹配”）利用了邮件服务器和用于阅读邮件的邮件客户端之间的不一致，如服务器和客户端认证/显示不同的邮件地址。
3)第三类（“模棱两可的重放”）重放部分受DKIM签名保护的邮件，采用添加的方式产生具有欺骗性内容的邮件，看起来像是由合法网站签署的。

3.尝试/测试

我们使用人工分析和黑盒测试相结合的方法评估了10个流行的电子邮件供应商和19个电子邮件客户端。

4.测试结果

我们发现了18种类型的漏洞： 6个电子邮件供应商受到服务器内部攻击的影响，并且所有这些都被证明容易受到用户界面不匹配和模糊重放的攻击。

二、背景

1.SMTP缺乏认证

图3显示了从a.com发往b.com的SMTP信息的要素。SMTP的原始规范缺乏验证发件人身份的机制，使得任何互联网主机都可以通过发送欺骗性的电子邮件来冒充他人的身份。在实践中，攻击者通常通过运行他们自己的电子邮件服务器或客户端来利用SMTP。SMTP的设计在处理邮件时包括多个 “身份”。MAIL FROM和From头信息都是识别电子邮件发件人的，但它们在SMTP对话中具有不同的意义。第一个代表传送邮件的用户，通常不显示给收件人。第二个代表撰写邮件的用户，并且对收件人可见。此外，SMTP还引入了其他多个发件人身份，如HELO命令、发件人和转发头。在设计中，没有任何东西可以强制执行这些身份之间的一致性。因此，该设计为任何认证机制提出了一个基本问题：要认证哪个身份？(转自原文Composition Kills: A Case Study of Email Sender Authentication 图3)

2.用SPF/DKIM/DMARC防止欺骗

为了打击电子邮件造假已经开发了各种电子邮件认证机制，包括SPF、DKIM、DMARC、BIMI和ARC。我们的研究重点是前三种机制，因为BIMI和ARC还没有被广泛采用。
SPF：
（Sender Policy Framework）是一种用于防范电子邮件欺诈的技术。它通过验证发件人域名和IP地址之间的关系，以确定是否允许该邮件传递到收件人邮箱。在SPF中，发送域名管理员需要在DNS记录中设置一个文本记录（TXT record），其中包含了哪些IP地址或IP地址段是被授权作为该域名发出电子邮件的。当接收方服务器收到一封带有SPF记录的邮件时，它会检查发送者的IP地址是否与已经授权的列表匹配。如果不匹配，则可以将此邮件标记为垃圾邮件或直接拒绝传送。
DKIM：
（DomainKeys Identified Mail）是一种用于验证电子邮件的技术。它通过数字签名机制，对发件人域名和邮件内容进行加密处理，并将签名添加到邮件头部。当接收方服务器收到这样的带有DKIM签名的邮件时，可以使用该域名公钥来验证签名是否有效。在DKIM中，发送者在DNS记录中设置一个公钥（public key），并将其与组成电子邮件消息的各个部分进行哈希运算得到一个新数值后进行数字签名。接收方服务器则从DNS查找该域下存储的公钥信息，并使用此公钥解密电子信封上所附属的数字签章以确定是否有效。
DMARC：
（Domain-based Message Authentication, Reporting and Conformance）是一种用于验证电子邮件的技术。它结合了SPF（Sender Policy Framework）和DKIM（DomainKeys Identified Mail）两种技术，为域名所有者提供了更加全面、准确的邮件身份验证机制。在DMARC中，发送方在DNS记录中设置一个策略表述该如何处理未通过SPF和DKIM检查的邮件，并指定接收方如何向其报告此类问题。当接收方服务器收到一封带有DMARC记录的邮件时，它会对发件人地址进行认证，并根据策略要求采取相应措施，比如将其标记为垃圾邮件或直接拒绝传送等。同时，在DMARC中还可以配置详细报告功能以便域名所有者监测电子邮件流量并及时修复任何漏洞。这些报告包括每个IP地址与域名之间是否存在匹配关系、签名是否有效等信息。

3.电子邮件处理流程

图4显示了电子邮件处理流程中的主要组成部分。(转自原文Composition Kills: A Case Study of Email Sender Authentication 图4)

一封由发送服务器发送的电子邮件在到达最终用户收件人之前要经过两个阶段：
1)由接收服务器验证，由邮件用户代理（MUA）显示。在第一个阶段，接收服务器会验证邮件是否确实是由声称的地址发送的、 如上节所述。如果该邮件通过了 DMARC验证，它就进入了用户的收件箱。
2)在第二阶段，MUA（例如，本地邮件客户端和 网页界面）解析经过验证的邮件，并将邮件显示给最终用户收件人。显示给最终用户的收件人，包括可能的、 包括对发件人身份的证明。尽管经过认证的 电子邮件在其标题中包括不同的发件人识别信息如发件人标题、MAIL FROM（又称返回路径）和 DKIM-签名头，但通常MUA只显示 “发件人"作为邮件发件人。因此，From头 提供了与获得用户信任有关的关键身份信息，因此值得特别保护。

三、 电子邮件认证中的产生的挑战

本部分主要分析在电子邮件发送和展示链中，不同的处理组件的组成是如何产生一系列漏洞来破坏发件人认证。

1.威胁模型

我们考虑三种类型的欺骗攻击者：
1）伪造攻击者:
伪造攻击者可以直接从他们的邮件服务器（attack.com）向受害者（victim@victim.com）发送任意的电子邮件。攻击者在 "发件人 "标题中把电子邮件的发件人伪造成一个合法网站的地址
(admin@legitimate.com)，而这是电子邮件认证机制应该防止的。
2）重放攻击者:
重放攻击者拥有由合法网站域名签名的有效DKIM签名的电子邮件。这些攻击者利用了对电子邮件标题的修改，还有可能是对电子邮件正文的修改，这不会破坏DKIM签名。这些攻击者可以从广告邮件、注册邮件或公共邮件列表等处获得此类DKIM签名的邮件。
3）拥有合法电子邮件服务账户的攻击者:
合法电子邮件供应商的恶意用户利用了一些电子邮件供应商未能对从本地MUA收到的电子邮件进行充分验证的情况。这些攻击者可以发送带有欺骗性的发件人标题的电子邮件。被利用的电子邮件供应商可能会自动将DKIM签名附加到他们发出的电子邮件上，使攻击者能够冒充其他
攻击者能够冒充该电子邮件提供商的其他用户。

在这项工作中，我们假设受害者情况如下：
1）目标合法网站正确配置SPF/DKIM/DMARC机制，
2）目标电子邮件服务拒绝未能通过DMARC认证的电子邮件。
在这样的部署环境中，电子邮件认证系统应该防止欺骗性的电子邮件通过认证测试，确保终端用户总是看到经过认证的电子邮件发件人地址。

安全要求:
一个电子邮件系统应该提供以下基本的安全要求： 使用电子邮件客户端C从接收服务器R接收电子邮件的最终用户Bob可以确定该邮件确实来自发送服务器S的用户Alice，即满足：

1. S发送的电子邮件的发件人头与被认证的用户名相匹配（S的其他用户不能欺骗Alice的地址）；
2. R中的SPF/DKIM/DMARC组件可以获得S的DNS正确策略；
3. R中的SPF/DKIM和DMARC组件一致认证相同的标识符；
4. R认证的标识符与C显示给Bob的标识符一致。

维护安全求的困难：
这个要求虽然很直观，但却意味着一套语义绑定关系，电子邮件处理链中的每个组件都必须尊重。这样做会带来相当大的挑战，特别是对于由不同的开发者构建的不同组件的分散系统。
1）跨组件协调的困难
虽然有标准来确保不同的组件以可预测的方式行事，但标准文件往往提供模糊的隐含描述，可以有不同的解释。例如，当 DMARC 利用 SPF 来防止电子邮件欺骗时，DMARC 组件可能会假定，如果 MAIL FROM 地址不是空的，SPF 组件总是会验证 MAIL FROM 的标识符；但是 SPF 并没有提供这种保证。SPF 组件可能会转发HELO 认证结果，并让 DMARC 自己检查哪个身份得到了验证。因此，DMARC 和 SPF 组件会验证不同的标识符，从而导致导致绕过电子邮件认证。
2) 与稳健原则的紧张关系
Postel’s Law鼓励实施者在处理畸形输入时采取宽容的态度。虽然这样做可以极大地促进信任方之间的连接，但在对抗性的背景下，它也可以引入可利用的模糊性，即邮件服务器和邮件客户端之间对容忍畸形的From头的不同偏好会导致许多邮件欺骗攻击。
3) 功能组件的危险
实施方案在支持各种特性方面会有不同，比如协议扩展或旧版本，或可定制的功能。当独立检查每个组件时，这种多样化的行为似乎是无害的，但结合起来就会引入安全问题。攻击者可以将不同的功能小工具串联起来，在各组件之间进行意外的计算。例如电子邮件提供商和客户的不同组合可能会出现漏洞，仅仅是因为它们对各种功能的支持不同。

2.测试方法

1）选择电子邮件供应商和客户端

我们选择测试的电子邮件提供商：
<1>为传入的电子邮件验证SPF/DKIM/DMARC；
<2>允许我们注册账户进行测试、
<3>在邮件标题中反映SPF/DKIM/DMARC认证结果。

对于MUAs，我们收集了一份涵盖当今主要平台的流行本地电子邮件客户端的清单。我们还通过使用第三方电子邮件导入功能测试了选定的电子邮件供应商的网络界面。我们总共测试了10个电子邮件供应商和19个MUA，包括9个本地电子邮件客户端和10个网络界面。

2）黑盒测试

我们研究的问题根植于不同程序的不一致的行为。我们的分析遵循以行为为导向的方法，剖析了一个电子邮件认证工作流程，将其分为四个步骤。
<1>首先，我们研究了SMTP和电子邮件规范（包括核心协议和扩展），提取与认证有关的行为，重点是不同身份的词汇、语法和语义规则。
<2>第二，我们通过 "走 "过所提取的规则来产生模棱两可的测试案例，以检查他们的每一个选择点，其方式类似于先前的工作中所采用的寻找IDS规避威胁的方式。
<3>第三，我们利用生成的案例来测试不同的组件在解析和解释模棱两可的信息时是否有不一致的行为。
<4>最后，我们手动分析了所识别的行为，以验证实践中成功的可能性。

当以下两种情况同时存在时，我们将电子邮件认证机制定义为被破坏：
<1>电子邮件服务器错误地验证了测试邮件的发件人没有被欺骗，例如、DMARC认证产生一个 "通过 "的结果；
<2>MUA错误地表明发件人地址是来自一个（合法的）目标域，而不是攻击者的发送域。

为了将我们的结果扩展到闭源的专有系统，我们首先检查了流行的开源SMTP实现，以了解它们可能的相互作用并找到潜在的模糊之处。在这些结果的指导下，我们接着探测了黑盒系统可能的内部逻辑，测试了任何发现的模糊之处，以评估它们是否反映了类似的漏洞。

利用这种方法，我们发现了三类导致 "破碎 "认证结果的攻击：
<1>服务器内部攻击利用了电子邮件服务器不同内部组件之间的模糊性。
<2>用户界面不匹配攻击利用了邮件服务器和MUA之间不一致的解释。
<3>模糊重放攻击产生误导性的DKIM签名的电子邮件，验证为由（合法）目标域签名。

测试结果:
虽然10个电子邮件提供商中的4个可以抵御服务器内的攻击，但所有的电子邮件提供商都有用户界面不匹配和模糊重放攻击的弱点。

四、 服务器内的攻击

服务器内的攻击利用了单一实现的不同内部组件之间的不一致。根据图4可以看出，发件人认证可以包括四个内部组件： SPF、DKIM、DMARC和DNS。对此我们发现了三种技术来利用它们的不一致性：

1.HELO/MAIL FROM的混淆

SMTP 采用了两个不同的标识符–HELO 和 MAIL FROM，来代表发送邮件的发件人。SPF标准(RFC 7208)指出，SPF验证器应该检查这两个标识；检查MAIL FROM是强制性的，而HELO是推荐的。DMARC标准(RFC 7489)指出，DMARC验证器应该使用MAIL FROM身份来执行对齐测试，以验证发件人头中的身份。如果MAIL FROM地址是空的，验证器应该使用HELO身份。
这种设计引入了一种可能性，即不同的组件可能会验证不同的标识。当 SPF 组件不能验证 MAIL FROM 地址，但可以验证 HELO 标识符时，DMARC 组件可能仍然使用 MAIL FROM 标识符进行对齐测试。
为此本文开发了两种技术来利用这些可能性：
1）不存在的子域（A1）。第一种技术将 MAIL FROM 域名制作成一个合法域名的不存在的子域名。SPF 组件无法验证 MAIL FROM 地址，因为这个不存在的域名没有任何 SPF 策略。一些SPF实现（例如Python-postfix-policyd-spf）就会只验证HELO标识符，转发一个 "通过 “的结果，因为HELO域是在攻击者的控制之下。然而，一些DMARC实现（例如，OpenDMARC），仍然使用MAIL FROM域来执行与From头的对齐测试，因为MAIL FROM地址不是空的。这样做颠覆了 DMARC 认证，因为 SPF 检查和 DMARC 对齐测试都显示出积极的结果。
2）"空的 "MAIL FROM地址（A2）。第二种技术是利用组件如何处理空的MAIL FROM地址的差异。一些 SPF 实现将”(any@legitimate.com) "视为一个空的 MAIL FROM 地址，并因此将检查 HELO 的结果转发给 DMARC 组件，因为根据 RFC 5322 ，括号里的字符串可以被解析为一个注释。然而，一些DMARC实现可能会把它当作一个正常的非空地址，并使用它的域来进行对齐测试。

2.模糊的域名

认证组件和DNS组件之间也可能出现不一致的情况：认证组件验证的内容与DNS组件查询的内容不同。因此攻击者可以制作模棱两可的域名，使认证组件认为它在验证合法的域名，但DNS组件实际上是在查询攻击者的域名以获得策略记录。使得认证组件产生 "通过 "的认证结果，因为攻击者控制了通过DNS检索的策略。

3.认证结果注入

潜在的模糊性的另一个载体来自于如何将结果从一个组件传达给另一个组件。通信中元字符的存在带来了 "结果注入 "的可能性，类似于SQL或命令注入。

认证结果头的语法：
这种威胁取决于 SPF 和 DKIM 组件将它们的认证结果转发给 DMARC 组件的细节，以使它能够对 From 头的值进行对齐检查，并且RFC 8601 定义了认证结果头，为通信这些认证结果提供了一个通用框架。
认证结果注入攻击：
漏洞的产生是因为攻击者可以控制嵌入 "header.d "和 "smtp.mailfrom "字段中的域名。并且域名语法的灵活性为攻击者提供了构建畸形域名的肥沃土壤。
虽然许多应用程序要求域名遵循特定的语法规则–例如，域名注册商只允许用户根据LDH规则（只有字母、数字、连字符）注册域名，但DNS协议对域名标签中的字符没有任何限制。特别是，攻击者可以引入包含元字符的畸形域名，例如 “a.com(.b.com”。SPF和DKIM组件可以将这些字符视为数据，而DMARC组件可以将它们解析为控制信息。
本文发现有两种基于这种畸形域名的注入攻击：

1)DKIM认证结果注入

击者可以使用他们自己的私钥生成DKIM-签名头，其 "d="值嵌入了一个字面的开放括号，如 “legitimate.com(.attacker.com”。当收到这个消息时，DKIM组件会查询 “selector._domainkey.legitimate.com(.attacker.com)”–一个由攻击者控制的域，以获得DKIM公钥来验证该消息。然后，DKIM组件生成：

Authentication - results: victim . com ; dkim = pass
(1024 - bit key ) header .d= legitimate . com (.
attacker . com ;

当接收到Authentication-Results头时，DMARC组件将 “header.d “解析为legitimate.com，因为它将”（“后面的内容解析为注释。由于 header.d “的值与From头域相匹配，攻击者的信息通过了DMARC验证。除了”(”，双(”)和单(')引号字符也可以适用于这种技术。因为RFC 5322将引号内的字符定义为原子，DMARC模块可以将引号之后的内容解析为原子的一部分。

2)SPF认证结果注入

攻击者可以在MAIL FROM命令中制作畸形的地址，以绕过SPF和DMARC验证。SPF组件验证了攻击者控制的域名 “legitimate.com(.attacker.com)”，而DMARC模块则采用了域名的前半部分来进行对齐测试。文章中发现，一些邮件服务器对MAIL FROM地址的语法进行了一定程度的验证，并拒绝上述地址。但攻击者可以绕过他们的验证，如图5f所示。在这里，邮件服务器将第二个"@“作为分隔符，并将其识别为一个有效的电子邮件地址，而SPF组件则将第一个”@"作为分隔符，从而查询 “legitimate.com’@a.attack.com”–攻击者的域名，以验证发送IP地址。当DMARC组件解析认证结果时，它把单引号后面的内容作为一个带引号的字符串，并使用 legitimate.com 进行对齐测试。

五、 用户界面不匹配攻击

电子邮件服务器和邮件用户代理（MUA）分别处理信息。UI-mismatch攻击利用了电子邮件服务器验证邮件的方式与MUA最终表明其有效性的方式之间的不一致。一般来说，我们可以把与邮件头有关的处理分为两个阶段：
1.解析MIME信息以提取发件人头；
2.解析发件人头以提取相应的域名或电子邮件地址。
我们同样也将我们的用户界面不匹配攻击分为两类：模糊的发件人头和模糊的电子邮件地址。

1.模糊的发件人头

我们设计了三种技术来利用模糊的发件人头

1) 多个发件人头
要求:
RFC 5322规定，电子邮件必须有一个发件人头.
发现的问题:
这意味着带有多个发件人头的电子邮件是无效的，应该被接收服务拒绝。
测试结果:
我们发现，在29个测试的实施方案中，有19个（包括5个电子邮件提供商和14个MUAs）事实上没有遵循规范，拒绝了这类邮件。所有5个电子邮件提供商都使用第一个发件人进行DMARC检查。iCloud.com（网络）和Mail（Windows）显示最后一个发件人；Mail（MacOS）显示两个发件人；而其他11个MUAs显示第一个发件人。
因此，攻击者可以通过使用一个:
<1>接受多个发件人头的邮件服务器，
<2>与用户的邮件客户端有不同的偏好，来误导用户对邮件发件人有效性的表述

2) 空间包围的发件人
要求:
RFC 5322将电子邮件头定义为一个字段名、一个冒号和一个字段体（值）。如果攻击者违反了这个语法结构，在头名称前后插入了空白，不同的实现会以不同的方式处理这个不符合格式的头。
发现的问题:
我们确定了三种这样的边缘情况：
<1>空格前的发件人头作为第一个头；
<2>空格后的发件人头；
<3>折叠空格后的发件人头。
电子邮件标准隐含地不允许前两种情况，而明确地不允许最后一种情况。
测试结果:
在实践中，我们所测试的实现没有一个是完全符合规范的。Protonmail.com（服务器）拒绝第一和第二种情况，Yahoo.com（服务器）拒绝第三种情况。其他的则承认空格环绕的发件人头是一个有效的发件人头，把它当作一个未知的头，或者解析为 作为一个未知的头，或者将空白处解析为邮件头和正文之间的分隔符 作为邮件头和正文之间的分隔符。
带来的危害:
留白为多种来自歧义的情况提供了新的机会。
<1>首先，使用空白处可以绕过电子邮件服务器的验证。例如，Mail.ru（服务器）拒绝带有多个发件人头的电子邮件，但攻击者可以通过折叠空格的发件人头来绕过它，如图6b所示。
<2>第二，对空白的解释不一致会导致歧义。Mail.ru（服务器）的DMARC组件识别了折叠空格成功的发件人，并验证了attack.com，但Outlook（Windows）将其视为一个未知的头，并将admin@legitimate.com 作为验证的发件人头。有时，我们甚至可以通过利用电子邮件服务器的特殊转发行为，骗过使用相同头信息解析和处理的电子邮件服务器和MUAs。例如，Fastmail.com（服务器）和 Fastmail.com（服务器）和Fastmail.com（网络）都不能识别空格接续的 发件人，但是Fastmail.com（服务器）对空格后的发件人进行规范化处理，在转发时删除空格。移除空格。这种转发行为导致Fastmail.com (Web)识别不同的发件人头。

3) 替代性头文件
要求:
RFC 5322包括多个标头，用于识别不同的电子邮件发件人角色。发件人头代表写邮件的用户，发件人头代表提交邮件的用户，而重发件人头代表转发邮件的用户。

发现的问题:
通常情况下，只有发件人头在电子邮件的验证和显示中起作用。然而，如果一个攻击者制作了一封没有发件人头或发件人不被识别的电子邮件、 一些实施方案将选择使用替代头来识别信息发件人。

攻击者还可以结合不同的技术，以连锁 绕过严格的安全验证的多种功能。例如，Gmail.com（服务器）有严格的信息 验证：它拒绝带有多个发件人头的邮件、 并添加一个新的 "发件人 "头，其值为MAIL FROM，如果如果没有发件人头，就会添加一个新的发件人头。但攻击者可以绕过这个 但攻击者可以通过将一个空格前的发件人头作为第一个头，再加上一个Resent-Family头，来绕过这个验证过程。作为第一个标头，一个Resent-From标头作为替代标头、和空的MAIL FROM值。Gmail.com（服务器）会识别 第一个空格前的发件人头，并使用它来执行 DMARC检查。然后它在邮件前插入一个认证结果头，这导致原始的 "发件人 "头被解析为 "折叠 "行，也就是说，是 "认证结果 "头的延续。即认证结果头的延续。然后，它添加一个新的来自 头，并将信息转发到电子邮件客户端。消息转发给电子邮件客户端。Gmail.com（网络）忽略了 空的发件人，并显示Resent-From头像 值作为信息发件人。

测试结果:
我们发现19个MUA中的7个有这种 行为。Gmail.com (Web)在缺少发件人的情况下，会显示Resent-From头的值。值；其他6个则在发件人字段中的发件人头值。我们测试的所有电子邮件服务器都只使用From头来进行DMARC验证。如果 "发件人 "头没有找到，他们就不执行DMARC 认证，或产生 "无 "的结果。From头和其替代头之间的相互作用引入了另一个模糊的来源。Naver.com（服务器）识别了一个折叠空间成功的发件人并验证了attack.com，但Outlook (Windows)没有识别它，并在发件人中显示（未经验证的）在发件人字段中的发件人头值。

2.模糊的电子邮件地址

即使电子邮件服务器和客户端从MIME信息中提取相同的发件人头，由于发件人头的复杂语法，从该发件人头中提取一个一致的电子邮件地址也是一个挑战。在本节中，开发了一套利用这些复杂性的攻击。
复杂的From头语法：
图7显示了一个有效的带有单个邮箱地址的发件人头，它由四个元素组成。显示名称是一个可选的字段，用于识别发件人的名字。由于这个字段不受SPF、DKIM或DMARC的保护，许多已知的网络钓鱼攻击使用显示名称来欺骗受害者。(转自原文Composition Kills: A Case Study of Email Sender Authentication 图7)
利用复杂的From头信息的攻击:
在解析和解释From头文件时，实现方式各不相同,可能产生安全问题这里我们展示了五种利用这些不一致的攻击：
1）多个电子邮件地址
我们观察到在处理列出多个地址的发件人时有5种不同的行为。
<1>Gmail.com（服务器）和Mail.ru（服务器）拒绝邮件；
<2>Tutanota.com（网络）显示最后一个地址；
<3>Zoho.com（服务器）和iCloud.com（网络）不验证或显示任何地址；
<4>2个邮件服务器和4个MUA验证或显示所有的 地址；
<5>其他所有的都采用第一个地址。

多个电子邮件地址使两种新的模糊的情况发生。
<1>首先，当邮件服务器在发件人中重写地址时 头中的地址时（例如，Protonmail.com（服务器）在发件人中插入了 发件人地址到发件人头中），邮件服务器可能会 识别出一个与客户端显示的电子邮件地址不同的发件人头值。
<2>其次、 如果邮件服务器按原样转发 "发件人 “头，对多个邮件地址的不同解释会直接导致 对多个电子邮件地址的不同解释可以直接导致认证绕过。
2）电子邮件地址编码
在我们的实验中，Yahoo.com（服务器）、Outlook.com（服务器）、iCloud.com（服务器）、Fastmail（服务器）、Zoho.com（服务器）和Tutanota.com（服务器）不识别编码地址，并使用attack.com进行DMARC测试；但Gmail.com（网络）、Outlook.com（网络）、Yahoo.com（网络）、Naver.com（网络）、Mail（MacOS）、Mail（Windows）和Mail（iOS）支持这一编码功能，并且只 显示第一个地址。
3）路线部分
Fastmail.com（服务器）并不识别路由部分、 并把attack.com当作一个真实的地址，用于 DMARC验证；而10个MUA，包括Fastmail.com (Web)，忽略了路由部分，只显示 admin@legitimate.com。
4) 引文对
图8d显示了一个因支持引号对功能的不同而产生的例子。Gmail.com（服务器）和iCloud.com（网络）承认第二个地址；但Mail（Windows）、iCloud（服务器）和 12个其他实施方案只使用第一个地址。 (转自原文Composition Kills: A Case Study of Email Sender Authentication 图8)5）解析的不一致性
本文还发现在识别不同定界符的优先级方面存在不一致。图8e显示了一个例子。Mail.ru（服务器）和Zoho.com (服务器）的DMARC组件认为”<"具有更高的优先级。优先，并验证attack.com；但Outlook（Windows）和其他8个MUAs有不同的偏好，并只显示legitimate.com。

在解析显示名称和真实地址方面的差异还提供了另一个模糊性的来源。如图8f所示，Thunderbird（Linux）、Mail.ru（Web）、Gmail.com (服务器）和Mail.ru（服务器）都错误地验证或显示了 admin@legitimate.com 作为真正的发件人，但Outlook.com(服务器），iCloud.com（服务器），Protonmail.com（服务器）和 9个其他实施方案将其识别为attack.com。

问题拓展
SPF、DKIM和DMARC依靠域名查询进行发件人认证。来进行发件人认证。当无法获得域记录时，邮件服务提供者可能会决定域没有部署相应的安全机制，并允许邮件进入用户的收件箱。利用这种 "失败打开 "功能，攻击者可以进一步利用邮件服务器和MUA之间的不一致来绕过认证

六、模糊重放攻击

攻击者还可以用来自合法域名的看似有效的DKIM签名来欺骗电子邮件，绕过DKIM和DMARC认证保险，使伪造的电子邮件更具欺骗性。DKIM使用数字、加密方法来防止篡改签名内容。然而，有两种DKIM机制使签名欺骗成为可能。首先，DKIM并不能防止重放攻击一个拥有合法域名签名的电子邮件的重放攻击者可以将其重新发送给其他受害者，这是DKIM标准中已经指出的一个已知问题。其次，DKIM允许攻击者在原始邮件上附加额外的邮件头，甚至在某些情况下附加邮件正文内容。结合这两个弱点，重放攻击者可以在不破坏DKIM签名的情况下附加恶意内容，并通过利用DKIM处理和MUA展示之间的不一致，进一步愚弄电子邮件客户端，只显示攻击者的内容。

1.DKIM签名重放攻击

DKIM签名同时保护 邮件头和邮件正文。后者总是被签名。签名 头部的签名是可选的，并由DKIM-签名头的 "h="标签指定。

1) 头部欺骗

本文发现了两种欺骗电子邮件头的技术。
<1>如果 "h="标签中的头文件 h="标签中的头信息是不完整的，重放攻击者可以修改这些未受保护的头信息，并将这些头信息转发给其他攻击者。
<2>虽然在签名中包括所有必要的标头可以防止攻击者篡改它们，但重放攻击者仍然可以通过使用多个标头绕过检查。

2) 主体部分欺骗

除了欺骗电子邮件头之外，攻击者还可以利用DKIM-签名头中的可选 "l="标签来欺骗电子邮件正文，该标签表示签名中包含的电子邮件正文的长度。这个标签是为了增加签名的稳健性 当发送至修改邮件正文内容的邮件列表时。例如，Google Groups通常在每封转发邮件的末尾附加退订信息。这种行为 可以破坏DKIM的验证。使用 "l="允许重放攻击者将新的恶意内容附加到原始邮件正文中而不破坏 DKIM签名。此外，如果内容类型标头 没有受到DKIM签名的保护，攻击者可以进一步改变电子邮件的MIME结构，重新定义它，使邮件客户端只显示攻击者的恶意内容。

2.通过电子邮件服务账户进行欺骗

攻击者也可以利用对电子邮件服务的访问来欺骗具有误导性的DKIM签名的电子邮件。在这种情况下，攻击者在一个合法的电子邮件服务上有一个账户，但是使用一个自定义的MUA，通过该服务发送电子邮件。电子邮件供应商将首先使用在电子邮件服务中提供的用户名/密码来验证MUA的身份。使用AUTH命令中提供的用户名/密码。然后他们会检查邮件中的发件人标题是否 是否与认证的用户名相符。如果是的话，电子邮件提供者 在转发邮件时附上其DKIM签名。问题(A17)出现在一个电子邮件提供者没有对发件人进行充分的检查，从而使攻击者可以用另一个用户的地址（例如，管理员）来发送已签名的邮件。由于该邮件有电子邮件供应商的 的签名，它将通过接收者的 DKIM和DMARC验证。鉴于From头语法的复杂性，其验证是困难和容易出错的。攻击者可以使用如模糊的发件人和电子邮件地址，来绕过电子邮件提供商的验证。

3.颠覆DKIM签名的重放攻击

即使是对执行严格的发件人验证的电子邮件供应商，如Outlook.com，拥有电子邮件服务账户的攻击者也可以使用重放攻击来伪造DKIM签名的电子邮件。
具体实现：
欺骗性攻击（A18）分两步进行。首先，攻击者使用他们的账户通过电子邮件提供商的服务器向自己发送电子邮件。在电子邮件中，攻击者可以在邮件正文、主题头和收件人头中创建欺骗性内容，但鉴于电子邮件提供商的严格验证，不能创建发件人头。当电子邮件提供商发送邮件时，它将其DKIM签名附在邮件上。其次，攻击者在DKIM签名的邮件中添加一个额外的发件人头，其中包含另一个用户的地址，并将其重新发送给受害者。当受害者的电子邮件服务器收到该邮件时，它的DKIM组件可能会验证原始的发件人头，并且该邮件同时通过了DKIM和DMARC验证，而MUA可能会显示假的发件人头。攻击者可以通过利用前面中描述的技术，诱发DKIM组件和电子邮件客户端之间的这种不一致。

七、反馈回复

非关注点，略

八、讨论

1.总评

本文发现的攻击都有一个高层次的主题，就是软件组件之间的不一致。因此这里总结了在整体上表现出来的三个不一致的来源。

1).电子邮件协议定义了多个发件人身份，为实施中的错误解释留下了空间。

例如，HELO和MAIL FROM命令，以及From、Sender和Resent-From头信息，代表了具有类似或多余语义的不同发送角色。虽然严格的规范可以澄清和规范具有混乱语义的协议字段，但当实施者缺乏对规范的全面理解时，往往会出现问题。

2).具有复杂语法的基于文本的协议会导致各种解析的不一致

例如，From头定义了各种复杂的特征，对于这些特征，不同的实现可以选择实现不同的子集。此外，基于文本的协议引入了灵活的格式和容忍度（例如，允许在许多地方自由插入空白和注释），为不一致创造了充足的空间，特别是当实现者在容忍不符合要求的输入方面有差异时。

3).发件人认证的过程涉及一连串的组件，对实现的一致性和正确性产生了强烈的依赖性

如图4中，一封由发件人的MUA发送的电子邮件在到达收件人之前可能至少要经过六个不同的组件处理。处理链中任何两个组件之间的不一致都可能带来歧义。所有这些元素加在一起，形成了一个纠结的局面，人类的实施者和操作者不太可能把它弄好。

2.缓解措施

我们对这些问题提出了一些可能的缓解措施，从直接（主要是）实施层面的改进，到设计协议时更广泛的考虑： 遵循关于DKIM规范的操作指南，防止重放攻击。RFC 6376建议DKIM签名者应在DKIM签名中包括所有重要的头信息，并避免使用 "l="标签以防止欺骗性攻击。RFC 6376还建议DKIM签名者应 “过度签名”，即重复重要的头信息，以防止重放攻击。

改进MUA的显示，MUAs将受益于对如何更好地显示安全功能的系统考虑。我们测试的大多数MUAs都没有明确显示SPF、DKIM或DMARC认证结果，这使得终端用户，特别是移动客户端用户很难理解邮件的认证状态。这种缺陷为攻击者绕过服务器端认证提供了便利，例如，通过附加不可见的字符来欺骗电子邮件服务器，使其无法通过DNS获得策略信息。缓解这种攻击的一个可能的方法是添加图标，表示具有经过验证的发件人域的电子邮件。然而，我们注意到，这种推广HTTPS的方法（通过浏览器显示具有有效TLS证书的网站的可信图标）的经验表明，要确保用户正确地解释这些图标，不被冒名顶替者愚弄是很困难的，我们把上述缓解措施定为 “战术性”：在不大幅重新设计组件或协议的情况下可以做到的步骤。我们现在把更多的战略–但也是更多的–缓解措施框起来。使用规范化。为了防御攻击者使用电子邮件服务的账户，电子邮件供应商可以持续地重新设置邮件标题（如发件人），以消除潜在的歧义。然而，这种方法的有效性仍然依赖于对电子邮件MIME结构的正确解析和解释。我们还提醒，通过与额外的安全组件（如净化器或监控器）的组合来强化一个薄弱的认证系统，其本身会引入复杂的组合，从而产生新的漏洞，正如我们在图6c和6e中所示。利用类型系统来防止内部不一致。我们的一些服务器内部攻击，如注入攻击，源于不同内部组件之间对消息的不一致解释。尽管实施者可以通过过滤引起混乱的特殊字符来解决具体的攻击，但构建完全正确的过滤器可能被证明是具有挑战性的。一个更强大的实现方法是利用一个类型系统，比如用类型来区分一个字段是持有数据还是控制信息。如果进程中不同组件之间的消息转发保留了类型信息，那么就可以用一般的方式解决注入威胁。然而，在不同的进程中采用这种技术是比较困难的，因为对于许多通信框架来说，消息的序列化和反序列化（例如，使用JSON）会失去必要的语义信息。避免重新处理。

UI-mismatch攻击的根本原因是电子邮件提供商和MUA之间的不一致。一个可能的缓解方案7是邮件服务器直接向邮件客户端提供认证信息，这样邮件客户端就可以避免重新解析和重新验证复杂的信息。尽管RFC 8601定义了Authenticationresults头来传达这一信息，但该头本身可以被攻击者伪造。一个更值得信赖的方法是开发一个未来的IMAP/POP3扩展，暴露认证结果。邮件服务器可以通过IMAP/POP3命令将认证信息，包括验证的地址和验证结果，传递给MUAs。然后，MUAs可以显示由邮件服务器暴露的原始信息，而不需要任何额外的解析和验证。

3.总结

我们发现了这么多针对广泛使用的电子邮件服务的攻击，这些攻击是针对网络钓鱼和鱼叉式钓鱼攻击的重要防御措施，这为多组件互联网服务的潜在脆弱性提供了警醒。虽然攻击的具体细节反映了各种电子邮件协议和机制的特殊性，但从抽象的角度来看，这些攻击利用了其他复杂的多组件服务中可能存在的几类漏洞。一般来说，要使不同的开发者所构建的组件完全一致是很困难的：
1）规范允许自由解释细节；
2）很容易忽视攻击者提供的输入中故意含糊不清的可能性；
3）规范本身随着时间的推移而演变，一些组件为了兼容而保留过时的功能；
4）组件在实现一套复杂功能的哪个子集方面可能有所不同；
5）组件在容忍不符合要求的输入方面可能有所不同；
6）复杂组件之间的功能等价检查是难以实现的。

我们发现的许多漏洞不是由编程错误引起的，而是由预期的功能引起的。当一个组件独立运行时，这些功能似乎是无害的，但当集成到一个更大的系统中时，它们会带来安全问题。这些攻击强调了现代系统建设中的一个广泛威胁。此外，一个系统的组成越复杂，它可能有更多的不一致之处，很可能造成更多的漏洞。

个人思考

一、个人总结

本文从不同组件之间对信息的解释不一致下手，着眼于邮件传输过程中不同组件对传输信息的处理核查，因为不同组件间相互独立，从而导致不同组件对身份认证等的处理存在不一致的问题，特别是不同组件间不存在/未严格遵守一套完善的传输保障机制，为此本文着眼于传输中的各个流程，研究各个步骤可能被利用的漏洞，通过研究不同组件间的验证机制，特别是对接双方因为各自独立编程实现很容易产生不一致的情况，从中查找可能的漏洞并按产生的不同部分分为不同类型，对不同类型问题再进行进一步分析研究，并且发现几乎所有邮箱都存在这样的漏洞。

二、思路剖析

1.发现邮件传输中不同部分是采用组件编程，即独立编程实现的。
2.因为各自是独立实现，发现可能存在校验机制上的不一致问题，从而可能产生安全漏洞。
3.具体化和细化邮件传输过程中的具体流程和步骤，对不同部分进行细致分析研究，对不特别是对接出不同部分的策略之间的差异，从而发现漏洞
4.按产生的原因和流程细化漏洞并从底层原理(头部/主体信息组成)剖析原因
5.测试主流邮箱中是否存在发现的问题
6.对发现的问题按照产生原因提出可能的缓解措施

三、大胆揣测

本文只研究了邮箱中验证的问题，实际上组件编程非常热门，远不止邮箱中存在，为了细化、具体化工作，以及方便开发实现提高效率，组件编程存在几乎所有应用中，除了邮箱需要进行身份验证，在其它诸如应用链接建立等处也存在类似的情况，这些地方是否也存在类似的问题呢？