【年度报告连载五】电子邮件安全拓展协议现状

作为互联网上广泛部署、应用的基础通信服务，电子邮件在个人和企业通信中扮演着举足轻重的角色。与此同时，基于电子邮件伪造的钓鱼欺诈、勒索软件和病毒木马等已成为当前威胁互联网安全的常见攻击之一，并造成了巨大的财产损失。

为了防止电子邮件伪造攻击，现代电子邮件体系基于各类安全拓展措施构建了一个依赖多方安全信任链的复杂生态系统。一方面，电子邮件自身缺少安全验证措施，需依赖相关安全拓展协议提供安全防护。目前，常见的方式是通过SPF、DKIM和DMARC这3个安全拓展协议从不同维度共同提供邮件防伪保护，因为单独协议并不能满足电子邮件的安全需求。另一方面，现实生活中存在多样化的电子邮件服务，包括但不限于Gmail、Outlook、Coremail、QQ Mail、Ali Mail、Yahoo Mail等，缺乏统一的安全策略实施标准。这种多方对安全机制的理解和实施的不一致，将导致大量的邮件安全问题，并将长期困扰邮件安全生态。

因此，本文分别基于SecRank Top 100万和Alexa Top 100万域名数据对其电子邮件安全拓展协议的部署进行了大规模测量，力图刻画电子邮件伪造问题防御现状，以揭示邮件伪造攻击屡禁不止的真正原因。

（注：本文数据均为截至2020年7月的数据）

1．国内外邮件协议部署存在差异

基于SecRank排名和Alexa域名排名中的Top 100万域名，分别进行大规模的邮件安全协议部署情况测量，并通过SPF和DMARC安全拓展协议比较其部署情况差异。

（1） SPF的部署情况

表1-12展示了SecRank Top 100万域名的SPF部署情况，其中有34.43%的域名部署了SPF记录，而部署了有效SPF记录（语法正确）的域名更是只有32.92%，不及三分之一。考虑到不是所有的域名都提供邮箱服务，因此统计配有MX记录的域名中SPF的配置情况，其部署率和有效部署率分别为65.21%和62.31%。

表1-12 SecRank Top 100万域名SPF部署情况

表1-13 展示了Alexa Top 100万域名的SPF部署情况，其中有52.02%部署了SPF记录，而部署了有效的SPF记录的域名为49.95%，比SecRank的34.43%和32.92%部署率更高。

表1-13 Alexa Top 100万域名的SPF部署情况

从SPF协议初次提出到2020年已经过去了14年，但是其部署率依旧不尽如人意。尽管有些域名仅用来展示信息，比如office.com，这些域名看起来可能并不需要SPF配置，但是如果没有配置SPF记录，那么这些域名就会有被攻击者伪造利用的风险，对接收方而言只是收到了一封来自没有配置SPF记录的发送方的邮件，邮件很可能进入收件箱，让用户受到欺骗。根据RFC文档的建议，即使域名没有邮箱服务，最好也配置一条SPF记录“v=spf1-all”，防止域名被他人伪造利用。

（2） DMARC的部署情况

表1-14显示了SecRank Top 100万域名的DMARC梯度部署率情况，其中有7.2%的域名部署了DMARC记录。分别对不同排名范围的域名进行测量，发现随着测量范围的扩大，DMARC的部署率明显下降。因为知名域名往往有更大的动力防止域名伪造攻击。DMARC的部署技术难度比较高也是影响普通域名对其部署的关键因素。对Alexa Top 100万域名的扫描结果如表1-15所示。

表1-14 SecRank Top 100万域名的DMARC梯度部署率

表1-15 Alexa Top 100万域名的DMARC梯度部署率

通过国内外DMARC的部署率梯度图（见图1-37）可以发现，DMARC部署率随域名知名度的下降而下降，且头部域名部署率国内外差距显著。

图1-37  国内外DMARC部署率梯度对比

此外，因为DMARC协议是基于SPF和DKIM验证结果构建的身份验证系统，所以它的部署率必然要低于SPF和DKIM协议，但重要性却要高于其他两个协议，一旦部署率过低，就会直接影响邮件安全拓展协议对于邮件伪造的保护效果。

考虑到DMARC的重要性，美国国土安全局（DHS）在2017年10月要求所有的联邦政府部门的邮件系统需要支持DMARC协议，此举大幅提高了美国政府部门的DMARC部署率。我国重要的邮件系统同样需要推广DMARC协议的部署。

（3） 邮件安全协议国内外部署现状分析

国内外邮件安全拓展协议的部署情况如图1-38所示。尽管3项安全拓展协议对于解决邮件伪造问题有很大的帮助，但在现实中部署率还不够理想。配置情况最理想的SPF如今也仅仅覆盖了SecRank Top 100万域名中34.4%。DMARC的部署率更是仍低于10%。DKIM的部署率虽然无法精确测量，但是初步估计也低于20%。这种低部署率带来的问题主要有以下两点。

图1-38 国内外邮件安全拓展协议的部署情况

1）邮件接收方不能将安全拓展协议视为必需的检查策略。不能直接将安全拓展协议的验证结果作为判定邮件是否被伪造的主要依据，因此依旧需要接收来自未配置安全拓展协议的发送方的邮件。

2）作为邮件发送方，即使自身部署了相关的安全拓展协议，但是接收方可能不会进行相关的检查，黑客可以利用这一点向安全性比较弱的邮箱发送伪造邮件，域名依然还是有被伪造的风险。

2．邮件安全协议部署存在常见错误

根据相关RFC协议对SPF和DMARC的配置进行语法分析，发现它们的部署失效率都在5%左右，充分证明现实中配置失效的情况经常发生。

在部署率本不够理想的情况下，配置失效进一步降低了安全拓展协议对于邮件伪造问题的防御效果，甚至会产生负面影响—让原本正常发送的合法邮件因为身份验证不通过而无法进入收件箱。因此在已经有主观意愿配置邮件安全拓展协议的情况下，这种配置失效是让人遗憾的，应当尽量避免。下文中也列出了很多安全拓展协议配置中常常出现的语法错误，可以供相关配置人员参考。

对SPF配置进行语法分析的结果如表1-16所示。在已配置SPF的域名中，依旧有4.40 %的域名存在语法错误。

表1-16 SecRank Top 100万域名的SPF配置语法错误情况

对DMARC部署的正确性进行分析，发现在已配置有DMARC的域名中有5.45%的域名存在语法错误，具体情况如表1-17所示。

表1-17 SecRank Top 100万域名DMARC配置中出现语法错误的情况

3．邮件安全协议生态存在的安全问题

（1）缺少明确的发送方策略

在测量中发现 3 项安全协议都存在缺少明确的发送方策略的问题。如图1-39所示，在SecRank Top 100万中部署SPF的域名只有不到40%将发送方策略配置为硬失败，而51%的域名都选择配置成软失败。同样，扫描结果显示70%的DMARC记录都选择将p字段配置成None，也就是发送方并没有声明当验证失败时的建议策略，只有15%声明了严格拒绝。缺乏强有力的处置措施，会让部署率本不算高的DMARC防御效果进一步下降。

DKIM协议本身并不包含发送方策略。如果发送方仅仅对邮件进行了DKIM签名，而没有发布明确的处置措施，那么接受方将不知道如果收到一封以该域名发出的没有DKIM签名的邮件该如何处理。DMARC协议的出现给邮件发送方提供了部署发送方策略的机会。所以大力推广DMARC也有助于弥补DKIM缺少处置策略的问题。

缺少强有力的处置策略，其实是将判定邮件来源的真实性这个难题留给了邮件接收方。没有可靠的判断依据，这让邮件接收方处于两难的境地。大多数时候邮件接收方选择将这种问题邮件放入收件箱，这会带来很大的安全隐患。 

图1-39 SecRank Top 100万域名的SPF和DMARC发送方策略占比

（2）SPF“include”机制的滥用问题

SPF为了使一个域名包含另一个域名的SPF配置而引入了“include”机制，这在方便了域名所有者配置SPF记录的同时，也带来了另一个问题—依赖关系复杂。

测量结果显示，在配有SPF记录的SecRank Top 100万域名中有61.8%的SPF记录使用了“include”机制。大量的电子邮件提供商会给其客户配置使用“include”机制的SPF记录，这带来的一个问题就是SPF记录中包含的IP地址可能不被域名所有者掌控。如图1-40绘制的近期部分知名邮件提供商的SPF依赖关系所示，每一家邮件提供商的SPF记录都覆盖了很多企业、学校、政府部门。甚至还存在部分域名同时在SPF记录中包含了多家邮件提供商的IP地址，这进一步增大了其SPF保护失效的风险。例如某著名的手机企业，在SPF记录中同时“include”了163.com、outlook.com和zendesk.com共3家邮件提供商。其SPF记录如下所示：

这些复杂的依赖关系违背了SPF协议让域名所有者声明该域名邮箱服务器使用的IP地址的设计初衷，IP地址无法起到区分不同域名的作用，极大地影响了SPF的保护效果。

图1-40  部分知名邮件提供商的SPF依赖关系示意图

根据SecRank Top 100万域名的SPF配置统计了这些域名对邮件服务商SPF记录的依赖情况，如表1-18所示。

表1-18 SecRank Top 100万域名对于邮件服务商的SPF记录依赖情况

选取排名Top30,000以内的域名，对其SPF记录中“include”机制的依赖关系绘图，如图1-41所示。这张图某种程度上可以体现一些邮件提供商的市场占有率，同时，也代表了潜在的安全隐患，大量的域名都通过“include”机制将相同的一批IP地址包含在内。这些邮件提供商的SPF记录如果不能保证所有IP地址都为其实际控制，那么大量域名的SPF配置将形同虚设。 

图1-41  Top 30,000域名的SPF“include”依赖关系

（3）SPF记录包含的IP地址过于宽泛

SPF本意是标识发信方邮件服务器的IP地址，用于确认发送方身份。但在实际的使用过程中，很多域名所有者会将CIDR配置得宽泛一些，这样可以提前预留出增加邮箱服务器的地址空间，或者方便服务器的IP地址更换。如果配置的CIDR范围内的IP地址全为该域名所有者，则不会出现问题，但是在实际情况中有很多域名配置的CIDR范围超过了其实际掌控范围，SPF记录中的很多IP地址并不被域名所有者所掌握，攻击者只需要拿到一个这样的IP地址，就可以发送伪造邮件且通过SPF校验。这破坏了SPF将IP地址用于身份校验的安全基础。例如某网站的SPF记录如下所示：

可以发现，gevestor.de域名的SPF记录包含了1,074,335,367个IP地址，其中一处CIDR掩码被设置为2导致其IP地址覆盖范围极大，属于明显的SPF记录配置错误，存在类似问题的域名还有很多。

（4）DKIM的公钥安全性问题

DKIM是基于数字签名技术的身份验证协议。它使用非对称密钥加密算法向电子邮件添加数字签名，以确保在传输过程中电子邮件不会被中间人伪造。在这种“PKI”的体系下，公钥的使用时间越长，泄露的风险越高。长时间不更换公钥，会带来极大的安全隐患，影响DKIM的验证效果。在基于PassiveDNS提取的DKIM数据集中，总计1,231,719个部署了有效DKIM的域名，其中共发现17,263个域名存在3年以上未更换公钥的情况，包括163.com、alibaba.com和github.com等知名域名。公钥有效期具体统计结果如表1-19所示。此外，由于数据集只覆盖2015年6月9日至2019年1月11日期间的数据，因此这些域名没有更换过公钥的时间可能更长。

表1-19 根据PassiveDNS数据分析得到的DKIM公钥有效期情况

此外，PassiveDNS的DKIM数据中发现了非常多的公钥共用的情况。这里仅考虑跨域的公钥共用，即不同的域名使用相同的一组公钥，这种情况很容易产生公钥泄露的问题，造成极大的安全隐患。统计结果显示，在1,231,719个部署了有效DKIM的域名中，有689,060个（55.95%）域名存在跨域公钥共用的问题（这里的跨域包含同一个二级域名下面的不同子域名）。

1．常见的主流邮件安全服务

基于SecRankTop100万域名的MX记录扫描结果，对这些收信邮件服务器的Banner信息进行了扫描与记录，并尝试基于Banner信息与MX记录对邮件服务进行识别，测量结果如表1-20所示。

表1-20 基于SMTP指纹识别得到的主流邮件厂商占比

可以看到，SecRank Top 100万域名中大约50%的邮件服务由QQ、Gmail等6家流行邮件服务商提供。对邮件服务器软件进行识别，可以发现其中一些域名的邮件服务基于开源邮件服务器软件搭建而成。如6.84%的域名邮件服务基于Postfix搭建而成，同时发现网易的大量以163.com结尾的邮件服务器基于HMail搭建而成。

在SMTP上部署StartTLS可以实现借助SSL/TLS的加密方法将不安全的传输连接升级成安全的连接，因此对邮件服务是否支持StartTLS的情况进行分析。结果如图1-42所示，有73%的邮件服务在收信中支持可用的StartTLS服务，而其余23%的邮件服务由于服务不可用、不支持StartTLS以及无法建立有效StartTLS连接等原因，并不能提供可用的StartTLS服务。 

图1-42  SecRank Top 100万域名对StartTLS的支持情况

2．主流邮件服务均受邮件伪造攻击影响

邮件发件人地址伪造是当前威胁邮件安全的主要攻击方式之一。电子邮件发件人地址伪造是网络钓鱼攻击中最关键的步骤。在攻击过程中，攻击者冒充受害者认识或者信任的人发送钓鱼邮件。通过冒充信誉良好的组织或者好友的电子邮件地址，攻击者可以大大增加钓鱼邮件攻击的成功率。据Valimail的报告称，当前全球每天至少有34亿的伪造邮件被发送出去，并且大多数行业深受鱼叉式网络钓鱼攻击的危害。对SecRank Top 100万域名中可免费注册的公共邮件服务进行分析，可以发现当前主流的邮件服务均不同程度地受到邮件伪造攻击的影响。具体结果如表1-21所示。

表1-21 主流公共邮件服务协议部署以及受邮件伪造攻击影响情况

表1-21中发件人伪造攻击方式（A1、A2、A3、A4）的详细介绍如下。

（1） IDN同形异义词攻击（A1）

IDN同形异义词攻击是近年来开始流行的一个Web安全问题，但是该问题对电子邮件领域的安全性的影响尚未被系统地讨论。与此同时，随着电子邮件厂商逐步支持IDN域名，该攻击将会产生更广泛的安全影响。Punycode编码是一种将无法以ASCII表示的单词转换为Unicode ASCII编码的方式。值得注意的是，Unicode的很多字符与常规的字符具有非常相似的外观，从而达到欺骗伪装的效果。图1-43展示了一封基于IDN域名的发件人伪造邮件，该电子邮件似乎发自于admin@paypal.com，但实际上来自于IDN域名xn–aypal-uye.com。 

图1-43 利用IDN同形异义词攻击冒充admin@paypal.com对iCloud邮箱发起伪造攻击示例

（2） From不一致攻击（A2）

SMTP协议没有任何内置的安全性功能来保证Mail From与MIME（Multipurpose Internet Mail Extension，多用途互联网邮件扩展类型）From头部的一致。因此，攻击者可以通过不同的Mail From和MIME From头部来发送电子邮件。比如将Mail From头部设置为Attacker@a.com，但是将MIME From头部的值设置为admin@a.com。此时，受害者将看到来自于admin@a.com的伪造邮件。虽然该攻击技巧已被攻击者广泛滥用，但当下主流邮件服务依旧受此类攻击的影响。更为糟糕的是，许多流行的电子邮件服务（如Outlook、Sina、QQ邮件）和大多数第三方电子邮件客户端（如Foxmail、Apple Mail）仅在用户界面显示MIME From头部的值，而不会显示Mail From头部。针对这类发件人伪造邮件，受害者甚至无法在UI上看到任何的安全告警标志。

（3） 歧义解析攻击（A3）

电子邮件地址是一个格式非常灵活、复杂的富文本。这导致邮件服务很难正确解析与展示发件人地址，带来了很多解析上的歧义理解。与此同时，这些歧义理解可被攻击者滥用于绕过协议身份验证以及欺骗目标电子邮件客户端。首先，电子邮件地址支持邮件路由、邮件列表、注释、空邮件地址等撰写格式。因此，下列邮件地址都是合法的：<@a.com,@b.com:admin@c.om>、<a@a.com>,<b@b.com>、<admin(username)@a.com(domain name)>。其次，当从目标邮件中提取与解析邮件地址时，存在一系列字符可能影响到字符串解析流程。比如，从字符串admin@a.com\x00@attck.com中解析目标域名时，程序将获得不完整的域名（a.com），攻击者可以使用这类技术绕过电子邮件安全协议的验证，并且达到较好的邮件地址伪造效果。与此同时，我们同样发现一些不可见的Unicode字符（如\uff00-\uffff）和语义字符（如[,],{,},\t,\r,\n）同样可能导致解析流程的异常。攻击示例如图1-44所示。

图1-44 6种造成歧义解析的攻击示例

（4） 子域名伪造攻击（A4）

攻击者可以通过冒充知名邮件服务的子域名邮箱（如admin@mail.google.com）来发送钓鱼邮件，如图1-45所示。许多公司会使用子域名来发送业务订阅电子邮件，比如Paypal、Gmail、工商银行等。因此，当普通用户收到来自知名厂商的子域名邮件时，往往会倾向于信任此类电子邮件。由于SPF缺乏对邮件子域名的保护，因此攻击者可以通过这类技巧来绕过域名的SPF保护。

图 1-45 子域名伪造攻击伪造成来自于 alice@mail.google.com 的邮件

（未完待续……）

版权声明：本研究报告由清华大学（网络研究院）-奇安信集团网络安全联合研究中心撰写完成，版权属于双方共有，并受法律保护。转载、摘编或利用其它方式使用本研究报告文字或者观点的，应注明来源。

【年度报告连载】互联网基础设施安全的范畴与形势

【年度报告连载二】域名系统安全现状

【年度报告连载三】HTTPS部署与公钥证书现状

【年度报告连载四】内容分发网络安全现状