作为一种基本的通信服务，电子邮件在个人和公司通信中都扮演着重要角色，这也使其成为最常见的攻击媒介之一。多个协议、角色和服务的身份验证链确保了电子邮件的真实性，任何失效的部分都可能破坏整个基于链的防御。本文系统地分析了电子邮件的传输，并确定了一系列能够绕过SPF，DKIM，DMARC和用户界面保护的新攻击。特别是通过进行cocktail组合攻击，可以伪造更真实的虚假电子邮件来渗透电子邮件服务，例如Gmail和Outlook。本文对30种流行的电子邮件服务和23个电子邮件客户端进行了大规模验证，发现它们都容易受到某些类型的攻击。已将发现的漏洞功能及时报告给相关的电子邮件服务提供商，并从包括Gmail，Yahoo，iCloud和Alibaba在内的11家公司收到了肯定的答复。
0x01 Introduction
电子邮件服务是当下必不可少的通信服务，这使其成为网络攻击的主要目标。但是，电子邮件传输协议远不能抵抗潜在的攻击。电子邮件系统的安全性依赖于由各种电子邮件服务维护的多方信任链，这增加了其对网络攻击的系统脆弱性。如下图所示，电子邮件传输过程中的身份验证涉及四个重要阶段。
正如木桶理论所揭示的，桶的容量取决于其最短的板，电子邮件的真实性取决于身份验证链中最薄弱的环节。首先，尽管存在各种用于识别欺骗电子邮件的安全扩展协议（例如SPF，DKIM和DMARC），但由于受不同协议保护的实体不一致，欺骗攻击仍可能成功。其次，电子邮件的身份验证涉及四个不同的角色：发件人，收件人，转发者和UI渲染器。每个角色应承担不同的安全职责。如果角色都无法提供适当的安全防御解决方案，则无法保证电子邮件的真实性。最后，安全机制是由具有不一致处理策略的不同电子邮件服务实现的。这些安全机制是由不同的开发人员实现，其中一些在处理带有模糊header的电子邮件时会偏离RFC规范。因此，不同的服务之间存在许多不一致之处。攻击者可以利用这些不一致来绕过安全机制，并向电子邮件浏览器端和电子邮件客户端呈现虚假结果。
这项工作系统地分析了电子邮件传递过程中身份验证的四个关键阶段：发送身份验证，接收验证，转发验证和UI呈现。发现14种电子邮件欺骗攻击能够绕过SPF，DKIM，DMARC和用户界面保护。通过组合不同的攻击，欺骗电子邮件可以完全通过所有当前流行的电子邮件安全协议，并且收件人的MUA上不会显示任何安全警告。
为了了解欺骗电子邮件攻击对电子邮件生态系统的实际影响，对30种流行的电子邮件服务进行了大规模实验，这些服务的用户总数达数十亿。此外还在不同的操作系统上测试了23个流行的电子邮件客户端，以衡量攻击对UI级别的影响。它们都容易受到某些类型的攻击，包括信誉良好的电子邮件服务，例如Gmail和Outlook。已经向涉及的电子邮件服务提供商妥善报告了所有已发现的问题，并从其中的11家（例如Gmail，Yahoo，iCloud，Alibaba Cloud）获得了积极的回应。
0x02 Attack Model and Experiments
A.攻击模型
如上图所示，电子邮件欺骗攻击的攻击模型包括一个受信任的电子邮件发送者（Alice，在a.com下拥有电子邮件帐户），一个受害者接收者（Bob，在b.com下拥有一个电子邮件帐户）和一个攻击者（Oscar）。Oscar的目标是向Bob发送电子邮件，伪装成Alice@ a.com并绕过所有安全验证。通常，电子邮件欺骗攻击有以下三种常见类型。
共享MTA攻击（Shared MTA Attack）：假设Oscar拥有一个电子邮件帐户（Oscar@ a.com），该帐户不同于Alice的帐户（Alice@ a.com）。 Oscar可以通过修改Mail From / From / Auth username header，通过a.com的MTA发送欺骗性电子邮件。由于发件人的MTA IP信誉是影响垃圾邮件引擎决策算法的重要因素，因此欺骗电子邮件可以轻松进入受害者的收件箱。发件人的MTA的IP在a.com的SPF范围内。发件人的MTA可能还会自动将DKIM签名附加到欺骗电子邮件中。Oscar绕过SPF / DKIM / DMARC验证并欺骗Alice@ a.com几乎没有困难。
直接MTA攻击（Direct MTA Attack）：Oscar还可以通过自己的电子邮件服务器发送欺骗性电子邮件。请注意，发送者的MTA与接收者的MTA之间的通信过程没有身份验证机制。 Oscar可以通过指定Mail From和From header来欺骗任意发件人。这种攻击模型可以确保所有欺骗性电子邮件都到达收件人的MTA，而不会受到发件人MTA严格发送检查（strict sending check）的影响。
转发MTA攻击（Forward MTA Attack）：Oscar可以通过滥用电子邮件转发服务来发送欺骗性电子邮件。首先，Oscar将欺骗性电子邮件发送到Oscar@ a.com，这是转发电子邮件服务上属于Oscar的电子邮件帐户。接下来，他可以配置转发服务以自动将此欺骗邮件转发给受害者（Bob@ b.com）。此攻击模型具有三个主要优点。首先，此攻击与共享MTA攻击模式具有相同的优势，因为收件人的MTA（b.com）认为电子邮件来自合法的MTA（a.com）。此外，此攻击还可以绕过发件人MTA的严格发送检查（例如，Mail From和From header之间不匹配）。最后，转发服务可以为转发的电子邮件提供更高的安全性认可（例如，添加不应添加的DKIM签名）。
因此，发件人身份验证问题可以分为四个阶段，包括发送身份验证，接收验证，转发验证和UI呈现，这些阶段可以缓解潜在的安全威胁。此外，将成功攻击的目标定义如下：（1）接收者的MUA错误地呈现了发件人地址，因为它来自合法域名，而不是攻击者的真实域名； （2）收件人的MTA错误地验证了欺骗电子邮件的发件人； （3）收件人的MUA不显示任何用于欺骗电子邮件的安全警报。
上图显示了使用直接MTA攻击和转发MT攻击模型成功进行电子邮件发件人欺骗攻击的示例。。所有这三种电子邮件安全协议都会为欺骗性电子邮件提供“pass”验证结果。此外，接收方的MUA不显示任何安全警报。受害人几乎无法识别来自这种看似真实的欺骗电子邮件的任何攻击痕迹。因此，即使对于具有技术背景的人来说，要弄清这种电子邮件是否是欺骗也是具有挑战性的。
B.目标选择
本研究系统地分析了30种电子邮件服务，包括最受欢迎的免费公共电子邮件服务，企业级电子邮件服务和托管的电子邮件服务。总共选择22种流行的电子邮件服务，它们的用户超过10亿，他们的安全问题可能会使广泛的普通用户受到威胁。此外还选择了Office 365，Alibaba Cloud和Coremail等5种流行的企业电子邮件服务，以测试对机构用户的威胁影响。对于托管电子邮件系统，构建\部署和维护3个著名的电子邮件系统（即Zimbra，EwoMail，Roundcube）。此外，测试了针对不同桌面和移动操作系统中23个广泛使用的电子邮件客户端的攻击，以评估对UI呈现的影响。
C.方法
这项工作旨在涵盖整个电子邮件传递过程中所有可能的验证问题。因此进行了五个步骤的安全性分析：首先系统地分析电子邮件规范。在语法方面提取ABNF规则，重点关注与身份验证相关的header（例如Mail From / From / Helo / Sender）。在语义方面，关注是RFC中每个阶段的电子邮件身份验证。其次，收集合法的电子邮件样本，并根据ABNF语法生成带有认证相关header的测试样本。由于普通邮件服务通常拒绝处理具有高度变形header的电子邮件，因此将指定某些header的值。例如，将domain的值限制为几个著名的电子邮件域名（例如，gmail.com，icloud.com）。第三，在协议模糊化中引入了常见的变异方法，例如header重复，插入空格，插入Unicode字符，header编码和大小写变化。第四，使用生成的样本在四个阶段中测试目标电子邮件系统的安全验证逻辑。最后分析并总结了使电子邮件发件人欺骗在实践中成功的对抗技术。
D.实验设置
成功的攻击：如果满足以下四个条件之一，则认为电子邮件欺骗攻击成功。
（1）在电子邮件发送验证阶段，攻击者可以任意修改标识符（例如，Auth username/ MAIL From/ From）。
（2）在电子邮件接收验证阶段，即使被欺骗域名已经部署了严格的SPF / DKIM / DMARC策略，收件人的MTA也会给出“none/pass”验证结果。由于验证结果并不总是显示在电子邮件header中，因此可以通过检查电子邮件是否已进入收件箱作为替代来推断结果。此外，如果欺骗性电子邮件被放入垃圾邮件箱，则认为攻击失败，这意味着收件人的MTA已检测到欺骗性并采取了防御措施。为避免意外情况，将每个攻击重复三遍，以确保欺骗电子邮件实际上已渗透到安全协议中。只有所有三遍都起作用的攻击才被视为成功攻击。
（3）在电子邮件转发阶段，转发者对转发的电子邮件给予更高的安全性认可。此外，如果攻击者无需任何身份验证就可以将转发的电子邮件自由配置到任何帐户，则攻击也被认为是成功的。
（4）在电子邮件UI呈现阶段，显示的电子邮件地址与真实电子邮件地址不一致。在此阶段，由于仅需要检查，因此使用IMAP协议的APPEND功能将欺骗的电子邮件发送到收件箱，因为只需要检查UI呈现结果，而不是绕过垃圾邮件引擎。最后，收集信息并根据UI级别上的电子邮件浏览器端和电子邮件客户端分析结果。
测量偏差最小化：首先，为了排除垃圾邮件检测的影响，选择了某个行业合作伙伴（一家著名的电子邮件提供商）提供的合法、良性和不敏感的电子邮件样本作为欺骗电子邮件的内容。这些电子邮件的内容是合法且无害的，不能被视为垃圾邮件。其次，所有欺骗电子邮件都是从位于不同区域的15个IP地址发送的，间隔为10分钟。此外为攻击者的域名和IP地址部署MX / TXT / PTR记录。第三，为了测试收件人的MTA如何处理带有“fail” SPF / DMARC验证结果的电子邮件，针对目标30个电子邮件服务进行了欺骗实验，发现其中有23个拒绝带有“fail”的SPF / DMARC验证结果的电子邮件。其余的将它们标记为垃圾邮件。
E.实验结果
发送方欺骗攻击的实验结果如上表，总结了以下实验结果。首先，测量了这些电子邮件服务对电子邮件安全协议的部署和验证。所有电子邮件服务都在发件人一方部署SPF协议，而只有23个服务部署全部三种协议。出乎意料的是，所有电子邮件服务都在接收方运行SPF，DKIM和DMARC检测。但是，只有12个服务执行发件人不一致检查。其次，所有目标电子邮件服务和电子邮件客户端都容易受到某些类型的攻击。最后，组合攻击使攻击者能够伪造看上去更真实的欺骗电子邮件。具体攻击方法（A1-A14）在下文中介绍。
0x03 Email Sender Spoofifing Attacks
将攻击分为四类，分别对应于电子邮件传递过程中的四个身份验证阶段。
A.邮件发送认证中的攻击
电子邮件发送验证是确保电子邮件真实性的必要步骤。电子邮件发送身份验证中的攻击可能会滥用知名电子邮件服务的IP信誉。他们甚至可以绕过SPF / DKIM / DMARC协议的所有验证，这对电子邮件安全生态系统构成了重大威胁。这些攻击主要用于共享攻击模型（Model a）。
电子邮件发送过程中有三个发件人标识符：(1) Auth username; (2) Mail From; (3) From。攻击被认为是成功的，当它可以在电子邮件发送认证过程中任意控制这些标识符。
Auth username和MailFrom header之间不一致（A1）：如上图a所示，攻击者可以假装是当前域名下的任何用户，以发送在电子邮件发送身份验证期间Auth username（Oscar@ a.com）和Mail From（Alice@ a.com）不一致的欺骗电子邮件。 SMTP协议不提供任何内置的安全功能来保证auth username和Mail From header的一致性。因此，这种类型的保护仅取决于电子邮件开发人员的软件实现。
在欺骗实验中，大多数电子邮件服务都没有发现此类问题，并禁止用户发送与其原始身份不一致的电子邮件。但是，这种类型的问题仍然出现在某些著名的公司电子邮件软件（即Zimbra，EwoMail）中。在默认安全配置下，这两个电子邮件服务容易受到攻击。电子邮件管理员需要升级其安全配置，以手动防止此类问题。
MailFrom与From之间的不一致（A2）:攻击者可以发送带有不同Mail From和From header的欺骗电子邮件。上图b显示了这种类型的攻击。尽管允许某些用户使用电子邮件别名来发送带有不同的From header的电子邮件，但不应允许任何用户将From header随意修改为任何值（例如admin@ a.com）以防止受到攻击。仅应在有限的合法值内设置From header。许多流行的电子邮件服务（例如Outlook，Sina，QQ邮件）和大多数第三方电子邮件客户端（例如Foxmail，Apple Mail）仅显示From header，而不显示Mail From header。对于具有不同Mail From和From header的邮件，受害者甚至无法在MUA上看到任何安全警报。
RCPT To和To header之间也存在类似的不一致。在现实世界中，有些场景会导致不一致，例如电子邮件转发和密件抄送。但是，这种灵活性增加了攻击面并引入了新的安全风险。例如，即使电子邮件的From header不是受害者的地址，攻击者也可以将电子邮件发送给受害者。在这种情况下，攻击者可以进一步使用此方法来获取通常无法获得的带有DKIM签名的欺骗电子邮件，这对于进一步的攻击很有帮助。单独使用时，此技术可能无效，但与其他攻击技术结合使用时，通常可以达到出色的欺骗效果。
在实验中，有14种电子邮件服务容易受到此类攻击。此外，还发现某些电子邮件服务（例如Outlook，Zoho，AOL，Yahoo）已经意识到了这些风险，并实施了相应的安全限制。他们拒绝在SMTP发送过程中发送带有不一致的MailFrom和From header的电子邮件。但是，仍然可以通过两种类型的攻击（即A4，A5）来绕过这些防御措施。例如，可以在Yahoo中发送带有From header为< Oscar@ a.com>和 From header为< Alice@ a.com，Oscar@ a.com>的欺骗电子邮件，这引入了另一种歧义源，并最终绕过了电子邮件协议验证。因此，即使发件人已经部署了相关的安全措施，仍然可能发送这种欺骗性电子邮件。
B.电子邮件接收验证中的攻击
SPF，DKIM和DMARC是用于抵抗电子邮件欺骗攻击的流行机制。如果攻击者可以绕过这些协议，则也可能对电子邮件安全生态系统构成严重的安全威胁。可以使用三种攻击模型来发起这种类型的攻击：共享MTA攻击，直接MTA攻击和转发MTA攻击。当接收方的MTA错误地获得“none/pass”验证结果时，攻击成功。
空Mail From攻击（A3）： RFC 5321明确描述了允许一个空的Mail From，主要用于防止回弹回送并允许某些特殊消息。但是，也可以滥用此功能来发起电子邮件欺骗攻击。如下图所示，攻击者可以发送带有空的Mail From header的电子邮件，而From header构成了Alice的身份（Alice@ a.com）。
SPF协议规定，如果Mail From header为空，则接收者的MTA必须根据Helo字段完成SPF验证。但是，现实生活中滥用Helo字段使某些电子邮件服务违反了标准并采取了更为宽松的验证方法，因此，当收件人处理这些电子邮件时，他们无法基于Helo字段完成SPF验证，而是直接返回“none”。此类错误使攻击者可以绕过SPF保护。结果，攻击者可以将此攻击的SPF结果从“fail”更改为“none”。
13种电子邮件服务（例如Yahoo，Yeah，126，Aol）容易受到此类攻击。幸运的是，已经有17个电子邮件服务解决了此类安全问题，其中有5个（例如Zoho.com，iCloud.com，exmail.qq.com）已将此类电子邮件丢弃为垃圾邮件。
多From header（A4）：From header有多种变形，例如在From之前和之后添加空格，大小写转换以及插入不可打印的字符。如上图所示，攻击者可以构造多个From header来绕过安全策略。RFC5322表示通常会拒绝具有多个From字段的电子邮件。但是，仍然有一些电子邮件服务无法遵循协议，无法接受带有多个From header的电子邮件。它可能会在电子邮件接收验证阶段引入不一致之处，从而可能导致其他安全风险。上图c显示了一个示例，显示的发件人地址为Alice@ a.com，而收件人的MTA可以使用Oscar@ attack.com进行DMARC验证。
只有4个邮件服务（即Gmail，Yahoo，Tom和Aol）拒绝具有多个From header的电子邮件，而这种攻击会影响19个邮件服务。大多数经过测试的电子邮件服务倾向于在网络邮件上显示第一个From header，而6个服务（例如iCloud，Yandex，Alibaba Cloud）选择显示最后一个From header。此外，有7家供应商已针对此类攻击制定了特定的安全法规，例如在网络邮件上同时显示两个发件人地址（例如QQMail，Coremail）或将此类电子邮件放入垃圾邮件文件夹（例如Outlook，rambler.ru）。
多邮件地址（A5）：使用多个电子邮件地址也是绕过协议验证的有效技术。多个地址的使用最早是在RFC2822中提出的，并在RFC5322中仍被明确允许。它适用于以下情况：具有多个作者的电子邮件应在发件人中列出所有作者。然后，添加“Sender”字段以标记实际发件人。如上图a所示，攻击者可以使用多个电子邮件地址（< Alice@a.com>，< Oscar@ attack.com>）绕过DMARC验证。此外，还可以对这些地址进行基于规则的更改，例如[Alice@ a.com],\< Oscar@ attack.com>。
15个邮件服务（例如QQ邮件，21cn.com和onet.pl）仍将接受此类电子邮件。只有4个服务（例如Gmail和Mail.ru）直接拒绝这些电子邮件，其他5个服务（例如zoho.com，tom.com，outlook.com）将它们放入垃圾邮件，其余6个服务（例如139.com ，cock.li和Roundcube）显示所有这些地址，从而使欺骗电子邮件更难以欺骗受害者。
解析不一致攻击（A6）：Mail From和From header为富文本格式，具有非常复杂的语法格式，正确解析显示名称和真实地址是一项挑战。这些不一致之处可以使攻击者绕过身份验证并欺骗其目标电子邮件客户端。
邮箱地址是这两个header的基本组成部分之一。首先，当邮箱地址包含在“ <”and”>”中时，允许其在真实发件人地址的前面具有路由部分。因此，邮箱（< @ a.com，@ b.com：admin@ c.com>）仍然是合法地址。其中，@ a.com，@ b.com是路由部分，“ admin@ c.com”是真实发件人的地址。其次，允许使用邮箱列表和地址列表并且它们可以具有“null”成员，例如< a@ a.com>，< b@ b.com>。第三，注释是用括号括起来的字符串。允许在本地部分和域的句点分隔的元素之间，例如< admin(username)@ a.com(domainname)>。最后，在From header中有一个可选的显示名称。它指示发件人的姓名，显示给收件人。下图显示了基于解析不一致的三种类型的攻击。
截断字符是终止字符串分析的一系列字符。当从电子邮件header中解析和提取目标域名时，被截断的字符将结束解析过程。上图d显示，当从字符串“ admin@ a.com\x00@ attack.com”解析目标域名时，程序获取的域名不完整（a.com）。攻击者可以使用这些技术来绕过电子邮件安全协议的验证。总的来说，这项工作在电子邮件字符串解析过程中发现了三种截断的字符。首先，NUL（\ x00）字符可以使用C编程语言终止字符串，在电子邮件字段中具有相同的作用。其次，一些看不见的Unicode字符（例如\uff00-\uffff,\x81-\xff）也可以终止字符串解析过程。第三，某些语义字符，例如“ “[,],{,},\t,\r,\n,;”，可用于指示词法分析中的标记化点。同时，这些字符也影响字符串的解析过程。发现在这种攻击下，有13个电子邮件服务在UI呈现阶段存在问题。对于Gmail和Yandex，可以使用这些攻击技术绕过DMARC。
基于编码的攻击（A7）：RFC 2045（MIME）描述了一种表示文本正文部分的机制，这些正文部分以各种字符集编码。这些部分的ABNF语法如下:=?charset?encoding?encoded-text?=。 “charset”字段指定与未编码文本关联的字符集； “ encoding”字段指定编码算法，其中“ b”代表base64编码，“ q”代表带引号的可打印编码； “encoded-text”字段指定编码的文本。攻击者可以使用这些编码的地址来逃避电子邮件安全协议的验证。上图a显示了这种攻击的细节。对于诸如From:=?utf-8?b?QWxpY2VAYS5jb20=?=这样的编码地址，大多数电子邮件服务在验证DMARC协议之前不会对地址进行解码，因此无法提取准确的域并在其中获得“无”以下DMARC验证。但是，某些电子邮件服务在MUA上显示解码的发件人地址（Alice@ a.com）。此外，该技术可以与截断的字符串结合使用。如上图b所示，攻击者可以将From header构造为“ b64(Alice@ a.com>b64(\uffff)@ attack.com”）。电子邮件客户端程序可能会获得不完整的用户名（即Alice@ a.com），但它仍将使用攻击者的域（attack.com）进行DMARC验证。7个电子邮件服务受此漏洞的影响，其中包括一些拥有超过十亿用户的流行服务（例如Outlook，Office 365，Yahoo）。
子域攻击（A8）：攻击者可以从不存在的知名电子邮件服务的子域（没有MX记录）发送欺骗电子邮件（例如admin@ mail.google.com）。因此，没有相应的SPF记录。 欺骗电子邮件仅收到none”验证结果，收件人的MTA不会直接拒绝它。尽管父域（例如google.com）部署了严格的电子邮件策略，但攻击者仍然可以这种方式进行攻击。不幸的是，许多公司使用子域来发送业务订阅电子邮件，例如Paypal，Gmail和Apple。结果，普通用户倾向于信任此类电子邮件。
不幸的是，RFC 7208声明不鼓励使用通配符记录来发布SPF记录。很少有电子邮件管理员在现实世界中配置通配符SPF记录。此外，收件人的MTA通常可以拒绝来自没有MX记录的域的电子邮件。但是RFC 2821提到，当域没有MX记录时，SMTP会假定A记录就足够了，这意味着具有A记录的任何域名都可以被视为有效的电子邮件域。此外，许多知名网站都部署了通配符DNS A记录，从而使这种攻击更加适用。结果，收件人的MTA很难确定是否拒绝此类电子邮件。
实验结果表明，有13种电子邮件服务容易受到此类攻击。在实验中，只有一个电子邮件服务（Mail.ru）为SPF记录部署了通配符DNS条目。默认情况下，为组织域设置的DMARC策略应适用于任何子域，除非已为特定子发布了DMARCrecord -领域。但是，实验结果表明，即使接收方的MTA进行了DMARCcheck，攻击仍然有效。
C.电子邮件转发验证中的攻击
这项工作表明，攻击者可以滥用电子邮件转发服务来发送欺骗性电子邮件，而这种欺骗性电子邮件将在sharedMTA攻击模型中失败。此外，转发服务可以为转发的电子邮件提供更高的安全性认可。攻击者可以利用这两种情况发送欺骗性电子邮件。
未经授权的转发攻击（A9）：如果攻击者可以在不进行任何身份验证验证的情况下将转发的电子邮件自由配置到任何帐户，则电子邮件服务存在未经授权的转发问题。首先，攻击者应在电子邮件转发服务上拥有一个合法的电子邮件帐户。因为这些电子邮件是从一个热门的电子邮件转发MTA发送的，因此收件人的MTA通常会接受此类电子邮件。当目标域名与转发域名相同时，还可以利用转发服务绕过SPF和DMARC协议。此攻击如下图所示。基于此攻击，攻击者可以滥用众所周知的MTA的信誉来制作真实的欺骗性电子邮件。
在实验目标中，有12个电子邮件服务具有此类漏洞。 7电子邮件服务不提供电子邮件转发功能。其他电子邮件服务已经意识到了风险，并进行了相应的转发验证以解决此问题。
DKIM签名欺骗攻击（A10）：转发服务可以为转发的电子邮件提供更高的安全性认可。但是攻击者可能滥用此功能来发送欺骗性电子邮件。如果转发的电子邮件没有DKIM签名或之前未通过DKIM验证，则转发者不应添加其域名的DKIM签名。否则，攻击者可以欺骗合法DKIM签名的转发服务。但是，RFC 6376和RFC 6377均建议转发者将其签名添加到转发的电子邮件中。这进一步导致更多的电子邮件服务出现此类问题。
上图说明了攻击的完整过程。电子邮件转发服务（a.com）无需严格验证即可对所有转发的电子邮件签名并添加DKIM签名。首先，攻击者可以在电子邮件转发服务下注册一个帐户（Oscar@ a.com）。其次，他可以将所有接收的电子邮件配置为转发到另一个攻击者的电子邮件地址（Oscar@ c.com）。然后，攻击者可以通过直接MTA攻击模型通过From: Alice@ a.com, To: Bob@ b.com到Oscar@ a.com发送欺骗电子邮件。转发服务（a.com）在此欺骗电子邮件中添加了合法的DKIM签名。结果，攻击者收到了带有由a.com签名的合法DKIM签名的欺骗电子邮件。在实验中，Alibaba Cloud，Office 365和Yahoo Email都容易受到此类攻击。
ARC问题（A11）： ARC是一种新提出的协议，它提供了一条信任链，可以在电子邮件转发过程中链接SPF，DKIM和DMARC的验证结果。在实验中，只有三个电子邮件服务（即Gmail，Office 365和Zoho）部署了ARC协议。但是研究发现Office 365和Zoho都在ARC协议实现方面存在安全问题。此外，除了A10攻击外，ARC无法防御上面讨论的大多数攻击。
对于Zoho电子邮件服务，如果电子邮件未通过发件人不一致检查，它将为用户显示警报。但是，Zoho的ARC实施存在错误。当通过Gmail自动将欺骗性电子邮件转发到Zoho邮箱时，Zoho添加的ARC-Authentication-Results（AAR）header显示了错误的“通过” DMARC验证结果。更糟糕的是，这种错误的ARC实现也可能绕过发送方不一致检查。 Zoho不会向用户显示有关此欺骗电子邮件的警报。 Office 365在ARC的实现中也有错误。它在AAR标header中传递了SPF，DKIM和DMARC的错误验证结果。这将破坏ARC信任链，从而引入更多的安全风险。
D.电子邮件UI呈现中的攻击
电子邮件系统的最后也是最关键的部分是确保正确呈现电子邮件。一旦攻击者可以在此阶段采取防御措施，就很容易在不知不觉中通过欺骗邮件欺骗普通用户。显示的地址是MUA上显示的发件人地址，但实际地址是SMTP通信中使用的发件人身份（From）。如果攻击者可以使显示的地址与真实地址不一致，则认为攻击成功。此外，某些MUA向未通过发件人不一致检查的电子邮件添加安全指示符。如果攻击者可以绕过发件人的不一致检查，它也被视为一种有效的攻击技术。
电子邮件UI呈现阶段存在各种攻击，其中一些类似于前面讨论的A6，A7攻击，不同之处在于UI级别攻击的目标是绕过发件人不一致检查并欺骗为用户显示的电子邮件地址，而不是绕过三个电子邮件安全性协议的验证。因此，通常构造模糊From header而不是Mail From header。
IDN同形异义词攻击（A12）：同形异义词攻击是一个已知的Web安全问题，但尚未系统地讨论其对电子邮件系统的安全风险。热门电子邮件提供商逐渐支持来自国际化域名（IDN）的电子邮件，此攻击可能会产生更广泛的安全影响。
Punycode是一种将无法以ASCII显示的单词转换为Unicode编码的方法。值得注意的是，当原始地址不同时，Unicode字符在屏幕上的外观可能相似。上图显示了一个欺骗电子邮件，该电子邮件似乎来自地址（admin@ paypal.com），但实际上来自地址（admin@ xn–aypal-uye.com）。
现代浏览器已针对IDN同形异义词攻击实施了一些防御措施。例如如果域标签包含多种语言的字符，则不应呈现IDN，不幸的是电子邮件系统中几乎没有类似的防御措施。实验结果表明，10种电子邮件服务（例如Gmail，iCloud，Mail.ru）显示出支持IDN电子邮件。当前，只有Coremail可以修复此漏洞。基于本研究，Coremail在地址栏中的Unicode字符前后添加了空格。这样，用户可以轻松区分ASCII字符和Unicode字符，以防止此类攻击。
UI呈现丢失攻击（A13）：本文还发现许多字符会影响MUA的呈现。在呈现过程中可能会丢弃某些字符。此外，某些字符还可能导致电子邮件地址被截断（类似于攻击A6）。这些字符包括不可见字符（U+0000-U+001F,U+FF00-U+FFFF）和语义字符（@,:,;,”）。例如，MUA呈现地址admin@ gm@ ail.com作为admin@ gmail.com。仍有12种电子邮件服务（例如zoho.com，163.com，sohu.com）容易受到这类攻击。其他服务拒绝接收此类电子邮件，或者只是将此类电子邮件扔入垃圾邮件箱。
RTRO（Right-to-left Overrid）写攻击（A14）：设计了几个字符来控制字符串的显示顺序。其中之一是“RIGHT-TO-LEFT OVERRIDE”字符，U+202E告诉计算机以从右到左的顺序显示文本。它主要用于书写和阅读阿拉伯语或希伯来语文本。尽管此攻击技术在其他地方已经讨论过，但尚未充分研究其对电子邮件欺骗的安全风险。攻击者可以将字符串构造为\u202emoc.a@\u202dalice，该字符串显示为Alice@ a.com。由于带有RTL字符的欺骗性电子邮件可能会直接丢入垃圾邮件箱，因此通常对有效载荷（采用utf-8模式）进行编码以进行攻击。11种电子邮件服务（例如Outlook，Yahoo，Yandex）仍然容易受到此攻击。 10个服务（例如cock.li，daum.net，onet.pl）无法正确呈现此类电子邮件地址。其他电子邮件服务直接拒绝了此类邮件。
0x04 Combined Attacks
根据电子邮件传递过程中的四个认证阶段，将攻击分为四类。但是，这些攻击有一定的局限性。首先，某些攻击（例如A2，A3）可能对配方产生欺骗作用。但是，他们无法绕过所有电子邮件欺骗保护。例如，通过来自攻击者的空邮件（A3）的欺骗电子邮件绕过SPF验证，但在DMARC验证中失败。此外，大多数电子邮件供应商已修复了单独进行的攻击，该攻击可以绕过实验中的所有三个电子邮件安全协议。因此，在实践中组合不同阶段的多种攻击更为可行。通过结合不同攻击技术的cocktail组合攻击，可以轻松构建可以完全通过三种电子邮件安全协议和用户界面保护验证的欺骗电子邮件。最后，此欺骗电子邮件与合法电子邮件在收件人的MUA上没有显示任何区别。通过在4个身份验证阶段组合3种类型的攻击模型和14种攻击技术，可以实现多种可行的组合攻击。选择两个最具代表性的示例来说明组合欺骗攻击的效果，下表列出了两个示例的关键信息。
相同攻击模型下的组合攻击：总共确定了14种电子邮件欺骗攻击技术，其中14种攻击技术可以在相同的攻击模型下进行组合以达到更好的攻击效果。此外，尽管某些供应商可以通过一项安全检查来修复漏洞，但攻击者可以准确地组合其他攻击技术来绕过相应的安全检查。
上图显示了共享MTA攻击模型下的代表性示例。Yahoo电子邮件执行简单的发件人检查策略以防御A2攻击。它禁止用户使用不同的Mail From和From header发送电子邮件。但是，攻击者仍然可以通过A4攻击绕过此发件人检查策略。具体来说，可以发送带有第一个发件人header（Oscar@ yahoo.com）的欺骗邮件，该邮件与Mail From头相同，然后添加第二个发件人header（Admin@ paypal.com）。 iCloud不会拒绝具有多个From header的此类欺骗电子邮件。更糟糕的是，iCloud使用第一个From header执行DMARC验证并通过yahoo.com获得“pass”结果，而第二个From（Admin@ paypal.com）header则显示在网络邮件的用户界面上，供用户使用。因此，这种组合攻击最终可能绕过所有三个电子邮件安全协议并欺骗MUA。
不同攻击模型下的组合攻击：攻击者还可以通过组合不同的攻击模型来进行更有效的攻击。电子邮件系统是具有多方信任链的复杂生态系统，它依赖于由多方实施和部署的安全措施。在不同的攻击模型下，多个参与方可能具有不同的漏洞。例如，如果电子邮件服务的发送MTA在发送身份验证时进行严格检查，则很难通过共享MTA攻击模型进行攻击。但是，一旦在其他阶段未能提供正确且完整的安全防御解决方案，攻击者仍可以绕过并通过其他两种攻击模型发送欺骗性电子邮件。
上图通过组合直接MTA和正向MTA攻击模型显示了成功的欺骗攻击。例如，Oscar使用攻击技术（A2，A3）发送带有空Mail From和精心构造的From header的欺骗电子邮件。与受害者的帐户不同，Oscar拥有一个合法帐户（Oscar@ aliyun.com）。因此，Oscar可以将该帐户配置为自动将接收到的电子邮件转发到他的一个帐户（Oscar@ attack.com）。Alibaba Cloud服务为所有转发的电子邮件添加了DKIM签名，而无需进行必要的验证检查（A10）。通过电子邮件发送合法的DKIM签名。然后，Oscar可以通过直接MTAattack模型通过MailFrom:< admin@ attack.com>头发送此欺骗电子邮件，如上图b所示。
对于此欺骗电子邮件，SPF协议验证attack.com域，而DKIM和DMARC协议验证aliyun.com域。因此，该电子邮件可以通过所有三个电子邮件安全协议，并进入Gmail收件箱。此外，没有电子邮件服务会向用户显示有关具有三种协议的不同已验证域的电子邮件的警报。这进一步使这类攻击对普通用户更具欺骗性。
0x05 Root Causes and Mitigation
A.根本原因
如前所述，电子邮件系统的安全性依赖于多个由多方分别实施的保护策略。因此，这些多方之间的不一致可能会造成更多漏洞，并导致严重的欺骗攻击。确定攻击的根本原因如下。
多协议之间的弱链接：由于电子邮件规范的含糊不清，缺乏最佳实践以及MIME标准的复杂性，协议验证过程是身份验证链中的薄弱环节之一。在SMTP通信过程中，协议的多个字段包含发送者的身份信息（即Auth username，MAIL From, From, Sender）。这些字段的不一致为电子邮件欺骗攻击提供了基础。
SPF，DKIM和DMARC均已提出并进行了标准化，以防止从不同方面进行电子邮件欺骗攻击。但是，只有在所有协议都得到很好实施的情况下，电子邮件系统才能防止电子邮件欺骗攻击。在这种基于链的身份验证结构中，任何链接的失败都会使身份验证链无效。
多角色之间的弱链接：在电子邮件系统中，自动确定发件人的身份是一个复杂的过程。它涉及四个重要角色：发送者，接收者，转发者和UI渲染器。标准安全模型的假设是，每个角色都正确开发并实施相关的安全验证机制以提供整体安全性。但是，许多电子邮件服务在所有四个角色中均未实现正确的安全策略。
许多电子邮件服务（例如iCloud，Outlook，Yeah.com）在电子邮件转发阶段并未注意到由未授权转发攻击（A9）引起的安全风险。另外，该规范没有规定电子邮件安全验证中四个角色（即发送者，接收者，转发者和UI渲染器）的任何明确职责。
多服务之间的弱链接：不同的电子邮件服务通常具有不同的配置和实现方式。某些服务（例如Gmail，Yandex.com）禁止发送带有歧义header的电子邮件，但会接收。相反，某些公司（例如Zoho，Yahoo）倾向于允许发送带有不明确header的电子邮件，但在电子邮件接收验证阶段进行非常严格的检查。安全策略之间的差异使攻击者可以将来自具有容忍发送策略的服务中的欺骗电子邮件发送给接收策略宽松的服务。
此外，一些电子邮件提供商在处理带有模糊header的电子邮件时会偏离RFC规范。当MUA处理带有多个From header的邮件时，某些服务（例如Outlook，Mail.ru）会显示第一个header，而其他服务（例如iCloud，yandex （.com）显示最后一个header。此外，不同的供应商都不同程度地支持Unicode字符。一些供应商（例如21cn.com，Coremail）已经意识到由Unicode字符引起的新安全挑战，但是一些供应商（例如163.com，yeah.net）则不知道。特别是，某些（例如zoho.com，EwoMail）甚至还不支持Unicode字符的呈现。
最后，只有少数电子邮件提供商显示可视UI通知，以警告用户欺骗电子邮件，并且只有12个供应商实施发件人不一致检查。特别是，由于缺乏统一的实施标准，实际中的发件人不一致检查非常多样化。缺乏有效和合理的电子邮件安全通知机制也是造成电子邮件欺骗屡禁不止，却从未消除的原因之一。
B.缓解
由于电子邮件欺骗是一个涉及多方的复杂问题，因此需要多方协作来解决相关问题。
更精确的标准：请注意，电子邮件提供商可能无法通过电子邮件协议中含糊不清的定义来提供安全可靠的电子邮件服务。因此，提供更准确的电子邮件协议描述对于消除多方协议的实践中的不一致是必要的。例如，DKIM标准应指定何时应将DKIM签名添加到转发的电子邮件中。对于转发者而言，添加DKIM签名以提高电子邮件的信誉是合理的；但是，他们不应在从未通过DKIM验证的电子邮件中添加DKIM签名。
UI通知：电子邮件UI呈现是影响用户对电子邮件真实性的感知的重要部分。不幸的是，在实验中，大多数电子邮件浏览器端和电子邮件客户端仅显示From header，而没有更多身份验证详细信息。因此，普通用户很难判断电子邮件的真实性。此外，某些视觉攻击（例如A12，A13）无法在协议级别进行防御。一种有效的防御方法是提供用户友好的UI通知，并警告用户其收到的电子邮件可能是电子邮件欺骗。
如上图所示，用户可以根据UI通知直观地识别所接收的电子邮件是否包含恶意行为。著名的电子邮件服务提供商Coremail已采纳了本研究的建议，并在其Webmail和电子邮件客户端上实现了UI通知。此外，本研究还发布了针对Chrome的Chrome扩展程序，名为“ NoSpoofing”（ https://chrome.google.com/webstore/detail/nospoofing/ehidaopjcnapdglbbbjgeoagpophfjnp ）的评估工具。已经在GitHub（https://github.com/mo-xiaoxi/EmailSpoofingTestTool ）上公开发布了测试工具，供电子邮件管理员评估和提高其安全性。配置目标电子邮件系统信息后，该工具可以与目标系统进行交互，并评估目标系统是否容易受到攻击。已经向30个相关的电子邮件供应商详细报告了此工作中发现的7个披露漏洞。本项目一直在与这些实体联系，以帮助他们缓解检测到的威胁，联系结果总结如下。
Alibaba Cloud对攻击很感兴趣，并与本文研究者就规范进行了深入讨论。 RFC 6376建议在电子邮件转发阶段添加DKIM签名以提高电子邮件的可信度。他们现在已经认识到在没有验证的情况下添加DKIM签名的风险，并承诺评估和修复此类问题。他们还建议本文研究者联系相关RFC的作者，以达成一致的解决方案。Gmail已经确认本文的报告，并将在后续更新中解决相关问题。他们联系本文研究者讨论这些安全问题背后的根本原因。iCloud与本文研究者讨论了攻击的详细信息及其潜在后果。特别是，苹果iCloudEmail通过与本项目的合作已经解决了相关的安全问题。Sina认为此问题是高风险漏洞，并在内部评估了相应的保护措施，提供了≈$ 90的奖励。Yandex接受本研究的报告并确认漏洞，同时提供200美元的奖金用于感谢。Yahoo确认了该漏洞，但是声称这不是直接的风险。Coremail感谢本研究的报告，尤其感谢UI攻击的问题。为了解决这些安全问题，采纳了建议并开始实施UI通知，以保护用户免受电子邮件欺骗攻击。QQ Mail和163.com感谢了本研究的工作，并告知将通过反垃圾邮件解决这些安全问题。Outlook和Mail.ru声称严格按照RFC标准运行其电子邮件服务，将这些问题归类为网络钓鱼电子邮件，并承诺将更加关注此类攻击的影响。已与其他相关的电子邮件供应商联系，并期待收到他们的反馈。
0x06 Conclusion
本文探讨了电子邮件生态系统中链式身份验证结构的漏洞。具体而言，在此基于链的结构下，任何部分的错误都可能破坏整个链，即电子邮件的真实性取决于电子邮件认证链中最弱的链接。本文提出了一系列新攻击，可以通过对电子邮件传递过程的系统分析来绕过SPF，DKIM，DMARC和用户界面保护。此外，对30种流行的电子邮件服务和23个电子邮件客户进行了大规模分析。实验结果表明，它们所有人都容易受到新攻击的攻击，其中包括著名的电子邮件服务，例如Gmail和Outlook，许多电子邮件服务尚未实施适当的保护措施。本研究集中于欺骗攻击对整个基于链的电子邮件身份验证过程的影响，分析了这些攻击的根本原因，并将问题报告给了相应的电子邮件服务提供商。 还为电子邮件协议设计者和电子邮件提供商提出了缓解措施，以防御电子邮件欺骗攻击。本文工作致力于帮助电子邮件行业更有效地保护用户免受电子邮件欺骗攻击，并改善电子邮件生态系统的整体安全性。