Weak Links in Authentication Chains: A Large-scale Analysis of Email Sender Spoofing Attacks
介绍
虽然有SPF、DKIM、DMARC三个协议，但由于受协议保护的实体不一致，但欺骗仍然有可能成功。
电子邮件的身份验证涉及四个不同的角色：发件人、收件人、转发者、UI呈现器。
不同的服务之间存在许多不一致之处，攻击者可以利用这些不一致之处绕过安全机制，并像Webmail和电子邮件客户端呈现欺骗性结果。
此文章系统的分析了电子邮件传递过程中身份验证的四个关键阶段：发送身份验证，接收验证，转发验证和UI呈现。 我们发现14种电子邮件欺骗攻击能够绕过SPF，DKIM，DMARC和用户界面保护。 通过组合不同的攻击，欺骗电子邮件可以完全通过所有流行的电子邮件安全协议，并且收件人的MUA上不会显示安全警告。 即使对于具有高级技术背景的人来说，要确定这种电子邮件是否是欺骗邮件仍然是一项挑战。
贡献：
- 通过系统地分析电子邮件身份验证链，总共发现了14种电子邮件欺骗攻击，其中9种（即A3，A6，A7，A8，A9，A10，A11，A13，A14）是新的攻击。 通过组合不同的攻击，可以伪造更逼真的欺骗性电子邮件来渗透Gmail和Outlook等著名的电子邮件服务。
- 对30种流行的电子邮件服务和23个电子邮件客户进行了大规模测量。 发现它们所有人都容易受到某些攻击。
- 为了增强对电子邮件系统的欺骗攻击保护，我们提出了一种UI通知方案，并为电子邮件广告管理员提供了一个电子邮件安全评估工具，以评估和提高其安全性。
成功攻击的目标定义如下
- 接收者的MUA错误地渲染了发件人地址，因为它来自合法域名，而不是攻击者的真实地址
- 收件人的MTA错误地验证了欺骗电子邮件的发件人
- 收件人的MUA不会显示任何用于欺骗电子邮件的安全警报
###
攻击方式
在发送认证阶段的攻击
A1: Auth和Mail From不一致
SMTP协议并不要求两者一致，只能是开发者来确保两者一致。 大多数电子邮件服务进制用户发送与原始身份不一致的邮件，但Zimbra和EwoMail仍含有这种漏洞。
A2:Mail From和From不一致
在发邮件时允许用户修改From字段 许多流行的电子邮件服务（例如Outlook，Sina，QQ邮件）和大多数第三方电子邮件客户端（例如Foxmail，AppleMail）仅显示From字段，而不显示Mail From字段
RCPT TO和To字段不一致
在接收认证阶段的攻击
A3:空Mail From字段
空的Mail From是被允许的，但是From字段填写的是伪造的发件人地址。
如果Mail From为空的话，则要求基于Helo字段完成SPF认证，但现实中Helo字段被滥用，所以验证比较宽松
A4:多个From 字段
攻击者构造多个From字段来绕过安全策略，RFC 5322声明有多个From字段的邮件是被拒绝的，但仍然有一些邮件服务商无法遵循该协。
From: <Oscar@attacker.com>
From: <Alice@a.com>
只有4个邮件服务（即Gmail，Yahoo，Tom和Aol）拒绝具有多个From字段的电子邮件，并且19种邮件服务受此类攻击的影响。 大多数经过测试的电子邮件服务倾向于在网络邮件上显示第一个From字段，而6个电子邮件服务（例如iCloud，Yandex，阿里云）选择显示最后一个From字段。 此外，有7家供应商针对此类攻击制定了具体的安全法规，例如在网络邮件上同时显示两个发件人地址（例如QQ邮件，Coremail）或将此类电子邮件放入垃圾邮件文件夹（例如Outlook，rambler.ru）
A5:多个发件人邮件地址
From 中列出多个发件人，Sender字段中需要标识实际发件人
但是
A6:解析不一致攻击
Mail From和 From字段是有复杂语法格式的富文本，难以正确解析并显示出来。
- 在邮箱地址前，允许包含一个route portion,例如
<@a.com, @b.com:admin@c.com> - 可以使用邮箱地址列表，并且其中的元素可以为空
<a@a.com>, ,<b@b.com> - 可以使用括号作为注释
- 有一个可选的显示名称，指示发件人的名称，是展示给收件人显示的名称
截断字符是终止字符串分析的一系列字符
\x00可以终止C语言程序解析字符串的过程- 不可见的Unicode字符串也可以终止解析(例如
\uff00-\uffff,\x81-\xff) - 某些语义字符，例如
[ ] { } \t \r \n
A7: 基于编码的攻击
以各种字符集编码:=?charset?encoding?encoded-text?=.,
encoding字段指定编码算法,b代表base64，q代表带引号的可打印编码。
encode-text指定编码的文本，攻击者可以用这些编码的地址来逃避电子邮件安全协议的验证。
例如From: =?utf-8?b?QWxpY2VAYS5jb20=?=,大多数电子邮件服务在验证DMARC协议之前不会对地址进行解码，所以DMARC解析的结果为None。
此外，该技术可以与截断的字符串结合使用。
A8:子域攻击
攻击者从知名的电子邮件服务的子域（没有MX记录）发送欺骗性电子邮件，SPF记录为None。
RFC 7208不建议使用通配符来发布SPF记录。
RFC 2821提到当域没有MX记录时，SMTP会假定只有A记录即可，而大多数网站都配备了具有通配符的DNS A记录。
在邮件转发验证中的攻击
A9:未经授权的转发攻击
A10:DKIM签名欺诈攻击
邮件转发服务对所有转发的电子邮件添加DKIM签名
A11:ARC问题
ARC(Authenticated Received Chain) 是一种新提出的协议，它提供了一条信任链，在电子邮件转发过程中将SPF，DKIM和DMARC的验证结果添加到一个有序集合中。
在实验中只有三个电子邮件服务（即Gmail，Office 365和Zoho）部署了ARC协议。
但是，研究发现Office 365和Zoho都在ARC协议实现方面存在安全问题。 ARC无法抵御上面讨论的除了A10以外的大多数攻击。
在UI呈现上的攻击
如果UI上呈现的发件人并不是真实的发件人，那么也可以认为这是一次成功的攻击。
A12:IDN重构攻击
internationalized domain names (IDN)
Punycode是一种将不能以ASCII格式显示的单词转换为Unicode编码的方法。值得注意的是，Unicode字符在屏幕上的外观相似，而原始地址不同。
如果域标签中包含多个语言的字符，则不应该呈现IDN。
A13: 影响UI呈现的攻击
有些字符无法呈现或者被截断。
例如U+0000-U+001F或者@ : ; "
例如admin@gm@ail.com显示为admin@gmail.com
A14:控制字符串显示顺序的攻击
U+202E字符串告诉计算机从右向左的顺序显示本文
攻击者可以使用\u202emoc.a@\u202dalice,显示为Alice@a.com