最近导师丢给了我一篇被Usenix Security 2021收录的的关于邮箱安全的论文《Weak Links in Authentication Chains: A Large-scale
Analysis of Email Sender Spoofing Attacks》，这里总结分析一下
序言
这篇文章主要针对的是电子邮箱的身份验证链上的发件人欺骗进行研究，提出了14种能绕过单个SPF、DKIM、DMARC协议或UI界面上的发件人不一致检测的攻击方法，以及将这些方法组合起来绕过以上这些防御措施的组合。然后对30个邮件服务和23个邮件客户端进行了测试，并将得到的结果提交给了这些服务提供商
邮件的传输与验证
在讨论发件人欺骗前，我们需要知道一个电子邮件是如何在两方中传输的。
如上图所示,一封邮件的发送首先通过SMTP和HTTP协议由发送者的邮件用户代理(MUA)发送到邮件传输代理(MTA),接着会通过SMTP协议从发送者的MTA传输到接收者的MTA上，最后通过POP3、IMAP、HTTP协议传输到接收者的MUA上。这便是一个最基础的传输过程
但有时候使用许多电子邮件服务时，我们会希望能够集中到一个服务中去查看而不是逐个查看每个邮箱服务，此时就需要用到邮箱转发。邮箱转发相对基础的邮件传输过程多了一个邮箱转发服务，发送者发送邮件时的接收者地址指向的是邮件转发服务，继而发送者的MTA会将通过SMTP协议将邮件发送给邮箱转发服务。邮箱转发根据服务上的转发条目，修改接收者的地址，再将邮件发送给接收者的MTA，达到转发的目的
在邮件传输的过程中，发送者的信息保存在以下四个字段中：Auth username:在客户端登录验证时使用的用户名MAIL From:电子信封上的发件人，在投递过程（发送给发送者MTA时）中进行验证的身份From：邮件正文的发件人，在邮件客户端会显示给用户Sender:在From中有多个地址时提供真正的发件人
发件人欺骗攻击的原因就是由于这些字段允许不一致所导致的
而整一个邮件传输过程中，在以下四处进行了身份验证
邮件发送认证
在MUA通过SMTP协议发送邮件时，需要发送者输入用户名和密码进行身份验证。而发送方的MTA收到邮件时，不仅会验证用户的身份，还会去确认Auth username与MAIL From字段是否相等
邮件接收验证
接收方的MTA接收到邮件后，会通过SPF、DKIM和DMARC协议对邮件进行验证，这几个协议的详细在后文描述
邮件转发验证
当邮件转发方要转发邮件时，会验证发送方的地址。若启用的DKIM签名，则DKIM的验证状态是pass时，才会添加新的DKIM签名。若部署了ARC协议，ARC验证链也会进行验证
邮件UI渲染
这里指的是各个邮箱服务通过UI渲染呈现给用户的信息，但不少邮件客户端并没有将真实性检查结果显示给用户，仅仅只是显示了电子信封上的信息。
而攻击者还可以通过不同的编码或是特殊字符使得发送人信息在UI界面上显示起来并没有问题，导致用户被伪装的攻击者所欺骗。UI渲染是身份验证的最后一关，也是至关重要的一关，但却很容易被忽略
邮件保护措施
在电子邮件中，最基础的协议就是SMTP协议，其全称是Simple Mail Transfer Protocol，即简单邮件传输协议。与字面一致，该协议十分简单，目的也仅仅只是为了使邮件能有规则地传输。在其设计中发件人的邮箱地址是可以由发件方随意声明的，这就导致了极大的安全问题。为了保障邮件传输的安全，出现了以下几种防御措施
SPF
Sender Policy Framework，即发件人策略框架
当邮件服务器接收到一封邮件时，会获得发件主机IPx.x.x.x和发件人邮箱`xxx@xx.com。接着服务器会去查询邮箱xx.com的SPF记录，若该域的SPF记录允许IPx.x.x.x`主机发送邮件，则认为该邮件合法，否则处理为非法邮件
SPF记录本质上是DNS记录v=spf1 a mx ip4:x.x.x.x -all，这是一个常见的SPF记录v=spf1代表使用的时SPF 1版本a mx ip4:x.x.x.x为主体内容。ip4指IPv4地址或地址段，当没有给出前缀长度时，默认为/32;ip6指IPv6地址或地址段，默认前缀长度是/128;a和mx指的都是相应域名对应的A/MX记录中包含的IP地址段，当没有指出域名时，则使用当年记录的域名;include的格式为include:<domain>，代表引入<domain>下的SPF记录，若不存在记录则会导致PermError;exists的格式为exists:<domain>，当<domain>的A查询存在返回时，则不论发件人IP如何，此SPF记录生效;ptr格式为ptr或者ptr:<domain>，由于ptr机制会带来大量的DNS查询开销，因此官方并不推荐使用-all代表查询到后的结果。+表示通过(PASS)，-表示拒绝(FAIL)，~表示软拒绝(Soft Fail)，?表示中立(Neutral)。除了以上这四种结果外，还有其它三种结果，其含义与标准处理方式是1
2
3
4
5
6
7Pass 发件IP是合法的 接受来信
Fail 发件IP是非法的 退信
Soft Fail 发件IP非法，但是不采取强硬措施 接受来信，但是做标记
Neutral SPF 记录中没有关于发件IP是否合法的信息 接受来信
None 服务器没有设定SPF记录 接受来信
PermError 发生了严重错误（例如SPF记录语法错误） 没有规定
TempError 发生了临时错误（例如DNS查询失败） 接受或拒绝
SPF记录中还允许两种可选的修饰符，一种修饰符只能出现一次。redirect，格式为redirect=<domain>，将用<domain>的SPF记录替换当前记录。exp，格式为exp=<domain>，但邮件被拒绝时可以给出一个消息，至于消息的内容取决于<domain>的TXT记录，具体细节不太清楚
DKIM
DomainKeys Identified Mail，即域名密钥识别邮件
在发送邮件时，发件方的MTA在确认发送人的身份后，用私钥对邮件进行签名并将DKIM-Signature添加到电子邮件的标头中。接收方的MTA则通过DNS查询获得发送方域名下的公钥，使用该公钥验证签名，检测邮件是否被篡改
1 | v=1; a=rsa-sha256; d=example.com; s=sl10527； c=relaxed/relaxed； q=dns/txt; t=1117574938； x=1118006938； h=from:to:subject:date; bh=pPl7／locF0uYQkxg4me09HwV+PIcXkeWmQAZSqEt7xM=;b=14m8NwVZFQxlWxDi7f4dtDsaf0u03dmuByy4XshoTRTyVuLCtLXF+UzTY6+yb2O0WailYOHb41SkcpLZfpLhJJCeYIoBhkvnhqU5Q+B7GnNpH5wIKCcIP0X0LDmlKRN4a19N6Kwl0x5PqLYU+1421YEwyvRZTxZxCwva／WmSRQ= |
以上是一个基本的DKIM-Signaturev为DKIM版本;a为签名算法，可选rsa-sha1;d为发送方的域名;s为选择器，使得同一域名有多个公钥，通过选择器选择公钥使用;c为标准化方法，第一个为邮件头的，第二个是内容的。simple标准不允许修改邮件的每一字节，relaxed标准允许少量修改一些空格;q为默认的查询方式;t为时间戳;x为过期时间;h为表示对头部的哪些字段进行签名;bh为正文哈希;b为标头的签名，将h字段的值取出，外加DKIM-Signature（除了b字段）进行hash，最后用a中的算法进行签名
DMARC
Domain-based Message Authentication, Reporting and Conformance，翻译不来，反正是一种邮件验证及报告协议
该协议至少需要启用DKIM和SPF协议其中一个协议才能够使用，它将From中的身份信息与SPF或DKIM的认证标识符相关联。当MTA接收到一封邮件时，查询DNS获取其域的DMARC记录，若无则忽略校验。然后校验SPF或DKIM，再通过DMARC上的策略对结果进行处理，在一段时间后将时间段内的结果集成报告发送给已设置的邮箱
v=DMARC1; p=none; ri=3600; rua=mailto:5b06a240321f1@ag.dmarcly.com; ruf=mailto:5b06a240321f1@fo.dmarcly.com; sp=none; adkim=s; aspf=s; fo=0:1:d:s;
以上是一个典型的DMARC记录v为DMARC版本;p为用于告知接收方检测到邮件存在伪造时，应进行什么处理：none不做任何处理、quarantine为将邮件标记为垃圾邮件、reject为拒绝该邮件;ri是以秒为单位的报告发送间隔;rua为用于接收方检测后，将一段时间的汇总报告发送到哪个邮箱地址;ruf为用于检测到伪造邮件时，收件方须将该伪造信息的报告发送到哪个邮箱地址;sp是子域名策略，若无设置则将p的策略应用于子域名;adkim制定DKIM的对齐策略，r为宽松验证，s为严格验证，默认为r;aspf制定SPF的对齐策略，同adkim;fo是故障报告选项，以冒号分隔的列表，如果没有指定ruf，那么该标签的内容将被忽略。0：如果所有身份验证机制都不能产生pass结果，那么生成一份DMARC故障报告、1：如果任一身份验证机制产生pass以外的结果，那么生成一份DMARC故障报告、d：如果消息的签名验证失败，那么生成一份DKIM故障报告、s：如果消息的SPF验证失败，那么生成一份SPF故障报告
ARC
Authenticated Received Chain，即已认证接收链，在2019年才成为RFC上的协议
在DMARC介绍中也提到了，DMARC允许设置宽松或严格验证。但当设置为严格验证时，由于转发会修改邮件，比如当添加主题内容此时就会导致DKIM签名失效，又比如转发方没修改来源地址，又或是与邮件列表域对齐而不是邮件作者的域对其，最终就会导致验证不通过
ARC的目的就是为了解决这样的一个问题，即使转发后SPF和DKIM验证失败，接收服务也可以选择相信ARC链。当ARC链中表明原始邮件通过了SPF和DKIM检测，并且仅由接收方信任的转发方对其进行了修改，则接收该邮件。只有当接收者信任ARC签名方时，验证ARC链才有意义，一定程度上防止了ARC链的伪造
1 | ARC-Seal: |
以上是一个常见的ARC Set。ARC Set分为三个部分，ARC-Authentication-Results(AAR)、ARC-Message-Signature(AMS)和ARC-Seal(AS)
AAR用于记录在转发器上所进行的DMARC验证的结果，以及在先前每一组ARC Set的验证结果;AMS用于保留原始信件的header和DKIM-Signature，以及新增或是更改的header;AS会对已记录的ARC Set和新添加的AAR和AMS进行签名，作为最新一次的检验
在ARC Set可以看到，三个header中i都是1，这里并非是版本而是说明这是第几次ARC验证，因为是第一次转发所以都是1。AMS和DKIM-Signature基本相同，AS也类似但只签名ARC Set因此没有h和bh。在AS中的cv代表该链此次的验证结果，若cv的值为fail，则后续的转发器不会对邮件在进行验证，该链不被信任。这里cv是none是由于这是链头因此没有做其它的验证
1 | ARC-Seal: |
这是三次ARC验证后的ARC Set，可以看到第二、三次对比第一次，spf、dkim和dmarc都是fail，但cv的值依旧是pass。这是因为AAR中的arc的值是pass，我们可以看到详细的验证内容，对于二、三次AEC验证，第一、二次的AS和AMS校验都pass。这说明第二、三次校验过程中，并没有被篡改，因此cv是pass
SIC
Sender Inconsistency Checks，即发件人不一致检查
SIC并不是一个标准，因为无论是转发还是订阅，都有可能使得发件人不同，并不能因发件人不同而直接丢弃邮件。虽然各个邮件服务有各自的实现方式，但都是对发件人的一致性进行检查，在检查出不一致时在UI界面上提醒用户
攻击模型
发件人身份验证绕过可能发生在四个阶段：发送认证、接收认证、转发验证和UI渲染。在论文中，将邮件攻击模型分为以下三种
共享MTA攻击
由图中的a攻击可以看到，共享MTA攻击是攻击者Oscar拥有一个`Oscar@a.com账号，通过修改Mail From/From/Auth username header伪装成为Alice@a.com，从a.com的MTA发送欺骗电子邮件。通过a.com的MTA发送的IP自然在a.com的SPF范围内，a.com还可能会为Oscar的邮件自动进行DKIM签名，从而绕过SPF/DKIM/DMARC。同时由于发件人的MTA IP的信用是判断是否垃圾邮件的重要因素，而此例中a.com是一个信用较好的MTA，因此不会被视为垃圾邮件，最终成功伪装为Alice@a.com`进入到Bob的邮箱中
直接MTA攻击
由图中的b攻击可以看到，Oscar通过自己的电子邮件服务器直接发送欺骗电子邮件。在发送方和接收方的MTA间没有任何验证机制，因此Oscar可以设置任意Mail From和From header伪装为`Alice@a.com`。这种攻击优势在于不会受到发件方MTA的发送检查，但接收方可能会不信任Oscar的电子邮件服务器
转发MTA攻击
由图中的c攻击可以看到，Oscar将欺骗邮件发送到`Oscar@a.com，同时Oscar在该服务器上为Oscar@a.com配置了转发服务，自动将邮件转发给了Bob@b.com。此攻击由三个优势，一是于共享MTA攻击一样都为同一域上的MTA，二是可以绕过发件方MTA的发送检查（比如Mail From和From header`不一致），三是转发服务还可以为转发的电子邮件提供更高的安全性认证（比如添加不该的DKIM签名）
实验设计
实验目标
22个流行的电子邮件服务，其用户总数超过10亿，选择其能够代表大多个人人用户所面临的邮箱安全问题
5个流行的企业电子邮箱服务，以测试对企业级用户的威胁程度
对于托管电子邮件系统，构建\部署和维护3个著名的电子邮件系统（即Zimbra，EwoMail，Roundcube）进行测试
针对不同桌面和移动操作系统中23个广泛使用的电子邮件客户端的攻击，以评估对UI呈现的影响
分析方法
首先系统地分析电子邮件标准规范。在语法方面提取ABNF规则，重点关注与身份验证相关的header（如Mail From/From/Helo/Sender）。在语义方面关注RFC中每个阶段的电子邮件身份验证
其次收集合法的电子邮件样本，并根据ABNF语法生成带有认证相关header的样本。同时要注意通常的邮件服务会拒绝接收header高度变形的电子邮件，因此需要对header的值进行限制。比如domain的值限制为几个常用的电子邮件域名
再者利用协议的模糊化引入一些常见的绕过方法，比如header重复、插入空格、插入Unicode字符、header编码和大小写变化
然后再使用生成的样本在检验的四个阶段中测试目标电子邮件服务
最后分析总结成功攻击的方法
成功标准
符合以下标准都认为是攻击成功
在邮件发送验证阶段，攻击者可以任意修改标识符（如Auth username/MAIL From/From）
在邮件接收验证阶段，不论欺骗的域名是否部署了严格的SPF/DKIM/DMARC策略，接收方的MTA依旧给出了none/pass的验证结果。是否通过验证可以通过查看电子邮件是否已进入收件箱来判断。若邮件被直接放入垃圾箱，则认为攻击失败，因为此时MTA已检测到是欺骗邮件。为避免偶然与意外，每次攻击都将重复三次且都起效才被视为攻击成功
在邮件转发验证阶段，转发方会为转发邮件提供更高信任度，即其它邮件服务会因转发方的信用度选择相信该邮件。若攻击者无需任何身份验证就可以将转发的电子邮件自由配置到任意账户，则攻击也被认为是成功的
在邮件UI呈现阶段，现实的电子邮件地址与真实电子邮件地址不一致。在这一阶段，由于目的是检查UI渲染的结果而不是绕过垃圾邮件检测机制，因此使用IMAP的APPEND命令直接将邮件放入邮箱中
测量偏差最小化
首先，避免被检测为垃圾邮件，使用合法且不敏感的内容，使其不被视为垃圾邮件
其次，所有欺骗邮件都从15个不同地区的IP地址发送，期间间隔10分钟。还为攻击方的域名和IP地址部署MX/TXT/PTR记录
最后，为了测试接收方的MTA是如何处理带有SPF/DMARC验证结果为fail的邮件，我们测试了目标的30个电子邮件服务，发现其中由23个拒绝带有SPF/DMARC验证结果为fail的邮件，其余的则记为垃圾邮件
发件人欺骗攻击
攻击邮件发送认证
邮件发送认证是确认邮件身份的重要步骤。对邮件发送认证的攻击会滥用知名邮箱服务的IP信誉，甚至能够绕过SPF/DKIM/DMARC验证。这些攻击主要用于共享MTA攻击模型
在邮件发送阶段，有三个发送人标识符：Auth username、Mail From、From。因此只要能在发送阶段能够任意地控制这三个标识符，攻击就被认为是成功的
头字段Auth username和Mail From的不一致(A1)
如上图所示，攻击者在发送验证阶段发送Auth username和Mail From不一致的欺骗电子邮件，以伪装成当前域下的任意用户。而由于SMTP协议并没有确认Auth username和Mail From header的一致性的功能，因此对该攻击的防御需要开发人员额外去实现
在实验中大多邮件服务都注意到了这个问题，且禁止用户发送与原始身份不一致的邮件。但在开源的邮件服务系统比如Zimbra、EwoMail，在默认配置下容易受到该攻击，邮箱开发者应更新安全配置以防御该攻击
头字段Mail From和From的不一致(A2)
如上图所示，攻击者可以发送Mail From和From不一致的欺骗邮件伪装成其他用户。虽然邮箱服务允许某些用户使用别名发送Mail From与From不同的邮件，但不应允许修改为任意值（如admin），应只允许在合法的范围内设置别名
对于许多电子邮件服务和第三方电子邮件客户端，仅显示From不显示Mail From，用户无法判断是否是一封欺骗邮件
而头字段PCPT To和To也存在类似的不一致，在进行邮件转发或是密件抄送时都会出现这样的不一致。这样的灵活性扩展了发件人欺骗的攻击面，引入了新的安全风险。比如，即使To字段非受害者的地址，但攻击者仍然能够将邮件发送给受害者。在这种情况下，攻击者可以使用该方法获得通常无法获得的DKIM签名（比如在转发时由于验证不足，给欺骗邮件添加了DKIM签名）。单独使用时也许起不了多少效果，但与其它技术结合，可以达到出色的攻击效果
实验中有14家电子邮件服务容易受到此类攻击，此外还有某些电子邮件服务，会拒绝Mail From和From的不一致的邮件，但仍可以与A4、A5攻击结合来绕过这些防御。例如发送Mail From为<Oscar@a.com>和From为<Alice@a.com, Oscar@a.com>的欺骗邮件可以绕过Yahoo的验证
攻击邮件接收验证
SPF、DKIM和DMARC是常用的抵抗邮件欺骗攻击的机制，这种攻击能够见于提及的所有攻击模型。攻击是否成功依据接收者的MTA是否给出了错误的none/pass验证结果
空Mail From攻击(A3)
在RFC 5321 3.6.3中提到，当邮件服务器受到转发邮件但因目标地址不正确或邮件由于其它原因无法转发到，此时需要构造一个“无法投递邮件”的通知消息发送给发件人。但这样的错误通知回传可能会因转发链上某个回传失败又产生错误通知回传。为了减少这样的流量浪费，标准中要求回传的Mail From的值必须为空，不再产生更多的错误通知回传。而这样一个特性，能够被利用来构造发送欺骗邮件
如上图所示，将Mail From置为空，同时将From置为目标伪装邮箱。在SPF协议中规定了，当Mail From为空时，应从Helo获取SPF的验证域。而由于Helo字段的滥用，一些邮箱服务违反标准并采用了更加宽松的验证措施。当接收方的MTA处理这些电子邮件时，由于无法基于Helo完成SPF的验证，因此直接返回none。这就使得攻击者能够将SPF的结果从fail转变为none
实验中有13家电子邮件服务会受到该攻击的影响，而有17家解决了此类问题，其中有5个将Mail From为空的邮件视为垃圾邮件
多个From字段(A4)
From字段存在多种变形，例如在From前后添加空格、大小写转换或插入不可视字符
如上图所示，攻击者可以构造多个From来绕过安全策略。RFC 5322中要求通常应拒绝具有多个From字段的电子邮件，但仍有邮件服务不遵循协议，接受带有From的邮件。从上图中可以看到，当存在多个From字段时，UI界面会显示最后的一个From字段，但DMARC验证会根据第一个From字段进行检验。这就导致了攻击者能够通过第一个From字段控制DMARC的检验，并用最后一个From字段欺骗受害者
实验中仅有四个邮件服务拒绝多个From字段的邮件，有6个服务选择显示最后一个From，7家供应商已针对此类攻击制定了特定的安全法规，例如同时显示两个发件人地址或置为垃圾邮件
多邮件地址(A5)
多邮件地址也是一种绕过协议验证的方式。多邮件地址最初在RFC 2822中提出，而知道RFC 5332仍被允许。多邮件地址是为了适应以下这种情况:由多个作者共同编写的邮件。这时Sender字段为实际发件人
如上图所示，攻击者可以使用多个电子邮件地址绕过DMARC验证，DMARC会根据后一个邮件地址进行检验。还可以对这些地址进行基于规则的更改，例如[Alice@ a.com],\< Oscar@attack.com>
实验中15个邮件服务接受此类邮件，4个服务直接拒绝，5个服务置为垃圾邮件，6个服务显示所有地址
解析不一致攻击(A6)
Mail From和From是富文本字段且具有非常复杂的语法格式，如何正确地解析显示名称与真实地址是避免此攻击的关键，这些不一致使得攻击者能够绕过验证并欺骗目标邮箱客户端
上图显示了Mail From中的三种解析不一致，可以看到其目的都是让SPF协议认为尾部的attack.com是该发件人的验证域
在RFC 2822 4.4中提到了一种过时但因兼容保留下来的地址形式，这种邮箱地址形式有着三个不同之处：一、当邮箱地址包含在<>中时，:前面的部分会被解析为路由，各个路由被,分隔，以@开头，而:后面的部分会被解析为真实发件人地址；二、用于分隔本地部分和域的.允许使用注释代替其作用；三、允许邮箱和地址列表由“空”成员，也就是允许连续的两个或多个逗号
利用这种过时的地址，在上图中可以看到，在第一个的Mail From中，在解析后会认为`Alice@attack.com是发件人地址，于是对attack.com域进行SPF验证；第二个使用了null成员，在解析后会认为a@attack.com是发件人地址，对其进行SPF验证（这个说实话不太明白）；第三个使用了注释代替点分隔本地部分与域名，解析后会认为attack.com`是SPF的验证域
上图显示了在From中，可以利用一些特殊字符对字符串进行截断，使得只显示字符串被截断的前半部分。比如用NULL \x00这种在C中的字符串种植字符，或是不可见的Unicode字符\uff00-\uffff \x81-\xff，再或是语义字符，例如[ ] { } \t \r \n ;。使用这些字符会使得UI显示不一致，但在解析时，仍然会以整个字符串末尾的域进行DMARC验证，这样就绕过了DMARC
实现测试得到由13个邮件服务在UI显示存在这样的问题
基于编码的攻击(A7)
RFC 2047中描述了一种MIME（多用途电子邮件扩展）的非ASCII文本的消息头扩展，其形式是=?charset?encoding?encoded-text?=，charset是未编码文本的字符集；encoding是编码，b是base64，q是可见编码；encoded-text是被编码的内容
上图中可以看到，在进行DMARC验证时，不会解码=?utf-8?b?QWxpY2VAYS5jb20=?=，直接以该字符串为域进行DMARC验证，结果自然是none成功绕过，而UI上会解析显示为`Alice@a.com但结合截断字符的攻击没看懂，b64(Alice@a.com>b64(\uffff)@attack.com这条字符串用\uffff进行了截断，而DMARC并不会解析为截断，结果就是认为attack.com为验证域。但UI界面显示Alice@a.com的原因没看懂，b64是编码的话就不应显示Alice@a.com，解码的话应该是解Alice@a.com`的base64编码值才对，以后实现测试看看
在实验测试得到由7个邮件服务受到该问题影响
子域名攻击(A8)
攻击者可以将邮件的发送域设置为知名邮件服务中没有MX记录的子域，无MX记录的子域没有相应的SPF记录，因此验证结果是none。就算父域配置了严格的电子邮件策略，依旧能够通过这种方式攻击。而许多公司通过子域发送业务订阅邮件，使得用户倾向于信任此类邮件
除此之外，RFC 7208中并不鼓励使用通配符记录来发布SPF记录（也就是不能直接*.xxx.xxx，因此少有管理员会配置通配符SPF记录。虽然收件方的MTA通常可以拒绝来自没有MX记录的域的电子邮件，但RFC 2821提到当域没有MX记录时，SMTP会认为有A记录已足够，这使得有A记录的域名都会被视为有效的电子邮件域。而许多网站都会使用通配符配置DNS A记录，这使得这种攻击难以被检测
在实验中发现，有13个邮件服务容易被攻击，而只有一个邮件服务为SPF记录配置了通配符DNS条目。默认情况下，为组织域设置的DMARC策略应适用于任何子域，除非已为特定子域配置了DMARC记录。但实验结果表明，即使接收方的MTA进行了DMARC验证，攻击仍然有效
攻击邮件转发验证
当共享MTA攻击无法成功时，攻击者可以尝试使用转发服务发送欺骗邮件。而通过转发服务邮件会得到更高级的安全认证
未授权转发攻击(A9)
若邮件服务在不进行任何身份验证的情况下，将转发的电子邮件任意配置到任何账户，那么攻击者可以在邮件转发服务上创建一个合法账号，通过该账号转发来自攻击者服务器的欺骗邮件。由于该转发服务是主流的邮件服务，因此接收方的MTA通常会接受该邮件，同时通过转发服务能够绕过SPF和DMAARC验证
从上图可以看到，从攻击者服务器发送的邮件Mail From为空，转发后Mail From被改为`Oscar@a.com，由于是从a.com域发送的，因此通过了SPF和DMARC验证
这里其实不太明白为什么最初的RCPT TO并不是Oscar.@a.com，但却能发送到这个账户或者是a.com的转发服务器上。可能是这个邮件是直接被投递到转发服务器上，同时该服务器上配置了From为Alice@a.com的邮件通过Oscar@a.com转发给Bob@b.com`的条目
实验中有12个邮箱服务有该问题，7个邮箱服务不提供转发
DKIM签名欺骗攻击(A10)
由于RFC 6376和RFC 6377均建议转发服务将其签名添加到转发的电子邮件中，因此许多转发服务都会为转发的邮件添加DKIM签名。攻击者能够利用这点，将没有DKIM签名的邮件发送给转发服务，获得DKIM签名以提高可信任度。实际上对于转发的邮件，转发服务器应检测是否有DKIM签名或之前是否未通DKIM验证，再选择是否添加DKIM签名
上图可以看到对该攻击的利用，攻击者在a.com的邮箱服务下创建账号`Oscar@a.com，并配置将接收的电子邮件发送给另一个攻击者的邮箱账号Oscar@c.com。接着发送From为Alice@a.com和To为Bob@b.com的邮件给Oscar@a.com再转发到Oscar@c.com。通过这一过程，攻击者就获得了a.com域对其邮件的DKIM签名，然后将Mail From置空，发送给Bob。由于没有将Mail From`计入DKIM签名的范围，因此修改也不会使DKIM验证失败。最终这封邮件通过接收方MTA的DKIM验证进入了Bob的邮箱
ARC问题(A11)
ARC协议仅有Gmail、Office 365和Zoho对其进行了部署，实验发现Office 365和Zoho在ARC协议上都存在问题，且除了攻击A10外，无法防御其它攻击
对于Zoho，如果邮件未通过发件人不一致检查，它将为用户显示警报。但Zoho的ARC实施存在错误，当通过Gmail自动将欺骗性电子邮件转发到Zoho邮箱时，Zoho添加的ARC-Authentication-Results(AAR)显示了错误的DMARC验证结果pass,而且这种错误的ARC实现还有可能绕过发送方不一致检查，不对用户显示警报
Office 365在ARC的实现中也有错误。它在AAR中传递了错误的SPF、DKIM和DMARC验证结果。这将破坏ARC信任链，引入更多的安全风险
攻击邮件UI界面
邮件的发件人显示是抵御发件人欺骗的最后一道防线，许多邮件服务都会对发件人的一致性进行检测并在UI界面上警告用户。该部分不讨论如何绕过邮件安全协议，只针对绕过发件人一致性检测并显示出来的地址能欺骗用户的方法进行讨论
IDN同形异义词攻击(A12)
IDN全称Internationalized Domain Names，即国际化域名。其允许使用Punycode这种特殊编码，这种编码能将无法用ASCII显示的单词转为Unicode编码，该编码出现的目的是为了使DNS服务器支持中文域名，中文域名在解析时需要转化为编码
如上图所示，可以看到真实的地址是admin@xn–aypal-uye.com，但由于编码后会显示为`admin@paypal.com，若不进行警告，用户很容易被欺骗
如今的浏览器针对IDN同形异义词攻击实施了一些防御措施，例如当域标签包含多种语言的字符时不解析IDN，但电子邮件系统中几乎没有类似的防御措施。实现中有10中电子邮件服务支持IDN，且仅有Coremail通过在Unicode`字符前后添加空格使用户可以区分
UI显示缺失攻击(A13)
在UI显示时，有些字符能够截断邮件地址，还有些不可见字符U+0000-U+001F,U+FF00-U+FFFF以及语义字符@ : ; "不予显示。例如admin@gm@ail.com会显示为`admin@gmail.com`
实验中有12种邮件服务会受到这种攻击，其它服务拒绝或放入垃圾箱种
RTRO(Right-to-left Overrid)攻击(A14)
有一些字符可以控制字符串的显示顺序，RTRO字符就是其中一种，U+202E可以控制字符串从右向左显示，其用于阿拉伯语或希伯来语文本。而攻击者可以构造字符串\u202emoc.a@\u202dalice，其显示为`Alice@a.com`
由于带有RTL字符的邮件可能会被认为是垃圾邮件，可以使用有效的payload（如UTF-8编码）。实验中有11个邮件服务容易受到攻击，10个无法正确显示，其它则选择拒绝该类邮件
组合攻击
根据电子邮件传递的四个认证阶段，攻击被分为四类，但这些攻击都有局限性。比如A2、A3能够欺骗接收方，但无法绕过所有欺骗保护。而单独的A3能绕过SPF，但绕过不了DMARC。单独的攻击在许多邮件服务上都很难起效，因此需要将这些攻击进行结合形成组合攻击，绕过三种邮件安全协议以及UI界面保护验证
相同攻击模型下的组合攻击
上图显示了共享MTA攻击模型下的攻击示例，Yahoo会对Mail From和From的一致性进行检测，此时利用A4设置两个From字段，Yahoo取第一个From字段与Mail From，记过成功通过。而利用A2使第二个From字段与Mail From字段不同伪装成`Admin@paypal.com。当iCloud接收到邮件时，会使用第一个From字段进行DMARC验证，结果自然成功通过。但在UI界面显示的却是第二个From`，使得该组合攻击成功
不同攻击模型下的组合攻击
邮件系统是一个具有多方信任链的复制生态系统，依赖于多方部署和实施的安全措施。在不同的攻击模型下，各个参与方可能具有不同的漏洞。比如，若发送方MTA在发送时对身份进行了严格的检查，则难以通过共享MTA进行攻击，但若在其它阶段无法获得正确且完整的安全防御方案，就可能使攻击者利用其它两种模型绕过
如上图所示，通过组合直接和转发MTA攻击模型成功实现了欺骗。攻击者首先构造一个Mail From为空，To为`victim@gmail.com的邮件，通过在aliyun的MTA上已注册的账号Oscar@aliyun.com转发给另一个自己的邮箱Oscar@attack.com。在转发的过程中，Aliyun的MTA会为邮件添加DKIM签名。接着攻击者再将收到的邮件直接发送给受害者的邮箱。对于此邮件，SPF验证的是Mail From中的域，而DKIM和DMARC验证则是对aliyun.com域进行验证。最终成功进入受害者的邮箱并显示为admin@aliyun.com`
原因分析
首先是SMTP可以通过多个字段包含发送者的身份信息，使得攻击者可以利用这些字段的不一致构造邮件进行攻击
其次是由于虽然有SPF、DKIM和DMARC这类的安全协议，但需要所有协议的验证无误才能保证攻击被拒绝。而在实际中由于协议间的关联性并不是很强，导致攻击者可以以某个协议为突破口，通过邮件的身份验证链的验证
再者是身份验证链上的四个角色很多时候会忽略其中一个或多个角色的安全风险，而也没有规范对四个角色进行明确的职责规定
最后是各个邮箱服务商对邮箱服务的不同实现方式，以及对安全风险的重视程度，导致就算一家服务商安全等级较高也会由于其它服务商的疏忽被攻击
缓解方法
对各个协议进行更加精准的定义，比如对DKIM何时将签名添加到转发邮件中进行标准规范
还可以通过各个邮件厂商在UI界面上显示那些有可能存在风险的字段以提醒用户