以任何Gmail或G Suite客户身份发送SPF和DMARC传递邮件

由于配置邮件路由时缺少验证，Gmail和任何G Suite客户严格的DMARC/SPF策略都可能被使用G Suite的邮件路由规则来中继和授予欺诈性消息的真实性颠覆。这与过去的经典邮件欺骗明显不同，在过去的邮件欺骗中，From报头被赋予一个任意值，这种技术很容易被使用发件人策略框架(SPF)和基于域的消息验证、报告和一致性(DMARC)的邮件服务器阻止。该漏洞是Google独有的漏洞，使得攻击者能够以任何其他用户或G Suite客户的身份发送邮件，同时仍然通过最严格的SPF和DMARC规则。

2020年4月16日-谷歌接受这个问题，将其归类为优先级2，严重程度2错误。

2020年8月1日-没有进步或缓解的证据，问题仍然可以使用120天前传达给Google的相同技术重现。

2020年8月1日-谷歌接到我发表意向的通知，披露截止日期定为8月17日(16天)。

2020年8月5日-谷歌承认了这个问题，声明他们已经解决了这个问题，并提出应该在我17日披露之前启动一些缓解措施。

2020年8月14日-谷歌更新罚单，声明漏洞修复要到9月17日才会发布。

2020年8月19日(美国太平洋标准时间下午3：13)-谷歌更新了罚单，提供了一系列基于返回路径修改和反滥用机制的缓解措施，在这篇帖子上线后不久就部署了一系列缓解措施。

虽然我在修补之前公开披露了这个漏洞(我可以补充一句，我不喜欢这样做，因为它就是不太好)，但我对谷歌的安全团队绝对没有恶意，因为他们在整个报告过程中一直很友好，非常明确地表示，他们不希望压制或以任何方式限制披露。[更新：在这篇帖子上线后的7个小时内，这个问题被修补了。出色的工作！]

如果您已经熟悉SPF和DMARC，请随意跳过！

电子邮件是一种古老的技术，来自互联网不过是研究型大学和政府实验室的时代。这是一个时间点，在这个时间点上，如果有人滥用电脑，你可以打电话给他们或他们的主管，亲自斥责他们。然而，随着互联网的发展，越来越多的对手在网上找到了出路，像电子邮件这样非常信任和不安全的系统需要发展。

电子邮件的成长之痛之一是，默认情况下，邮件的内容和发送者都是完全未经验证的。这意味着当邮件服务器接收到一条消息时，没有明确的方法来确定该消息是否确实来自它声称的地址。换句话说，任何人都可以声称他们有一条来自(受保护的电子邮件)的信息，而邮件服务器几乎没有正式或严格的手段来揭穿他们的虚张声势。这当然是一个巨大的问题，因为钓鱼和诈骗作为用户，无论是好是坏，都信任和依赖电子邮件域来确保他们正在与他们认为自己是谁交谈。

这个问题的解决方案是增加新的控制，允许域的操作员通知邮件服务器允许哪些IP地址从域发送邮件。这允许管理员为接收邮件服务器提供他们需要的工具，以自信地断定发件人的虚张声势，因为他们现在能够将发件人的IP地址(由于使用TCP的电子邮件，无法伪造)与授权发件人列表进行比较。如果发件人的IP不在列表中，邮件服务器可以自信地拒绝该邮件，并防止欺诈性电子邮件攻击其用户的收件箱。

此保护的关键要点(对此漏洞很重要)是SPF和DMARC使用发件人的IP来保护其免受欺骗和欺诈性消息的攻击。这就是说，如果消息来自批准的源，则它在SPF和DMARC下被认为是合法的。

在浏览G Suite管理员控制台时，我注意到我可以使用“Settings for Gmail”下的“Default Routing”选项为我的域上的入站邮件创建全局邮件路由规则。这些规则允许我在Google的其他基础设施处理电子邮件之前，应用自定义标题、修改主题行或更改电子邮件的收件人。

最后一个选项(上面显示为“更改信封收件人”)特别有趣，因为它允许我指定一个任意的收件人，并使Google的后端将电子邮件重新发送给其他人。令人担忧的是，收件人值被G Suite接受，而没有执行任何验证以确保我拥有目标电子邮件地址或目标域。当我回想起SPF和DMARC时，这种行为立即在我的脑海中敲响了警钟，因为这个有漏洞的功能可以让我将传入的电子邮件(包括欺骗电子邮件)重定向到使用谷歌后端的其他人，这样如果受害者还指定谷歌为批准的发件人，那么根据SPF和DMARC，它看起来不再是欺骗的！

(联合国)幸运的是，这个通过路由规则发送欺骗电子邮件的初始程序并不完全有效。虽然我能够成功地让谷歌后端使用没有SPF/DMARC或采用较弱的软故障/隔离策略的域名重定向和重新投递欺骗电子邮件，但我发现使用DMARC的强化拒绝策略的域名无法投递，因为我的欺骗电子邮件由于SPF/DMARC强制执行而被丢弃在谷歌的边界邮件服务器上。这相当令人失望，因为大多数值得模拟的目标都使用p=reject，因此似乎不容易受到攻击。这是我旅程的终点吗？是我危险探索的顶峰吗？不要害怕，亲爱的读者，事实并非如此！

说真的，这个问题的变通方法并不是特别复杂。通过深入研究G Suite管理面板，我找到了一个部分，可以为我的域配置Google所说的“入站网关”。谷歌在他们的文档(重点是我的)中对这一功能提供了简洁的解释：

入站邮件网关是所有传入邮件都要经过的服务器。网关通常以某种方式处理邮件，例如将其存档或过滤垃圾邮件。然后，它将邮件传递到邮件服务器，该服务器将邮件传递给收件人。

您可以配置入站网关设置以标识网关的IP地址或地址范围。Gmail跳过对网关IP列表中包括的IP地址执行SPF检查。如果设置了入站网关，则应由入站网关执行DMARC检查，对于从列出的主机到达的消息将跳过该检查。

关于带有入站网关的SPF和DMARC的最后说明正是我想要的。这是因为它将允许我将原本会因为SPF和DMARC故障(如欺骗消息)而被彻底拒绝的消息注入Google的邮件基础设施，从而使它们按照我的自定义邮件路由规则进行处理。

通过将G Suite邮件验证规则中被破坏的收件人验证和入站网关链接在一起，我能够使Google的后端重新发送任何域名的邮件，这些域名在收到邮件时显然是被欺骗的。如果攻击者打算冒充的受害者也使用Gmail或G Suite，这对攻击者是有利的，因为这意味着Google后端发送的消息将同时通过SPF和DMARC，因为通过使用G Suite，他们的域将被配置为允许Google后端从他们的域发送邮件。此外，由于该消息来自Google的后端，因此该消息也有可能会有较低的垃圾邮件分数，因此应该减少过滤频率。

在这个概念证明中，我使用我的个人G Suite域([Email is Protected])将一封看似合法的电子邮件从google.com地址发送到我不控制的域([Email is Protected])上的我校的G Suite电子邮件。我选择发送到另一个G Suite账户，以证明谷歌强大的邮件过滤和反垃圾邮件技术不会阻止或检测到这种攻击。此外，我选择模拟google.com，因为他们的DMARC策略被设置为p=reject，因此任何违反SPF的行为(不管SPF策略如何)都会导致邮件被有偏见地丢弃。

以下是一封从最终受害者的角度略微清理的电子邮件，删除了各种不相关的标题，以提高可读性：

收件人：[受保护的电子邮件]接收日期：2002年前：a05：6830：1db6：0：0：0：0：0：0；SMTP id z22csp1120956oti；星期五，2020年4月3日15：41：27-0700(PDT)X-接收日期：2002年前：a17：90b：915：SMTP id bo21mr10227430pjb.58.1585953687701；周五，03 Apr 2020 15：41：SPF=PASS(google.com：域的[电子邮件受保护]指定209.85.220.69为允许发件人)[电子邮件受保护]；dmarc=PASS(p=reject sp=reject dis=NONE)header.from=google.com return-path：<；[电子邮件受保护]>；Received：from mail-sor-f69.google.com(mail-sor-f69.google.com)。[209.85.220.69])由mx.google.com提供，SMTPS id为o11sor13151518plk.43.2020.04.03.15.41.27，适用于<；[电子邮件受保护]>；(Google传输安全)；Fri，03 Apr 2020 15：41：27-0700(PDT)已收到-SPF：PASS(google.com：[电子邮件受保护]的域指定209.85.220.69为允许发件人)client-ip=。SPF=PASS(google.com：Domain of Not_Maltual_[电子邮件受保护]指定209.85.220.69为允许发件人)[电子邮件受保护]；dmarc=Pass(p=Reject sp=Reject dis=None)header.from=google.com X-Original-Authentication-Results：mx.google.com；SPF=softail(google.com：转换域[电子邮件受保护]未将64.90.62.162指定为允许发件人)[电子邮件受保护。Fri，03 Apr 2020 15：41：27-0700(PDT)ARC-Authentication-Results：i=1；mx.google.com；SPF=softail(google.com：转换域[电子邮件受保护]未将64.90.62.162指定为允许发件人)[电子邮件受保护]返回路径：<；[电子邮件受保护]>；已接收：来自chocolate.Birch.relay.mailchannel els.net(chocolate.Birch.。[23.83.209.35])由mx.google.com提供，ESMTPS ID为s12si7121157pgq.251.2020.04.03.15.41.26，适用于<；[电子邮件受保护]>；(版本=TLS1_2密码=ECDHE-RSA-AES128-GCM-SHA256位=128/128)；周五，03 Apr 2020 15：41：26-0700(PDT)已收到-SPF：soft

此消息中第一个值得注意的标头是Google在第一次从攻击者中继地址([电子邮件受保护])的入站网关收到该消息时对该消息的调试ARC分析，在该地址检测到SPF和DMARC故障，但由于入站网关配置的原因没有对其采取行动：

Arc-Authentication-Results：i=1；mx.google.com；SPF=softail(google.com：转换域[电子邮件受保护]未将64.90.62.162指定为允许发件人)[电子邮件受保护]。

第二种情况是受害者([电子邮件受保护])收到该邮件，Google重新评估该邮件，并确定SPF和DMARC都通过了严格的p=reject策略：

身份验证-结果：mx.google.com；Arc=PASS(i=1)；SPF=PASS(google.com：[电子邮件受保护]的域指定209.85.220.69为允许发件人)[电子邮件受保护]；dmarc=PASS(p=reject sp=reject dis=None)header.from=google.com。

这会导致来自具有强SPF和DMARC配置的高度受信任域的完全非法邮件会在没有任何警告的情况下直接传送到受害者的收件箱：

如果你已经走到这一步，请考虑关注@ezhes_(me！)。在推特上听到我最新的披露/其他安全漫谈！