浅谈SPF配置不当导致的任意邮件伪造漏洞

1.1前提

最开始从其他师傅那里见到这个漏洞，参照一些师傅的博客学习了一下SPF记录的相关安全问题，今天来聊聊吧，首先要介绍一个协议和两个记录。

  • SMTP协议是简单的邮件传输协议，目前邮件还是使用这个协议通信，但是它本身并没有很好的安全措施。SMTP协议本身没有机制鉴别寄件人的真正身份，电子邮件的“寄件者”一栏可以填上任何名字，于是伪冒他人身份来网络钓鱼或寄出垃圾邮件便相当容易，而真正来源却不易追查。
  • MX记录用于指定负责处理发往收件人域名的邮件服务器。MX记录允许设置一个优先级，当多个邮件服务器可用时，会根据该值决定投递邮件的服务器（值越小优先级越高）。SMTP会根据MX记录的值来决定邮件的路由过程。
  • SPF记录的全称为 Sender Policy Framework，中文译作“发件人策略框架”，它是一套电子邮件认证机制，可以确认电子邮件确实是由网域授权的邮件服务器寄出，防止有人伪冒身份网络钓鱼或寄出垃圾电邮。SPF允许管理员设定一个DNS TXT记录或SPF记录设定发送邮件服务器的IP范围，如有任何邮件并非从上述指明授权的IP地址寄出，则很可能该邮件并非确实由真正的寄件者寄出。

 

这里做一个小总结：配置SPF记录的目的就是防止随意伪造发件人

 

1.2语法

查看一个域名的SPF记录命令：

nslookup -type=txt example.com //windows
dig -t txt example.com         //linux

 

SPF记录会结合“匹配机制”和“限定词”使用，它其实就是一条有特殊语法的TXT记录

匹配机制主要用于定义和指定可由该域名发送邮件的主机，其定义方式包括：

  • all 匹配任何主机，它写在SPF记录最后以匹配在其前面所列出的主机
  • ip4 匹配 IPv4 地址或网络范围
  • ip6 匹配 IPv6 地址或网络范围
  • a 匹配主机名或域名
  • mx 匹配域名的MX记录，当出站与入站邮件为同一服务器时通常采用此种机制
  • ptr 通过DNS反向记录来匹配发件人IP和域名，由于会增加DNS负载，一般不采用此种机制
  • exists 只检查域是否在DNS中存在
  • include 将发件人IP和SPF记录指向另一个域，这种匹配机制通常用于云服务，如 Exchange Online Protection

 

匹配机制会结合一些限定词来使用，以告诉服务器找到一条匹配记录时该怎么办。常见的限定词有：

  • + 放行，如果没有明确指定限定词，则为默认值
  • - 硬拒绝，直接拒绝来自未经授权主机的邮件
  • ~ 软拒绝，邮件可被接受，也可被标记为垃圾邮件
  • ? 中性，不考虑邮件是否被接受

 

一些实例（v=spf1 指采用SPF1版本，现在它的最新版本就是第 1 版）：

"v=spf1 -all" （拒绝所有，表示这个域名不会发出邮件）
"v=spf1 +all" （接受所有）
"v=spf1 ip4:192.168.0.1/16 -all"（只允许 192.168.0.1/16 范围内的IP发送邮件）
"v=spf1 mx -all"（允许当前域名的 mx 记录对应的IP地址发送邮件）
"v=spf1 mx mx:test.example.com -all"（允许当前域名和 test.example.com 的 mx 记录对应的IP地址发送邮件）
"v=spf1 a mx ip4:173.194.72.103 -all"（允许当前域名的 a 记录和 mx 记录和一个给定的IP地址发送邮件）
"v=spf1 include:example.com -all"（采用和 example.com 一样的SPF记录）

 

1.3绕过

SPF解析不当

  • 语法错误将导致SPF记录完全失效，https://www.kitterman.com/spf/validate.html 网站输入域名和SPF记录，可以检查SPF记录是否正确（SPF记录本质上是一个DNS记录，所以并不是修改之后立即生效的，通常需要几个小时的时间）
  • 允许IP段过大，只要攻击者拿下一台网段内的机器即可绕过
  • ~all 软拒绝，会接受来信，但可能被标记为垃圾邮件（outlook 邮箱可以接收邮件，qq 邮箱不接收，163 邮箱标记为垃圾邮件）SPF记录设置硬拒绝，就会有大量的邮件被丢弃或者隔离，影响办公效率，为了减少业务影响，有些管理员采用软拒绝的策略，但也会在一定程度上造成安全风险

SPF配置不当

  • 域名增加了SPF记录，但是邮件服务器不支持SPF检查或邮件网关未开启SPF检测，无法验证邮件来源。这种情况下，我们声明了自己是谁，但却无法验证对方是谁，SPF检测无效，可伪造任意用户发送到你的域名邮箱里
  • SPF解析在公网DNS，邮件服务器配置内部DNS，内部DNS无法进行SPF解析，从而导致绕过，可从公网伪造任意用户发送邮件
  • 攻击者在公司内网，内网SMTP服务器开启匿名邮件发送或者在信任服务器IP段，就可以使用任意用户发送邮件

高权限用户绕过

  • Exchange 邮箱系统，拥有 Domain admin 权限的域用户，可以通过 outlook 直接指定发件人，伪造任意发件人发送邮件并且邮件头不会显示真实IP，但是这条没有什么实际意义，已经拥有 Domain admin 权限就没必要进行邮件伪造了

邮件客户端内容解析差异

From 字段特殊字符填充绕过

 

1.4总结

上一小节只讲了前三点进行SPF绕过的原理，因为写这篇随笔的初衷是如何判断邮件服务器有无配置SPF，如果没有或配置不当的话可以直接使用 swaks 伪造邮件发送，思路偏向于防守和挖洞，而后两点则是运用一些技术实践任意邮件伪造漏洞，思路偏向于红队，接下来会再出一篇实操任意邮件伪造的思路。

 

 

参考文章：

http://www.renfei.org/blog/introduction-to-spf.html

https://zh.wikipedia.org/wiki/%E5%8F%91%E4%BB%B6%E4%BA%BA%E7%AD%96%E7%95%A5%E6%A1%86%E6%9E%B6#cite_note-3

https://www.cnblogs.com/xiaozi/p/12906040.html

https://blog.csdn.net/qq_36119192/article/details/106452010

https://anchorety.github.io/2020/10/18/%E9%82%AE%E4%BB%B6%E5%AE%89%E5%85%A8%E4%B9%8B%E5%8F%91%E4%BB%B6%E4%BA%BA%E4%BC%AA%E9%80%A0/

 

posted @ 2021-11-04 22:47  beiwo  阅读(3225)  评论(0)  编辑  收藏  举报