关于邮件伪造的一些新思路

  • A+
所属分类:安全闲碎

关于邮件伪造的一些新思路

起因:

由于工作的原因,我们需要不定期对公司内部的设备及人员发起攻击,但是常规的WEB攻击或者系统服务攻击,并不能完整的模拟出外部的威胁。所以在这段时间,我们也就研究了一下邮件伪造技术。(当然本文中的伪造肯定不同于常规的伪造)。


在讨论邮件伪造的主题之前,我们先来简单了解一下这几个协议(POP3,IMAP,SMTP)与SPF。

1.POP3:


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

2.IMAP:

IMAP即“Internet Mail Access Protocol”,它不同于POP3,POP3协议并不会将客户端对邮件进行的操作同步至服务器。当使用IMAP协议与邮件服务器交互的时候,你在客户端对邮件进行的操作都会同步到服务器上,所以IMAP也叫做交互式邮件存取协议。

3.SMTP

SMTP协议即“Simple Mail Transfer Protocol”简单邮件传输协议。它是用于从源地址到目标地址传输邮件的规范。通过该协议来控制邮件的中转。而我们常用的邮件供应商所提供的邮件服务基本都是采用的SMTP协议进行传输。
SMTP协议同时也要求了客户端连接服务器需要进行认证(如果允许匿名登录那就另当别论了)。但是它也仅仅只要求了客户端需要与服务端进行认证。而SMTP服务器之间传输邮件的过程是不需要进行认证的。这也就是邮件伪造的关键点所在。

4.SPF

SPF即“Sender Policy Framework”是一种以IP地址认证电子邮件发件人身份的技术。接收邮件方会首先检查域名的SPF记录,来确定发件人的IP地址是否被包含在SPF记录里面,如果在,就认为是一封正确的邮件,否则会认为是一封伪造的邮件进行退回。


SPF可以防止别人伪造你来发邮件,是一个反伪造性邮件的解决方案。当你定义了你域名的SPF记录之后, 接收邮件方会根据你的SPF记录来确定连接过来的IP地址是否被包含在SPF记录里面,如果在,则认为是一封正确的邮件,否则则认为是一封伪造的邮件。

传统的邮件伪造

当我们在进行邮件伪造的时候,一般都会去查询对应域名的SPF记录,如下腾讯便使用了SPF技术:


关于邮件伪造的一些新思路


基本上现在很难有看到没有使用SPF的大厂域名了。当我们伪造邮件的时候。如果域名有设置SPF,那么我们基本就很难进行传统的伪造了。

但是优良传统不能忘,这里我还是得举个使用Swaks进行邮件伪造的例子。(公司内部邮箱)
关于Swaks的具体用法请自行百度。毕竟它不是本文的关键。


关于邮件伪造的一些新思路


这里我已经收到了邮件,但是其在邮件中提示了SPF Failed,这就是虽然我们公司做了SPF,但是其规则存在问题,所以会出现拦截失败的状况。但是这种拦截失败的提示对于财务,人力等非技术人员来说可能并不会注意,但是对于技术人员来说当收到这种邮件的时候,肯定会起疑。所以我们在进行钓鱼工作的时候,可以有针对性的对特定目标进行钓鱼。


关于邮件伪造的一些新思路


非传统性邮件伪造(基于客户端漏洞的伪造),以腾讯邮箱为例

首先,我们知道,腾讯邮箱是做了SPF策略的。当我们使用Swaks去伪造管理员用户的时候,是无法伪造成功的。如下,550错误。


关于邮件伪造的一些新思路


但是这样我们是否就无法进行伪造了?当然可以继续伪造,不过我们需要使用的方法不同而已。
首先我们需要知道,SMTP协议发送邮件的时候,是使用Mail From来指定发件人,但同时需要我们知道的还有一点即(发件人别名),这个是我们可以自定义的,那么这个时候我们来大胆猜测一下。发件人别名有什么用?而邮件客户端是如何去对它进行处理的。因此我对QQ邮箱进行了FUZZ测试。测试结果如下图所示:


关于邮件伪造的一些新思路


关于邮件伪造的一些新思路


可以看到我收到了以[email protected]为发件人发送的邮件。这个时候我在给你们看看邮件原文,你们应该就知道这是为什么了。


关于邮件伪造的一些新思路


其实就是我通过修改“发件人别名”在其中填充大量的特殊字符,从而使邮箱客户端截取实际发件人失败,导致实际显示效果为我们伪造的邮箱及发件人。


以下为发件人别名payload,当然也可以自己写个SMTP脚本进行测试。脚本我已经写好了,但是敏感时期就不发了。大家可以使用outlook进行测试。

管理员 <admin@qq.com>                                         


关于邮件伪造的一些新思路


最后

经过测试,并非只有腾讯邮箱存在这样的问题,各个邮件厂商都或多或少的存在问题,同时我也将这个问题提交给了腾讯SRC,但是他们的回复是这是符合RFC标准和协议的伪造场景。SO,我也就没什么好说的了。但好在这次研究中也发现了一些Outlook与Exchange的问题。


最后放上一张图,不知道这算不算邮件伪造成功或者伪造漏洞?


关于邮件伪造的一些新思路


最后最后:

祝您们新年快乐,越来越好,祝各位大表哥天天挖0day,厂商不忽略!


关于邮件伪造的一些新思路

最重要的事

以上相关利用点,仅可用作研究,或公司内部任务,请勿用于非法用途,望周知。


关于邮件伪造的一些新思路


本文始发于微信公众号(疯猫网络):关于邮件伪造的一些新思路

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: