0%
毅种循环

返回

有关SPF邮件信息伪造的内容Blur image

为什么我能假冒你们 CEO 发邮件?(即便你以此为豪配置了 SPF)#

很简单的一件事,就是客户的域名配置了SPF,但是给的是软策略,基本上邮件都能通过,今天被监管通报了。

img 1765777674454 0df763

大概差不多就是这样吧,图是我后面补的。

关于邮件这一块我也了解得不深,基本不会遇到这种有效的漏洞,这次恰好测试就干脆记录一下。

有关SPF的查询,可以到这里进行:https://www.site24x7.cn/zhcn/tools/spf-validator.html

img 1765777674575 c5c1d0

状态会有4种,大概解释一下。

这四个符号(-, ~, ?, +)被称为 SPF 限定符 (Qualifiers),它们决定了“当发信 IP 不在允许列表中时,接收方该怎么处理”。

我们可以把邮件服务器比作小区的保安,IP 地址就是访客的身份证。


SPF的四种状态码#

1. Hard Fail#

-all
plain
  • 含义硬拒绝。只有列表里的 IP 能发,其他的全是伪造,直接拒收。
  • 保安视角:“我手里有一份白名单。只有名单上的人能进。**所有不在名单上的人,直接拿棍子打出去!**连门都不让进。”
  • 后果:邮件直接被 SMTP 层级拒绝(550 Error),发件人会收到退信。
  • 举例
    • 配置
v=spf1 ip4:1.1.1.1 -all
plain
- **攻击**:黑客用 IP
plaintext
2.2.2.2
plain

伪造邮件。

- **结果**:QQ/Gmail 服务器说:“你不是 1.1.1.1,并且策略是 -all,**滚**。”
plaintext

2. Soft Fail#

~all
plain
  • 含义软拒绝。不在列表里的 IP 也能发,但会被标记为“可疑”或垃圾邮件。
  • 保安视角:“我手里有白名单。不在名单上的人…我想拦,但我老板(管理员)怕拦错了客户。行吧,你进去吧,但我在你背上贴个条子:‘此人可疑’ 。”
  • 后果:邮件会被接收,但极大概率进入垃圾箱,或者显示红色警告。
  • 举例
    • 配置
v=spf1 ip4:1.1.1.1 ~all
plain
- **攻击**:黑客用 IP
plaintext
2.2.2.2
plain

伪造邮件。

- **结果**:能够发送成功,但受害者的收件箱里会显示“此邮件可能不是由 info@domain.com 发送的”,或者直接躺在垃圾箱里。这是目前互联网最常见的配置(为了防止误杀)。
plaintext

3. Neutral#

?all
plain
  • 含义中立。不做任何声明。不管 IP 在不在列表里,我都“不置可否”。
  • 保安视角:“我手里没有名单,或者说我懒得管。你是谁?我不知道。能不能进?你自己问屋里人去。
  • 后果:SPF 检查结果是 Neutral,邮件通常会被放行进入收件箱(除非内容本身太像垃圾邮件)。这等于配置了个寂寞。
  • 举例
    • 配置
v=spf1 ip4:1.1.1.1 ?all
plain
- **攻击**:黑客用 IP
plaintext
2.2.2.2
plain

伪造邮件。

- **结果**:大摇大摆进入收件箱,不做任何拦截。
plaintext

4. Allow All#

+all
plain
  • 含义全通过。任何 IP 都是合法的发件人。
  • 保安视角:“大门敞开!谁都可以进! 面具人、强盗、骗子,统统欢迎!”
  • 后果:任何黑客都可以完美伪造你的域名,且 SPF 检查结果是 PASS
  • 举例
    • 配置
v=spf1 +all
plain

(极少见,除非是测试或者蜜罐)

- **攻击**:黑客用 IP
plaintext
2.2.2.2
plain

伪造邮件。

- **结果**:邮件不仅进了收件箱,而且系统还告诉用户“这封邮件是通过 SPF 安全验证的哦”。**这是极度危险的配置错误。**
plaintext

符号模式伪造难度后果推荐度
-allHard Fail⭐⭐⭐⭐⭐ (极高)直接拒收推荐 (只要确保 IP 没漏填)
~allSoft Fail⭐⭐⭐ (一般)进垃圾箱过渡期推荐
?allNeutral⭐ (极低)进收件箱不推荐
+allPass☠️ (无)SPF Pass绝对禁止

很遗憾的就是客户设置的就是 ~all 导致邮箱伪造发信人通过。

后来测试已经-all。

img 1765777674790 e49278

另外一种绕过可能:#

我们域名早在八百年前就配了 SPF v=spf1 ... -all,硬拒绝策略!稳得很。

真的如此吗?

虽然 -all 防御了直接的 SPF 欺骗,但作为安全工程师,你必须知道单纯的 SPF -all 依然存在被绕过的可能,这就是为什么还需要 DMARC

绕过场景(Header From 欺骗): 如果攻击者稍微聪明一点,使用以下配置发送邮件:

  • Envelope From (信封发件人/Return-Path) : attacker@evil-domain.com (攻击者自己的域名,且攻击者IP在 evil-domain.com 的 SPF 允许列表中 —— SPF 检查通过)
  • Header From (邮件头显示的发件人) : admin@baidu.com (你的域名)

结果:

  • 邮件接收方检查 Envelope From 的 SPF,结果是 PASS(因为查的是攻击者的域名)。
  • 用户在客户端里看到的却是 admin@baidu.com
  • 结论:如果没有配置 DMARC 来强制要求“Header From”和“Envelope From”保持一致,SPF -all 也无法防御这种“挂羊头卖狗肉”的欺骗。

在邮件协议这个古老的世界里,有时候“看大门的”和“前台接待”根本不是一伙人。

其实这也是很常见的一种邮件代发策略,简单扒一扒这个让绕过思路。


1. 邮件协议的“精神分裂”#

要理解这个漏洞,你得先知道一个冷知识:SMTP 协议是 40 多年前设计的。那个年代的互联网全是君子,大家互相信任,压根没考虑过有人会撒谎。

所以,SMTP 在设计上把“信封”和“信纸”完全分开了。

  • 信封上的发件人 (Envelope Sender) :这是给邮局(邮件服务器)看的,用来决定退信退给谁。
    • 技术黑话叫 MAIL FROM
  • 信纸上的落款 (Header From) :这是给收信人(你我)看的,显示在 outlook 或手机屏幕上。
    • 技术黑话叫 From

漏洞就在这儿: 现有的 SPF 检查,就像是一个看大门的保安。他非常尽职,但他只检查信封。 只要快递员(发送方服务器)拿的信封是合法的(比如我用网易账号发信,信封写的是网易,网易服务器当然认可),保安就放行了:“进去吧,没毛病。”

至于信封里面的信纸上,落款写的是“马化腾”还是“丁磊”,保安压根不看

这就是为什么我能绕过你的 SPF:

  • 我的信封:用我的网易账号 (XXXX@163.com) —— SPF 检查通过! (因为我确实拥有这个账号)
  • 我的信纸:写上你们公司 CEO 的名字 (admin@baidu.com) —— 用户被骗!

这就叫“挂羊头卖狗肉”。


2. 红队视角:花式绕过姿势#

其实,只要你没上 DMARC,你在红队眼里基本就是裸奔。除了上面这种最经典的“信头欺骗”,我们还有很多好玩的手段。

姿势一:“我帮朋友代发”#

当你用 Outlook 或者手机收邮件时,有时候会看到一行灰色小字:“由 xxx 代发”。 这是邮件客户端良心发现,看到了信封和信纸不一致,特意提醒你。

img 1765777674930 656059

这种提醒也可以通过注册相近域名自建SMTP解决。

姿势二:视觉欺骗#

如果你的防御真的滴水不漏(上了 DMARC p=reject),那我就不攻击你的域名了, 我去注册一个 baidu.com.cn(把中间的 i 换成 l)。 在手机那么小的屏幕上,加上紧张的工作节奏,有几个人能一眼看出来? 这种域名我自己注册的,SPF、DMARC 全套我都配齐,正规得不能再正规了,当然这是后话了。


3. 怎么修?#

别再迷信 SPF -all 了,他不完全起作用。

要想真正关上这扇门,你得凑齐邮件安全套:

  1. DKIM (防篡改) : 这就好比给信封加了个封泥。发信时服务器用私钥盖个章,收信时验证一下。这样别人就不能在中途偷偷改你的邮件内容了。
  2. DMARC (终极BOSS) : 这才是解决“信封信纸不一致”的唯一解药。 DMARC 就像是给保安下了一道死命令: “必须拆开信封检查!如果信纸上的落款跟信封对不上,直接把信给我撕了!”
    • 建议配置v=DMARC1; p=reject; aspf=s; adkim=s;
    • 注意:别上来就 Reject,不然你们公司的市场部发不出去邮件会来砍你。先开 p=none 观察几天,再慢慢收紧。

4. 总结一句#

邮件安全其实不难,难的是很多人还在用几十年前的老眼光看问题。 信任是脆弱的。 在这个零信任的时代,永远不要相信“发件人”那一行字,除非 DMARC 告诉你:它是真的。

提供一个我写的测试脚本:

有关SPF邮件信息伪造的内容
https://astro-pure.js.org/blog/spf-email-spoofing
本文作者 r3rk04·謊言無法穿透石灰水泥
发布于 2026年1月2日
版权声明 CC BY-NC-SA 4.0
Comment seems to stuck. Try to refresh?✨