邮件伪造系列

 

0x00 SMTP 协议介绍

SMTP协议:全称为 Simple Mail Transfer Protocol,简单邮件传输协议。是属于应用层协议,基于TCP收发邮件。 它定义了邮件客户端软件和SMTP邮件服务器之间,以及两台SMTP邮件服务器之间的通信规则。SMTP协议的通信双方采用一问一答的命令/响应形式进行对话,SMTP协议分为标准SMTP协议和扩展SMTP协议,标准SMTP协议是1982年在RFC821 文档中定义的,而扩展SMTP协议是1995年在RFC1869 文档中定义的。扩展SMTP协议在标准 SMTP协议基础上的改动非常小,主要增加了邮件安全方面的认证功能,现在我们说的SMTP协议基本上都是扩展SMTP协议,下面会介绍相关的安全协议。

SMTP 服务器一般会开启 25 端口提供服务, 当然如果 smtp 服务器使用了安全认证也就是 ssl/tls, 那么就会开放 465 或 587 端口。

SMTP 协议中一共定义了18条命令,但是发送一封电子邮件的过程通常只需要6条命令:

一般SMTP协议的发送流程如下:

  1. 建立TCP连接,也就是喝SMTP服务器建立连接。
  2. 客户端发送HELO或者EHLO命令以标识发件人自己的身份,服务器返回250 OK或者更详细一点的信息。
  3. 选择登录认证方式,一般我们在第二步执行完后,会提示有几种认证方式,我们一般选择的是login。即输入命令:auth login,进行登陆认证。(这里的认证需要输入base64编码后的用户名以及密码。)
  4. 客户端发送MAIL命令,表面发送者邮箱地址,服务器端以OK作为响应,表示愿意接收邮件。
  5. 客户端发送RCPT命令,表明接收人邮箱地址,可以有多个RCPT行,服务器端以OK作为响应,表示愿意为收件人接收邮件。
  6. 协商结束,发送邮件,用命令DATA发送,服务端会返回邮件发送成功与否的情况。

下图为手工使用SMTP协议来发送一个邮件,对应上述流程,如图(之前测试公司邮箱服务器的图片,凑合看吧..):joy_cat:

0x01 SMTP 相关身份验证安全协议介绍

  • SPF
  • DKIM
  • DMARC

1.SPF-发件人策略框架

发件人策略框架(Sender Policy Framework, SPF)是一种以IP地址认证电子邮件发件人身份的检测电子邮件欺诈的技术, 是非常高效的垃圾邮件解决方案。SPF阻止垃圾邮件发件人发送假冒本网域中的“发件人”地址的电子邮件, 收件人通过检查域名的SPF记录来确定号称来自该网域的邮件是否来自授权的邮件服务器。 当SRF未设置或者配置不当,就会导致一些邮件伪造的问题,详情请看下面:

简单来说,当你定义了你域名的SPF记录之后,邮件接收方的收件服务器在接受到邮件后,去核实邮箱源IP地址然后匹配它的dns中txt记录的SPF信息,如果在,就认为是一封正确的邮件,如果没有查找到,那就邮件的来源有问题。这时候一般邮箱接收端就会有三种处理方式:

png

  1. 直接拒绝或者删除
  2. 认为是垃圾
  3. 正常到收件箱,但是邮件会有?等警告,告诉收件者无法验证邮件的真实身份

SPN一般的定义格式如下:

"v=spf1 mx ip4:61.0.2.0/24 ~all"

Ex: 我们进行查看 ven***ech这个网站的SPF记录

~  nslookup -type=txt ven***ech.com.cn
Server:		114.114.114.114
Address:	114.114.114.114#53

Non-authoritative answer:
ven***ech.com.cn	text = "v=spf1 a mx ip4:106.39.10.184 ~all"

Authoritative answers can be found from:

这一行就是他的SPF记录:

ven***ech.com.cn	text = "v=spf1 a mx ip4:106.39.10.184 ~all"

v=spf1

这说明这是 SPF 第一版,必填。

a

匹配主机名或域名。

mx

引入这个域名上的 MX 记录。

ip4:106.39.10.184

引入这个 IPv4 的地址段

~

为一个限定词,相应的还有(-,+,?),~代表软拒绝,邮件可被接受,也可被标记为垃圾邮件

all

此项用来处理上面没有做过处理的的 IP 地址。可选。不用来发邮件的域名可以用 -all 来处理。建议在测试期使用 ~all,正式上线后使用 -all

理解 “all” 在SPF中的设置

参数 结果 含义
+all pass Permits all the email, like have nothing configured.(允许所有邮件,相当于未设置)
-all fail Will only mark the email like pass if the source Email Server fits exactly, IP, MX, etc. with the SPF entry.(仅通过匹配spf中正确配置IP、MX、etc.)
~all softfail Allows to send the email, and if something is wrong will mark it like softfail.(有错误的标识为软失败)
?all neutral Without policy(策略之外)

其他定义的规则不再多说,请参考:如何设置域名的 SPF 记录

网站http://tools.wordtothewise.com/spf还可以检查SPF是否配置正确。

2.DKIM-域名密钥识别邮件标准

DKIM 域名密钥识别邮件标准(Domain Keys Identified Mail)是一种通过检查来自某域签名的邮件标头来判断消息是否存在欺骗或篡改的检测电子邮件欺诈技术。

DKIM 是利用加密签名和验证的原理, 在发件人发送邮件时候, 将与域名相关的私钥加密的签名字段插入到消息头, 收件人收到邮件后通过DNS检索发件人的公钥(DNS TXT记录), 就可以对签名进行验证(这里使用私钥加密的原因自己想吧), 判断发件人地址及消息的真实性. 需要注意的是, DKIM 只能验证发件人地址来源的真伪, 无法辨识邮件内容的真实性

同时, 如果接收到无效或缺少加密签名的消息, DKIM 无法指定收件人采取什么措施. 此外, 私钥签名是对本域所有外发邮件进行普遍的签名, 是邮件中继服务器对邮件进行 DKIM 签名而不是真正的邮件发送人, 这意味着, DKIM 并不提供真正的端对端的电子签名认证。

使用 DKIM 发送的电子邮件包括一个 DKIM-Signature 标头字段,接收方收邮件时,通过DNS 查询获得公钥,验证邮件DKIM签名的有效性,从而确认在邮件发送的过程中,防止邮件被篡改,其实就是非对称的端对端加密,只不过我们把公钥暴露在域名的 DNS TXT记录中,接收邮件的提供商可以在公网上查到。 下面这张图可以解释这个过程:

png

如果成功接收到设置了DKIM的邮件的话,在邮箱中,我们以一个Amazon发的邮件为例子,查看原始邮件,会发现在DKIM一栏,会出现PASS(如果没有验证通过为FAIL):

DA8A2091-D8A7-4C24-8A4D-CD34A49BFF65

DKIM-Signature字段解读:

查看DKIM-Signature字段,发

8E038B13-46A6-48ED-9B07-1347946EA4A7

我们就以上面的标头为例子,解释关键的字段。

v=1,版本

a=rsa-sha256,使用rsa-sha256算法

q=dns/txt,使用DNS TXT记录分发密钥

c=relaxed/simple,标准化方法,另一种为relaxed

s=*,域名的selector(自定义),通过这个selector,用于查询public key

d=*,发送者的域名

t=*,时间戳

h=*,header签名包括字段

bh=*,body hash,即内容的hash(sha256)后再base64

上面的截图中,给定DKIM签名字段 d=amazon.com,s=caxb2jsezaooh2mhsm6hpe5cix6kfyez,DNS查询为:caxb2jsezaooh2mhsm6hpe5cix6kfyez._domainkey.amazon.com 。(所有 DKIM 密钥存储在一个子域,命名为_domainkey)

通过nslookup也可以看到:

image-20200723211338024

3.DMARC-以域名为基础的邮件认证、报告和一致性标准

SPF 和 DKIM 中共同存在的问题是缺少有效的策略和反馈机制, 这两个协议并未定义如何处理来自声称为某域的未经身份验证的电子邮件, 如何处理第三方声称托管的某域的未经身份验证的邮件, 如何反馈和统计声称是某域的身份认证成功或失败的电子邮件。

DMARC 以域名为基础的邮件认证、报告和一致性标准(Domain-based Message Authentication, Reporting, and Conformance) 就是用来解决 SPF 和 DKIM 中存在的这些问题, 邮件收发双方建立了邮件反馈机制,便于邮件发送方和邮件接收方共同对域名的管理进行完善和监督。对于未通过前述检查的邮件,接收方则按照发送方指定的策略进行处理。DMARC 的主要用途在于设置“策略”, 这个策略包含接收到来自某个域未通过身份验证的邮件时应执行什么操作、该域授权的第三方提供商发送了未经身份验证的邮件时该如何处理. DMARC 还会让 ISP 发送有关某个域身份验证成功或失败的报告, 这些报告将发送至“rua”(汇总报告)和“ruf”(取证报告)中定义的地址中. 同时, DMARC 依靠出站邮件流配置的 SPF 记录和 DKIM 密钥来确保邮件来源及签名的完整性, 当未通过 SPF 或 DKIM 检查的邮件时便会触发 DMARC 策略。

下面这张图可以说明这个过程:

png

DMARC 常用参数:

还是以上面的Amazon邮件为例子,可以看到正常采用了DMARC的成功发送到邮箱的邮件,也会出现PASS。

DA8A2091-D8A7-4C24-8A4D-CD34A49BFF65

从原始邮件中,截取相关字段为:

dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amazon.com

p,要求的邮件接收者策略(纯文本;必要的)表明接收者根据域名所有者的要求制定的策略

  • none,域名所有者要求不采取特定措施
  • quarantine,域名所有者希望邮件接收者将 DMARC 验证失败的邮件标记为可疑的
  • reject,域名所有者希望邮件接收者将 DMARC 验证失败的邮件拒绝

sp,要求邮件接收者对所有子域使用的策略(纯文本;可选的),若缺省,则“p”指定的策略将应用到该域名和子域中

dis=none (disposition=none) ,代表Gmail使用”none”策略

要查看你的 SPF 和 DKIM 是否有遵守 DMARC, 可以通过nslookup来查看:

~  nslookup -type=txt _dmarc.amazon.com
Server:		114.114.114.114
Address:	114.114.114.114#53

Non-authoritative answer:
_dmarc.amazon.com	text = "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@bounces.amazon.com; ruf=mailto:dmarc-reports@bounces.amazon.com"

Authoritative answers can be found from:

v,版本(纯文本;必要的)值为“DMARC1”,必须作为第一个标签

pct,(纯文本0-100的整型;可选的,默认为100)域名所有者邮件流中应用DMARC策略的消息百分比

rua,发送综合反馈的邮件地址(逗号分隔的 DMARC URI纯文本列表;可选的)

ruf,发送消息详细故障信息的邮件地址(逗号分隔的DMARC URI纯文本列表;可选的)

结合上面的一些参数,就可以理解一个网站配置DMARC具体的策略了。

0x02 SMTP 协议报文结构

在SMTP协议中,与HTTP协议相同,也有状态码的概念。如下表:

状态码 描述
211 System status, or system help reply
214 Help message
220 Service ready
221 Service closing transmission channel
250 Requested mail action okay, completed
251 User not local; will forward to
354 Start mail input; end with .
421 Service not available, closing transmission channel
450 Requested mail action not taken: mailbox unavailable
451 Requested action aborted: local error in processing
452 Requested action not taken: insufficient system storage
500 Syntax error, command unrecognized
501 Syntax error in parameters or arguments
502 Command not implemented
503 Bad sequence of commands
504 Command parameter not implemented
550 Requested action not taken: mailbox unavailable
551 User not local; please try
552 Requested mail action aborted: exceeded storage allocation
553 Requested action not taken: mailbox name not allowed
554 Transaction failed

SMTP协议的邮件对象由两个部分组成:信封和内容。如下面的网络图片:

这里写图片描述

SMTP报文的传输过程见下图:

这里写图片描述

看到这里,注意信封中有FROM,而信的内容中,也有FROM

2020-02-05-07-06-29

这个例子(图片来自倾旋大佬博客)就是,左右两个SMTP报文,发现信的内容中的FROM:*被更改了,这时候B@examle2.com收到的邮箱就显示P@example3.com发送的,这样一来,修改后的邮件会经过邮件网关的检查,并且符合邮件服务器配置的安全协议,最终到达邮件客户端。其中邮件客户端可以是浏览器、也可以是邮件客户端软件,一般情况下,邮件客户端是不具备邮件安全协议验证的,因此在客户端会解析成正常邮件。

但是这种伪造方式在配置了DMARC的邮件服务器上是存在问题的,具体结果和配置有关。

关于SMTP的东西就说到这里,更多信息请参阅:RFC 821

还有两个站点可以测试发送伪造邮件:

https://emkei.cz

http://tool.chacuo.net/mailanonymous

0x03 swaks工具介绍

Swaks(Swiss Army Knife for SMTP,SMTP瑞士军刀),多功能的SMTP协议测试工具,使用它我们可以灵活的操作SMTP协议报文,可以很方便的发送伪造邮件。

✘  ~  nslookup -type=txt caxb2jsezaooh2mhsm6hpe5cix6kfyez.domainkey.amazon.com Server: 114.114.114.114 Address: 114.114.114.114#53

** server can’t find caxb2jsezaooh2mhsm6hpe5cix6kfyez.domainkey.amazon.com: NXDOMAIN

✘  ~  nslookup -type=txt caxb2jsezaooh2mhsm6hpe5cix6kfyez._domainkey.amazon.com Server: 114.114.114.114 Address: 114.114.114.114#53

Non-authoritative answer: caxb2jsezaooh2mhsm6hpe5cix6kfyez._domainkey.amazon.com canonical name = caxb2jsezaooh2mhsm6hpe5cix6kfyez.dkim.amazonses.com. caxb2jsezaooh2mhsm6hpe5cix6kfyez.dkim.amazonses.com text = “p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXVaWZ7e6semn8JtnkiaYB4/zIKhMtvkABkSWUudJArRNYxWlHCoYJCBystgSBUz9vbwHEmkLhRRM0OFztasZxmusnZ8PyKicWLnbfSDwrgpJ0z1sxhsuxcydA7ve/P0U1T27Y4gprImv2Jh/QAiJVLvr9IUI0apai55uj3WPamwIDAQAB”

Authoritative answers can be found from:

~  ~  ~  nslookup -type=txt _dmarc.amazon.com Server: 114.114.114.114 Address: 114.114.114.114#53

Non-authoritative answer: _dmarc.amazon.com text = “v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@bounces.amazon.com; ruf=mailto:dmarc-reports@bounces.amazon.com”

Authoritative answers can be found from:

~  nslookup -type=txt _dmarc.163.com Server: 114.114.114.114 Address: 114.114.114.114#53

Non-authoritative answer: _dmarc.163.com text = “v=DMARC1; p=none;”

Authoritative answers can be found from: