SPF 电子邮件验证协议

admin 2024年2月14日01:30:13评论10 views字数 5407阅读18分1秒阅读模式

SPF 电子邮件验证协议

介绍

SPF 电子邮件验证协议的快速概述(示例、漏洞)。

SPF(发件人策略框架)用于强化您的 DNS 服务器并限制谁可以使用您的域名发送电子邮件。

发件人框架策略预先提供了被授权代表域发送电子邮件的 IP 地址列表。它指定了一种防止发件人地址伪造的技术方法。此 IP/域列表存储在域 TXT 记录的 DNS 记录中。具有 SPF 的电子邮件提供商将查找电子邮件声称所在域的 DNS 记录。它将将该信息与原始 IP 地址/电子邮件进行比较。如果检查匹配,电子邮件将通过。如果不这样做,电子邮件可能会被标记为垃圾邮件或被拒绝。SPF 仅检查电子邮件的发件人部分。

SPF 电子邮件验证协议

检查域 SPF

nslookup -type=txt <selector>._domainkey.<domain>

SPF 限定符(操作)

我们可以将任何机制与四个限定符中的任何一个一起使用:

  • + for aPASS :允许所有邮件。这个可以省略;例如,+mx mx 相同

  • ?对于 aNEUTRAL:接受所有电子邮件(例如?全部 - 无政策声明)

  • ~(波形符)SOFTFAIL :电子邮件被接受/向用户显示,但标记为可疑/垃圾邮件警告(例如 ~all – 允许邮件,无论其是否与参数匹配)

  • (减号)forHARDFAIL:所有疑似伪造或垃圾邮件的电子邮件均被拒绝且不送达(例如 -all – 仅允许与其中一个参数匹配的邮件)

SPF机制

>>all始终匹配。一般设置在最后。

  • "v=spf1 mx -all" :允许域的MX为该域发送邮件,禁止所有其他MX

  • "v=spf1 -all" : 该域根本不发送邮件。

  • "v=spf1 +all" :域名所有者认为 SPF 无用/或不在乎。

>>ipv4IPv4网络范围。如果未设置CIDR ,则默认为 /32对于ipv6,该ip6 机制的参数是 IPv6 网络范围。如果没有设置网络掩码,则默认为/128

  • "v=spf1 ip4:192.168.0.1/16 -all" :允许 192.168.0.1 192.168.255.255 之间的任何 IP 地址。

  • "v=spf1 ip6:1080::8:900:200C:417A/96 -all" :启用 1080::8:900:0000:0000 1080::8:800:FFFF:FFFF 之间的任何 IPv6 地址。

  • "v=spf1 ip6:1080::8:900:68.0.3.1/96 -all" :允许 1080::8:900:0000:0000 1080::8:800:FFFF:FFFF 之间的任何 IPv6 地址。

>>a:测试域中的所有 A 记录。如果在其中找到客户端 IP,则表示匹配。对于通过 IPv6 建立的连接,将执行 AAAA 查找。如果未设置域,则使用当前域。

  • "v=spf1 a -all" :使用当前域。

  • "v=spf1 a:example.com -all" :如果当前域是 example.com,则等效。

  • "v=spf1 a:mail.example.com -all" :也许 example.com 选择在 mx.example.com 下的特殊 A 记录中明确列出所有出站邮件程序。

  • "v=spf1 a/24 a:sub.example.com/24 -all" :如果 example.com 解析为 192.0.3.2,则会在 192.0.3.0/24 的整个 C 类中搜索客户端 IP。对于 sub.example.com 也是如此。如果返回多条 A 记录,每条记录都会扩展到一个CIDR子网。

>>mx:按 MX 优先级顺序测试域的所有 MX 记录的所有 A 记录。如果在其中找到客户端 IP,则表示匹配。如果没有域,我们将使用当前域。A 记录必须与客户端 IP 完全匹配,除非提供后缀长度,在这种情况下,A 查找返回的每个 IP 地址将扩展为其相应的 CIDR前缀,并且将在该子网内搜索客户端 IP

  • "v=spf1 mx mx:deferrals.domain.com -all" :也许某个域通过其 MX 服务器以及另一组服务器发送邮件,这些服务器的工作是为延迟域重试邮件。

  • "v=spf1 mx/24 mx:offsite.domain.com/24 -all" :也许某个域的 MX 服务器在一个 IP 地址上接收邮件,但在另一个不同但邻近的 IP 地址上发送邮件。

>>ptr:使用 PTR 查询查找客户端 IP 的一个或多个主机名。然后验证主机名:PTR 主机名的至少一条 A 记录必须与原始客户端 IP 匹配。无效的主机名将被丢弃。如果有效的主机名以域结尾,则此机制匹配,否则我们将依赖当前域。

避免在 SPF 记录中使用此机制,因为这会导致大量昂贵的 DNS 查找。

  • "v=spf1 ptr -all" :直接控制其所有计算机的域(与拨号或宽带 ISP 不同)允许其所有服务器发送邮件。例如,hotmail.com paypal.com 可能会执行此操作。

  • "v=spf1 ptr:otherdomain.com -all" :指定主机名以 otherdomain.com 结尾的任何服务器。

>>存在:对提供的域执行A查询。如果找到结果,则表示匹配。查找结果是什么并不重要 它可能是 127.0.0.2

  • "v=spf1 exists:example.com -all" :如果 example.com 无法解析,则结果为失败。如果确实解决了,此机制就会产生匹配。

>>include:在指定的域中搜索匹配项。如果查找未返回匹配项或错误,则处理将继续执行下一个指令。

警告:如果域没有有效的 SPF 记录,则会导致永久错误。某些邮件接收者会根据 PermError 拒绝邮件。

在以下示例中,客户端 IP 1.2.3.4,当前域为 example.com

"v=spf1 include:example.com -all"

如果 example.com 没有 SPF 记录,则结果为PermError

假设 example.com SPF 记录为“v=spf1 a -all”

查找 example.com A 记录。如果匹配 1.2.3.4,则返回Pass

如果没有匹配,除了被包含域的-all外,整个包含都匹配失败;从本示例中设置的外部指令来看,最终结果仍然是失败

SPF调节剂

修饰符是可选的。每个记录只能出现一次修饰符。未知的修饰符将被忽略

>>重定向: SPF 记录替换当前记录。宏扩展也会替换这些查找中的当前域。

以下示例:客户端 IP 1.2.3.4,当前域为 example.com

"v=spf1 redirect=example.com"

如果 example.com 上没有 SPF 记录,则出现错误。结果未知。

例如,如果 example.com SPF 记录为“v=spf1 a -all”

检查 example.com A 记录,如果匹配 1.2.3.4,则返回Pass

如果没有匹配,则 exec 匹配失败,并使用 -all 值。

>>exp:(很少使用)如果 SMTP 接收方拒绝邮件,它可以包含解释。SPF 发布者可以指定发件人看到的解释字符串。这样,ISP 就可以将不合格的用户引导至提供有关如何配置SASL 进一步说明的网页。领域扩大了;执行 TXT 查找。TXT 查询的结果随后被宏扩展并显示给发送者。其他可用于提供定制的解释。

漏洞(绕过/绕过 SPF

SPF 电子邮件验证协议本身对于保护您的域免遭滥用实际上并没有多大帮助。最大的问题是 SPF 的身份验证决策基于大多数人从未见过的消息头字段(返回路径)。这使得黑客很容易创建看似合法但实际上是欺诈的邮件(因为他们在发件人字段中使用了其他人的域)。

简单示例(Office 365

查找没有 SPF 记录的域或查找具有开放”SPF 的域。

# telnet <mail server> 25EHLO domainX.com250-ESMTP Server ReadyMAIL FROM: <[email protected]>250 +OK Sender OKRCPT TO: <target_user@target_domain.com> SIZE=43251250 +OK Recipient OKDATA354 Start mail input, end with '<CR><LF>.<CR><LF>'FROM: "Jack the CFO" <jack@target_domain.com>TO: "target_user" <user@target_domain.com>SUBJECT Important requestPlease send me your user credentials, I forgot mine. P.S. Don't tell anyone. Thanks.

第一部分(红色)是Mail envelope部分。它的存在是为了误导”SPF(绕过验证测试)

第二部分(绿色)是Mail header。它的存在是为了误导最终接收者。

完成接受电子邮件消息所需的过程后,邮件服务器将删除Mail envelope包含有关发件人身份的信息(存储在 MAIL FROM 字段中)的消息。在删除之前,该值将被移动/复制到 RETURN-PATH 字段。如果消息无法传递给收件人,则存在该字段。在这种情况下,服务器将使用该地址将 NDR 消息发送回发件人。

这并不理想。我们没有提供用户凭据,因此发件人被识别为匿名。这可能会导致发件人信息在收件人的电子邮件客户端上显示有点不同(很难注意到)。

罗纳德·里根攻击(Gmail SPF 绕过)

一种用于绕过 Gmail SPF 检查鱼叉式网络钓鱼的新方法。黑客从外部服务器发送信息,用户看到内部用户(例如您的 CEO),Gmail SPF 检查显示 SPF-OK

电子邮件标头中有两个字段在这里发挥作用:

  1. X-Sender-IdGmail SPF 检查中使用的字段,用于鱼叉式网络钓鱼和模拟分析

  2. From:实际呈现给 Gmail 用户的字段

该电子邮件完全合法,并在没有任何警告的情况下将其传递给收件人。这显示为来自其他人的电子邮件,大概是他们认识的组织中的某个人。

(1)X-Sender-Id:这是真正的发件人(欺骗的)。攻击最重要的部分,与发送电子邮件的服务器保持一致。

(2)Reply To :此标头字段 (FROM) 呈现给收件人,但实际回复会发送到“Return-Path”中指定的电子邮件(前面的示例显示了如何填写此字段)。回复也被欺骗:在不存在的域中使用模拟的受害者名称

(3)Authentication-Results和:这些字段指示收件人 (Gmail) 计算出的电子邮件的真实性Received-SPFArc-Authentication-Results请注意,在所有测试中,都会选择 X-Sender-ID 中的电子邮件地址作为要测试的身份(如 X-Auth-Id 字段中所示),并且所有测试均成功通过 - 电子邮件是真实的

(4)Return-Path:如果最终用户选择回复发件人,邮件服务器将使用此字段。用户看到的回复字段是欺骗性的,回复将通过返回路径字段正确路由给攻击者。

(5)From:冒充发件人(欺骗)的电子邮件地址。

ARP 欺骗(敌后)

地址解析协议 (ARP) 是一种将 IP 地址映射到本地网络中可识别的物理机地址(MAC – 媒体访问控制)的协议。ARP/缓存用于维护MAC(第2层地址)和相应的IP地址(第3层地址)之间的关联。如果您不熟悉网络层(OSI 模型 ,请重新检查它们。通过 ARP 欺骗,我们可以广播虚假的 ARP 信息。目标是强制 DNS 流量通过我们的计算机(作为网关),以便我们可以更改通过的流量。

实现此目的后,我们现在可以使用一些工具(例如 Ettercap)来修改 DNS 响应以满足我们的需求:告诉接收邮件服务器任何 IP 都可以向目标 <DOMAIN> (SPF=+all) 发送电子邮件,从而导致有效的 SPF 检查。使用 Ettercap 我们可以指定一个过滤器(修改流量):

if (ip.proto==UDP &amp;amp;&amp;amp; udp.src==53 &amp;amp;&amp;amp; search(DATA.data, &quot;v=spf1 mx -all&quot;)) {    replace(&quot;v=spf1 mx -all&quot;, &quot;v=spf1 mx +all&quot;);    msg(&quot;Mail Server Opened!&quot;);}

使用 Etterfilter 编译它:

etterfilter myfilter.filtero myfilter.ef

使用 Ettercap 设置攻击:

ettercap –TqM arp:remote –F myfilter.ef /192.168.1.10-15/ /192.168.1.33/

当出现消息邮件服务器已打开时,继续尝试通过 Telnet 发送电子邮件。

结论

这就是 SPF 电子邮件验证协议的全部内容(示例、漏洞)。当我们继续涵盖相关主题时,我们将在稍后更新/扩展文章。请记住,您宣传 SPF 记录并不意味着其他任何人都必须遵守它。任何给定邮件服务器的管理员都可以选择接受哪些电子邮件。因此,如果某些管理员抱怨您的域向他们发送垃圾邮件并且您拥有 SPF 记录,请不要惊慌。他们可能没有检查 SPF 记录。世界上到处都是拉默。

查看“Telnet 电子邮件地址验证以获取有关 MX 通信/响应的一些示例,或查看 DKIM 以获取进一步改进。

SPF 电子邮件验证协议

surface选择* ,其中Dark

夜晚是最孤独的,也许,就这样吧

原文始发于微信公众号(深网知识库):SPF 电子邮件验证协议

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2024年2月14日01:30:13
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   SPF 电子邮件验证协议http://cn-sec.com/archives/2205095.html

发表评论

匿名网友 填写信息