协议

POP3 与 IMAP

“POP3即“Post Office Protocol - Version 3”,其作用是客户端连接服务器下载服务器中所有未阅读的邮件”

“当使用IMAP协议与邮件服务器交互的时候,你在客户端对邮件进行的操作都会同步到服务器上,所以IMAP也叫做交互式邮件存取协议”

如何发送一封邮件(SMTP)

在这一环节,我们以命令行发送邮件详细说一下,邮件发送的环节。

1.连接至邮箱服务器。
可以直接用telnet指定25端口进行链接

image-20210519161112531

服务器返回

image-20210519162457768

2.打开传输通道

通过helo或者ehlo指令,附带自己的个人信息 发送给邮件服务器。推荐使用ehlo。
这一步用于向服务器表明自己的身份

image-20210519162639005

3.身份认证

身份认证并不是必须的环节,不过这里是连接的163邮箱,发送邮件必须通过身份认证。
对于自建的邮件服务器,可以跳过这一环节。

对于163邮箱而言,需要提前开启smtp服务(不展开讲,教程网上一大堆)。

打开传输通道后,输入 auth login 然后输入你的163邮箱的base64编码,以及开启smtp服务后给你的授权码的base64编码,即可认证成功。

image-20210519170853252

4.指定发送者邮箱

这一步通过MAIL指令,指定接下来发送的邮件的发送者邮箱。这个邮箱往往不会在收件者的收信中显示,这里指定邮箱的目的是告诉邮箱服务器邮件发送地址。

image-20210519171147375

5.指定收件者邮箱

通过RCPT命令,指定接下来发送的邮箱的收件者邮箱,同样的,这里指定邮箱的目的是告诉邮箱服务器邮件的接收地址。

image-20210519171559686

6.邮件内容

输入DATA指令,开始编写邮件内容。

to:手动打码@qq.com  //在邮件中显示的收件人邮箱
from: hr@huawei.com //在邮件中显示的发件人邮箱
subject: hi //标题

test //正文

. //退出编辑

image-20210519171737634

收到后就是这样的

image-20210519171903282

从上面的操作我们可以看到,如果我们有自己的邮件服务器,那么我们可以可很轻而易举的伪造邮件的发件人(伪造mail from 与 data from),smtp本身并没有特别的校验机制,那么防护措施有哪些呢?

其实从上述操作后,我们已经对smtp协议有一个大致的认识了

image-20210520230716497

注,以下为方便叙述,往往把data里的from 叙述为 MESSAGE FROM

SPF

spf根本上 是一个dns记录类型(txt类型),它登记某个域名用来外发邮件的所有IP地址。

spf,即发送方策略框架。邮件服务器在接收邮件时若使用了SPF,那么它将会以下列步骤验证邮件是否可信。

1.检查所发来的邮件的域(HELO 或 MAIL FROM),并查询其SPF记录
2.将发送服务器的IP与SPF记录进行比对
3.若发送服务器IP存在于SPF记录,则比对成功,反之则比对失败。

我们可以看一下,qq的SPF规则

image-20210519205301040

SPF 的规则长这样 v=spf1 [[pre] type [ext] ] … [mod]

1.v=spf1  说明spf版本。

2.pre:定义匹配时的返回值。可能的返回值包括:
+:缺省值。在测试完成的时候表示通过。
-:表示测试失败。这个值通常是 -all,表示没有其他任何匹配发生。
~:表示软失败,通常表示测试没有完成。
?:表示不置可否。这个值也通常在测试没有完成的时候使用。

3.type:定义使用的确认测试的类型:
include:包含一个给定的域名的测试。以 include:domain 的形式书写。
all:终止测试序列。比如,如果选项是 -all,那么到达这条记录也就意味着测试失败了。但是如果无法确定,可以使用 ?all 来表示,这样,测试将被接受。
ip4:使用 IPv4 进行验证。这个可以以 ip4:ipv4 或 ip4:ipv4/cidr 的形式使用。
ip6: 和ip4异曲同工
a,mx:会命中相应域名的a记录或者mx记录中包含的IP地址(段)

4.ext:定义对 type 的可选扩展。如果没有这个字段,那么仅使用单个记录进行问询。

5.mod:这是最后的类型指示,作为记录的一个修正值。测试后有以下结果:
通过;SPF 记录指定要允许发送的主机;接受
硬失败;SPF 记录已将主机指定为不允许发送;拒绝
软失败;SPF 记录已将主机指定为不被允许发送但正在转换;接受但标记
中性;SPF 记录明确指出,对有效性无关;接受
没有;该域没有 SPF 记录,或者 SPF 记录不对结果进行评估;接受

对于qq的spf规则,就是只认ip段为mail.qq.com的a地址指向的IP段

DKIM

DKIM,即域名密钥识别邮件标准。它被设计来判断电子邮件发件人是否是伪造以及内容是否被篡改。

它的工作机理简要概括如下:

1.发送方在发送邮件时,生成一个公钥和一个私钥,并把公钥放到DNS上,使任何人可以通过域名来查询到公钥(如通过nslookup)
2.用私钥对邮件内容的正文以及头部(必须包括from)进行签名
3.将签名放置在邮件标头中,发送
4.收件方收到邮件后,根据标头中的信息去获得公钥,若公私钥匹配,则dkim验证通过。

这里再说一下,签名的结构。

image-20210520132708241

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
有些时候也会有b字段,b字段包括h中给出的字段以及bh

那么收件方收到邮件后怎么通过签名标头去获取公钥呢?这里就用到s这个字段的值了。
如下图,就是通过nslookup s指定的值+_domainkey.+d指定的值获得公钥。

image-20210520140402067

DMARC

全称Domain-based Message Authentication, Reporting and Conformance

设计初衷:解决用户收件时往往只能看到DATA信息块中所填写的发件人,而DATA信息块中的发件人信息是可以伪造的,攻击者可以利用此点进行网络钓鱼。
大致:DMARC构建在SPF和DKIM技术之上(甚至可以说是SPF和DKIM的有机结合),结合SPF和DKIM技术对邮件进行校验,对于未通过校验的邮件则需按照发件方(指被仿冒的发件方,即正规的机构)指定的策略进行的处理,如拒收以及投入垃圾箱,从而避免伪造的钓鱼邮件进入用户邮箱。
另外,DMARC还引入了对齐机制对保证SPF与DKIM校验的域名与MESSAGE FROM 的两个地址是可以“对齐匹配”的,从而保证用户看到的来源地址真实可信。

对齐方式有两种,严格模式与宽松模式。

严格模式:

对于SPF:MAILFROM(或HELO)必须与MESSAGE FROM指定的域完全一致
对于DKIM:DKIM标识符(d=xxx.com)必须与MESSAGE FROM 指定的域完全一致

宽松模式:

对于SPF:MAILFROM(或HELO)必须与MESSAGE FROM指定的域主域名一致即可
对于DKIM:DKIM标识符(d=xxx.com)必须与MESSAGE FROM 指定的域主域名一致即可

绕过

1.当SPF被设置有~all时 即设置了软失败,软失败往往不会使用强制措施让邮件进入垃圾箱或者拒收,而且在某些邮箱系统里即使软失败邮件也会照常接收(如在稍早一段时间,outlook会接收软失败邮件)

2.SPF IP段过大 ,若IP段过大,则会导致IP范围超出了业务范围,我们只要获取IP段内任意一台主机的控制权即可进行SPF Bypass。

3.SPF报错,若SPF在设置时就出现了语法错误,如

v=spf1 ip4:11.111.11.0/24 3.1.226.0/24 -all

可见SPF中指定了是ipv4,但是又采用了非ipv4的IP,导致整个SPF报错而直接失效。

4.利用子域名未配置SPF,
首先我们需要知道的一个前提是,DMARC检验SPF时默认是通过MAILFROM去查询SPF记录的。
但是如果我们在MAILFROM处填写的是所仿冒域的子域名,且恰好这个子域名没有配置SPF,且DMARC启用的是宽松模式,那么SPF也就被顺利绕过了。 就像下面一样

.....
MAIL FROM: anything@xxxxx.apple.com //该子域名未配置SPF,当DMARK校验此域名时SPF记录为空,自然会把该域名当作可信来源。
.....
MESSAGE.FROM: admin@apple.com

5.利用SPF与DMARC组件差异性,(感觉太刁钻了),这个利用条件是利用SPF组件与DMARK组件的差异性。
①利用默认校验的头部不同Bypass
我们钓鱼邮件长这样

HELO:ATTCKER.COM
MAIL FROM: any@apple.com
....
MESSAGE.FROM: ADMIN@apple.com

SPF组件默认对HELO中指定的域名进行SPF校验,由于我们HELO中指定的是我们自己的恶意域名,其SPF记录被置空或者攻击者已将自己发件服务器的IP写入到SPF记录里,从而SPF通过

DMARC 组件默认对MAIL FROM进行对齐校验,显然对其校验会通过。

②利用对注释的判定不同Bypass
我们的钓鱼邮件长这样

....
MAIL FROM: any@apple.com(.attack.com
....
MESSAGE.FROM: admin@apple.com

SPF组件检验MAIL FROM时,校验的域名是apple.com(.attack.com,由于这个域名是属于attack.com(也就是我们的域名)旗下的,所以我们对其可控,可控制其spf记录来使SPF校验通过

DMARC组件校验对齐时,视(及以后内容为注释符,将apple.com与apple.com进行对齐校验,通过。
对于注释符,不仅有(,还有@

6.多个MAIL FROM,虽然在RFC 5322中说明过一个邮件消息必须有一个Message.From,同样存在多个Message.From无效并且会被拒绝。但是实际状况并不如此,以下是几个例子

(a) iCloud.com (Web) 在面对多Message.From的情况时,DMARC会验证其第一个Message.From并且给客户端展示的是最后一个Message.From

(b) Mail.ru的邮件服务器会拒接多个Message.From的情况,但是可以使用堆叠的空格可以进行绕过。随后其DMARC可以识别第一个Message.From来进行校验并在Outlook (Windows) 上展现正确格式的第二个Message.From给客户端用户

(c) Fastmail.com的邮件服务器和Fastmail.com (Web) 无法成功识别空格,DMARC会校验格式正确的第一个Message.From,但Fastmail.com的邮件服务器在转发给Fastmail.com (Web) 客户端时除去了空格,并展示给用户的是最后一个Message.From

7.Sender头+MAIL FRON置空,Sender头是用于标记代发者的一个头,在一些邮件服务器中,会对MAIL FROM指定的域名进行SPF 与 DKIM校验,但如果MAIL FROM 置空,这些校验会通过。然后将Sender头中指定的邮箱地址显示在用户的页面

ref:https://www.anquanke.com/post/id/218889
https://bbs.ichunqiu.com/thread-55388-1-1.html
https://www.cnblogs.com/xiaozi/p/12906040.html