上文链接

鉴别

上篇文章提到了发件人伪造，那么该如何鉴别发件人伪造

打开这封伪造的邮件的原始信息 在鉴别邮件是否伪造的最好的方法是查看其信头的Received字段

一封邮件的Received存在一个或多个，用于标识这封邮件从哪里发送过来并被邮件服务器所接收 ，通过邮件Received ，可以一定程度上看出这封邮件的路由情况

举个例子

以下为一封正常情况下的邮件 可以得知邮件先被投递至 我的邮箱（10.110.47.69）随后该邮件服务器将该邮件转发至  m13212.mail.163.com （ip：220.181.13.212）邮件服务器中

同样的 我们来看一封伪造的邮件 两个received中 一个为伪造的freebuf，但ip无法对应   另一个没有可信的smtp服务器域名 因此该邮件为一封伪造邮件

因此在辨别一封邮件时 就观察其Received中宣称身份是否与ip对应，不对应则为伪造 。

虽然Received头也可以被伪造，但Received中若包含大公司的smtp服务器，那一定是已经经过身份验证，邮件可信。

防御措施

目前为了防止邮件被伪造，有三种方法

SPF

SPF，全称为 Sender Policy Framework，即发件人策略框架。

我们查看huawei.com的spf设置情况

nslookup -type=txt huawei.com

spf是如何生效的呢？

当邮件服务器想将邮件投递至对方邮件服务器时，对方邮件服务器会检查发件人声明身份与SPF记录中的ip进行匹配验证，根据SPF设置内容来决定是否接收该邮件

如下图 为想以华为的身份发送一封邮件至目标邮箱时的SMTP日志记录 ，发送失败同时提示550MI：SPF ， 表示未通过SPF验证

SPF 记录包含在一个 TXT 记录之中，格式如下：

v=spf1 [[pre] type [ext] ] ... [mod]

每个参数的含义如下表所示：

• #### 举些例子

下图为华为的spf结构

huawei.com      text =
 "v=spf1 ip4:45.249.212.32 ip4:45.249.212.35 ip4:45.249.212.255 
ip4:45.249.212.187/29 ip4:45.249.212.191 ip4:168.195.93.47 
ip4:103.69.140.247 ip4:185.176.79.56 ip4:119.8.179.247 -all"

含义就是仅允许以上的ip以huawei.com的身份发送邮件，尾部的 -all 表示硬失败会直接像上文一样出现550MI：SPF

有时也会遇到尾部为~all的情况 表示为软失败  这种情况下 是否接收邮件取决于厂商，不过大部分厂商都选择放行，如图  以苹果的域名发送邮件

虽然收到邮件却被丢到了垃圾箱

如图为苹果子域名spf情况   redirect表示该域名的spf策略被重定向至spf.apple.com

提供一个spf自查网站，检测自己网站的spf是否配置生效

https://www.kitterman.com/spf/validate.html

DKIM

DKIM让企业可以把加密签名插入到发送的电子邮件中，然后把该签名与域名关联起来。签名随电子邮件一起传送，而不管是沿着网络上的哪条路径传送，电子邮件收件人则可以使用签名来证实邮件确实来自该企业。

DKIM 的基本工作原理同样是基于传统的密钥认证方式，他会产生两组钥匙，公钥(public key)和私钥(private key)，公钥将会存放在 DNS 中，而私钥会存放在寄信服务器中。数字签名会自动产生，并依附在邮件头中，发送到寄信者的服务器里。公钥则放在DNS服务器上，供自动获得。收信的服务器，将会收到夹带在邮件头中的签名和在DNS上自己获取公钥，然后进行比对，比较寄信者的域名是否合法，如果不合法，则判定为垃圾邮件。由于数字签名是无法仿造的，因此这项技术对于伪造域名的垃圾邮件制造者将是一次致命的打击，他们很难再像过去一样，通过盗用发件人姓名、改变附件属性等小伎俩达到目的。在此之前，垃圾邮件制造者通过把文本转换为图像等方式逃避邮件过滤，并且使得一度逐渐下降的垃圾邮件数目再度抬头。

关于其具体实现方式与绕过方式可以参考这位代佬的文章

https://zhuanlan.zhihu.com/p/29965126

DMARC

在上篇文章 我们以telnet的方式发送邮件时，可以注意到我们设置了两个From

第一个Mail from为Smtp.From,第二个位于邮件内容中的from 为Message.From

以上的两种框架，spf仅仅能校验Smtp.from的真实性，而第二种框架DKIM保证邮件内容没有被篡改。而用户在收取邮件时，只能看到Message.From字段，则可能被伪造的该字段所欺骗。于是产生了DMARC策略。目的就是将Message.from字段与已经通过SPF/DKIM再次进行匹配

p：用于告知收件方，当检测到某邮件存在伪造发件人的情况，收件方要做出什么处理，reject为拒绝该邮件；none为不作任何处理；quarantine为将邮件标记为垃圾邮件。
ruf：用于当检测到伪造邮件，收件方须将检测结果发送到哪个邮箱地址。

小技巧

1、针对手机用户可以直接修改自己的昵称 但是点击详情就可以看到真实邮箱 伪装性不强

2、在部分主域名已经设置spf的情况下可以讲目光放在其子域名下

例如 如果仅仅主域名设置了spf，但子域名未进行设置，我们还是可以以子域名身份发送邮件

如图为 华为子域名未设置spf导致可以伪造邮件

针对于不存在的子域名 若使用其发送邮件 会被直接送到垃圾箱中

如图仍是华为

苹果将所有的子域名无论存在与否， 都设置了spf，可能是因为刷机黑产

3、当SMTP.from与Message.from不一致时，会显示代发

如图，SMTP.from为test@test.com但Message.from设置为了我的qq邮箱

可以看到虽然在发件人处显示为Message.from邮箱 但会提示代发，并且邮件会进入垃圾箱

但值得一提的是 在手机端查看该邮件不会有代发字样

那利用以上两个特性，来一发组合技

找到未设置spf的子域名+伪造message.from  、

便可以完成  腾讯子域名代发腾讯邮件的情况

（虽然可惜仍然是出现在了垃圾箱中）

4、利用IDN域名

IDN（Internationalized domain name, IDN）是指在域名中包含至少一个特殊语言字母的域名，特殊语言包括中文、法文、拉丁文等。在DNS系统工作中，这种域名会被编码成ASCII字符串，并通过Punycode进行翻译。

Punycode是一个根据RFC 3492标准而制定的编码系统,主要用于把域名从地方语言所采用的Unicode编码转换成为可用于DNS系统的编码。

浏览器里面会自动对IDN域名进行Punycode转码，而地址栏依旧显示的是原始输入的IDN域名。

举个例子参考先知上的师傅的方法 如以下域名看似aliyun实际上时www.xn--lyun-43d3u.com

www.аlіyun.com

0x456 і
0x430 а

经punycode转码：www.xn--lyun-43d3u.com

将SMTP.from与message.from均设置为上述域名

结果均不成功，发现其后端逻辑为 ：当SMTP.from需要进行转码时，邮件服务器便会将该字段不予显示，同时提示原始地址存在特殊字符

但同样的在手机端，迷惑性极强，也不会进入垃圾箱中

punycode在线转换工具：http://tools.jb51.net/punycode/index.php

5.垃圾字符填充

这里作者想利用一个小特性，就是如果设置的Message.from不为邮箱格式，邮件服务器便会将Message.from解析至红框处,将SMTP.from解析至绿框处

因此作者想通过在message.from处填充大量垃圾字符,使得邮件服务器找不到SMTP.from从而不显示代发的情况

原作者使用替换Message.From头如下

From:=?gb2312?B?udzA7dSxIDxhZG1pbkBxcS5jb20+0aGhoaGhoaGhoaGhoaGhoaGhoaGhoQ==?=
=?gb2312?B?oaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGh?=
=?gb2312?B?oaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGh?=
=?gb2312?B?oaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGh?=
=?gb2312?B?oaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGh?=
=?gb2312?B?oaGhoaGhoaGhoaGhoaGhoaGhoaGhoSAgICAgICAgICAgICAgICAgIKGkoaQ=?=
=?gb2312?B?oaQgICAgICAgICAgICAgICAgIKGhICAgICAgIKGkoaShpA==?=   admin@qq.com

但是本地测试没有成功，猜测已经做了相应的处理

6.不同客户端解析

有文章提到若使用Foxmail不会显示代发，针对这种情况我也做了一个测试

刚好最近也有收到钓鱼邮件，就用这个钓鱼邮件做演示（顺带吐槽一下（  建）（）的信息泄露）

可以清晰的看到由某某代发，因此Foxmail会不显示代发的漏洞应该也已经被修复了

经过这段时间的研究，子域名未加spf还是可以作为主要的突破口来进行利用，同时手机端的防护明显弱于pc端。希望能为各位师傅在打站时提供一些思路

文章中如有纰漏，还希望各位师傅指正，同时也欢迎各位师傅讨论交流

参考链接

https://www.anquanke.com/post/id/218889#h2-0

https://xz.aliyun.com/t/6325/

https://www.freebuf.com/articles/web/227694.html

https://bbs.ichunqiu.com/thread-55388-1-1.html

https://www.freebuf.com/articles/network/264663.html