Gsuite邮件发送功能中的SMTP注入漏洞分析

本文讲述了作者通过Gsuite邮件发送功能,可构造后缀为@google.com的任意发件人身份,实现SMTP注入,漏洞获得了谷歌$3133.7的奖励。Gsuite是谷歌旗下的一款整合协同办公软件,它可以用来管理组织机构内部账户,允许管理员对内部账户进行权限划分、应用程序访问控制、通讯录查看以及邮件头应用等操作。其中,Gsuite的邮件头应用功能引起了我的兴趣,如今的电子邮件头中包含了一些可以“利用”的SMTP协议信息,它算是一种古老的通信协议了,几乎每个接触互联网的人都会使用到它。这里的“利用”指的是我们可以从中发现一些有用信息,从而做一些尝试性的欺骗测试。谷歌这种大厂其实也难免犯错,这不,我就发现了Gsuite的邮件配置存在漏洞,攻击者可以利用该漏洞伪造谷歌服务器的发送邮件。

SMTP协议背景

本质上来说,如果可以建立连接到某个SMTP服务器的接口,就能按相应步骤向任意邮件地址发送电子邮件了,这里更重要的是,可以以任意发件人身份进行邮件发送。所以,这种情况下会引发一系列的混乱问题,因为作为收件人来说,他邮件内的发件人身份完全是不可信的。通常,我们可以从以下几条简单的SMTP命令来了解SMTP协议:1、‘MAIL FROM’: 发件人身份(发件人邮箱地址),再强调一下, 这里可以是任意地址,如[email protected]
2、‘RCPT TO’: 收件人邮箱地址;
3、‘DATA’: 邮件内容。就这些,没有cc(转发),没有bcc(私密发送)和subject(主题)等头信息,它们都是后续的内容了。那现在如何来利用呢?我们可以把一些额外的头信息放到上述的邮件内容字段(DATA)里,比如,在DATA的开头部分中加入任意的头信息,只要发件人和收件人可以解析理解都行,按RFC定义来讲,每个头信息都新占一行,头名(header)和值之间以冒号分隔。如以下简单的例子:

SMTP FROM: [email protected] SMTP TO: [email protected] DATA: bcc: [email protected]  Send me all your money!!  .

伪造发件人身份

显然,如果上述问题得不到解决,且随着时间的推移,基于SMTP的身份和内容验证措施推出,那么电子邮件就不会是一个很好的交流工具了。在此,我们不展开讨论其安全机制。但是,我们要记住的是,在如今的邮件协议中,验证发件人身份的就仅只是“自称是谁就是谁”的DNS域名验证(DNS domain validation)。所以,如果我拥有‘google.com’网站,就可以设置一个域名服务记录,配置所有的SMTP服务器发自‘google.com’的邮件为安全可信邮件,其它发件都是垃圾邮件。也就是说,如果可以伪造(Spoof)谷歌服务器的发件,那么其可信度也就非常之高了。 

回到Gsuite

有了上述思路,我们就来测试一下Gsuite的邮件功能。如果你登录admin.google.com,转到Apps -> G Suite -> Settings for Gmail->Advanced settings->Routing下,就能在其中添加进出邮件的“邮件路由设置”规则,其中一个可选项就是为所有邮件配置一条“自定义头”:
Gsuite邮件发送功能中的SMTP注入漏洞分析
基于上述的测试构想,我们可以假设其所谓的“自定义头”是添加到SMTP协议的‘DATA’内容中去的,所以,如果能在其中添加进任意头信息,那么也就能操控邮件内容了。然而,实际情况并非如此,Gsuite中的自定义头有一个“X-”前导,因此貌似我们不能完全控制头名称,但是,等等!前面我们说过,按照RFC规则惯例,每个头信息都是新占一行的。如果我们可以插入一个新行作为头名称的下一个部份呢?那么下一行到底是新的头,还是我们可以控制的呢?然而,经测试证明,这种方法不可行。谷歌不允许在头信息中包含换行符。但是,我又注意到一个地方,那就是在“自定义头”的下方存在一个选项:Prepend custom subject,即为每封邮件添加“自定义主题”的选项。前述我们说过,SMTP中并不包含‘subject’ 这一项,它只是‘DATA’内容中的一个头信息。为此,来看看这个“自定义主题”能否作为利用点。发送邮件时,打开代理工具,往其中的‘subject’中插入新行 (‘rn’),抓包看流量:

Gsuite邮件发送功能中的SMTP注入漏洞分析

请求出去后,没返回任何错误提示!我立即向我的其它Gmail发送了一封测试邮件,然后从中收到的内容如下:

Gsuite邮件发送功能中的SMTP注入漏洞分析

惊到我了!也就是说我们构造的Payload成功了,其中插入的Payload字符:wernnewlinewrnnewlinell,被谷歌邮件服务端解析成了多行了!由于每一个头信息占一行,所以subject之后的Payload:wernnewlinewrnnewlinell被推到了后续显示,成为了这里的邮件内容(email body)。这就是一种典型的SMTP注入啊!接下来,我构造了一个更有意思的Payload,再次对其中的subject设置做了手脚,这一次,我包含进行了邮件发件人的from头信息,即:

Gsuite邮件发送功能中的SMTP注入漏洞分析

再一次成功了!Gmail把它解析成了发件人为[email protected]的邮件:

Gsuite邮件发送功能中的SMTP注入漏洞分析

就这样,我可以伪造任意后缀为@google.com的发件人身份!

漏洞上报和处理进程

2020.1.5    附带Payload报送谷歌
2020.1.13  谷歌接受漏洞
2020.1.15  我发送包含[email protected]的有效POC详细技术信息给谷歌
2020.2.11  谷歌发放赏金$3133.7

本文为转载文章,源自互联网,由网络整理整理编辑,转载请注明出处:https://www.hacksafe.net/articles/web/2747.html

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论