近日，德国安全研究员 Sabri Haddouche发现30多种邮件客户端中存在漏洞，可以让任意用户伪造身份发送欺诈邮件并绕过反欺诈保护机制（如 DMARC 等）和多种垃圾邮件过滤器，Sabri把这些邮件客户端漏洞集统称为MailSploit，目前它主要影响 Apple Mail（macOS, iOS, and watchOS）、Mozilla Thunderbird、 部分 Microsoft 客户端、Yahoo Mail、ProtonMail 等，MailSploit漏洞集目前主要包括邮件身份伪造漏洞、邮件跨站漏洞（XSS）和代码注入漏洞。
电邮身份伪造背景
90年代和2000年初期，电邮身份（Email identity）很容易被伪造，只需把邮件发送的“From”头区域修改为父母、重要人士或执法机构等其它名称内容，甚至还有专门制作伪造邮件的网站。但是，随着反欺诈保护和邮件过滤机制的应用，这些恶意技巧就失效了。如今，邮件服务端的各种反欺诈保护和邮件过滤手段都能检测到“From”区域的伪造内容，由于其高效的沟通能力，电邮服务和我们形影不离，但这种手段也并不安全，大量恶意软件、钓鱼链接和勒索病毒利用电邮进行传播扩散。
那么，现在，是否存在一种手段像1999年那样，能轻松绕过DMARC伪造发件人呢？有的！
MailSploit工作机制
Mailsploit就是一种新型的电邮身份伪造手段，攻击者可以使用它伪造任意用户身份进行邮件发送，我用邮件地址potus@whitehouse.gov做个示例（其它邮件地址也可以），整个伪造流程是这样的：在一封电邮中，包括”From”区域在内所有的头信息都必须是ASCII字符，主要问题在于用以区分MTA处理机制的非ASCII字符编码表示协议RFC-1342上。
RFC-1342：把电邮主题或地址部分的非ASCII字符编码转换为ASCII字符，以避免邮件服务端发生传输错误。
但很多邮件客户端和Web登录接口在采用RFC-1342对非ASCII字符编码后，都不会对用来伪造电邮身份的编码字符进行有效检查，就像这样：
=?utf-8?b?[BASE-64]?=
=?utf-8?Q?[QUOTED-PRINTABLE]?=
以上Base64和QUOTED-PRINTABLE（可打印字符引用编码）两种表示方式都可行，但使用新行或空字节等控制字符组合，可以让我们隐藏或删除原始电邮的域名后缀部分，从而允许我们将其替换。因为：
iOS系统存在空字节注入影响
macOS存在“email(name)”注入
也就是说，如果RFC-1342解析的邮件字符中包含空字节或两个或更多电邮地址，邮件客户端最终只会显示空字节或有效电邮地址之前的伪造地址。上述两种方式结合可在iOS和macOS系统中有效执行伪造，攻击者可以像这样把伪造的电邮地址有效经过RFC-1342编码：
From: =?utf-8?b?${base64_encode('potus@whitehouse.gov')}?==?utf-8?Q?=00?==?utf-8?b?${base64_encode('(potus@whitehouse.gov)')}?=@mailsploit.com编码后变为：
From: =?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=00?==?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=@mailsploit.com该From信息被邮件客户端解析后就变为这个：
From: potus@whitehouse.gov\0(potus@whitehouse.gov)@mailsploit.com邮件客户端经过解析后只会显示第一个电邮地址potus@whitehouse.gov，而忽略了真实的电邮域名@mailsploit.com。
在iOS系统上的PoC测试视频：
看不到？点这里
30多种电邮客户端受影响
据安全研究员Sabri声称，目前有超过30多种的电邮客户端受到影响（具体列表），在其联系了各家受影响厂商后，只有8家及时修复了该邮件解析漏洞，12家确认了漏洞但并未明确给出具体的修复日期，另有12家还未确认该漏洞。Mozilla和Opera明确表示，这是客户服务端问题，他们不会修复这种漏洞。
另外，攻击者利用Mailsploit漏洞集，还能隐藏恶意代码，或是在webmail客户端执行XSS或代码注入等攻击（详见Demo），好在不是所有邮件客户端都受Mailsploit漏洞集影响，目前来说影响还不算特别严重。
*参考来源：mailsploit，freebuf小编clouds编译