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

黑客资讯hacker2020-08-28 8:08:2218662A⁺A^-

本文讲述了作者通过Gsuite邮件发送功能，可构造后缀为@google.com的任意发件人身份，实现SMTP注入，漏洞获得了谷歌$3133.7的奖励。

Gsuite是谷歌旗下的一款整合协同办公软件，它可以用来管理组织机构内部账户，允许管理员对内部账户进行权限划分、应用程序访问控制、通讯录查看以及邮件头应用等操作。

其中，Gsuite的邮件头应用功能引起了我的兴趣，如今的电子邮件头中包含了一些可以“利用”的SMTP协议信息，它算是一种古老的通信协议了，几乎每个接触互联网的人都会使用到它。这里的“利用”指的是我们可以从中发现一些有用信息，从而做一些尝试性的欺骗测试。谷歌这种大厂其实也难免犯错，这不，我就发现了Gsuite的邮件配置存在漏洞，攻击者可以利用该漏洞伪造谷歌服务器的发送邮件。

SMTP协议背景

本质上来说，如果可以建立连接到某个SMTP服务器的接口，就能按相应步骤向任意邮件地址发送电子邮件了，这里更重要的是，可以以任意发件人身份进行邮件发送。所以，这种情况下会引发一系列的混乱问题，因为作为收件人来说，他邮件内的发件人身份完全是不可信的。

通常，我们可以从以下几条简单的SMTP命令来了解SMTP协议：

1、‘MAIL FROM’: 发件人身份（发件人邮箱地址），再强调一下, 这里可以是任意地址，如queen@yesIReallyAmTheQueen.com；2、‘RCPT TO’: 收件人邮箱地址；3、‘DATA’: 邮件内容。

就这些，没有cc（转发），没有bcc（私密发送）和subject（主题）等头信息，它们都是后续的内容了。那现在如何来利用呢？我们可以把一些额外的头信息放到上述的邮件内容字段（DATA）里，比如，在DATA的开头部分中加入任意的头信息，只要发件人和收件人可以解析理解都行，按RFC定义来讲，每个头信息都新占一行，头名（header）和值之间以冒号分隔。如以下简单的例子：

SMTP FROM:
admin@google.com
SMTP TO:
Victim@gmail.com
DATA:
bcc: attacker@gmail.com

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下，就能在其中添加进出邮件的“邮件路由设置”规则，其中一个可选项就是为所有邮件配置一条“自定义头”:基于上述的测试构想，我们可以假设其所谓的“自定义头”是添加到SMTP协议的‘DATA’内容中去的，所以，如果能在其中添加进任意头信息，那么也就能操控邮件内容了。

然而，实际情况并非如此，Gsuite中的自定义头有一个“X-”前导，因此貌似我们不能完全控制头名称，但是，等等！前面我们说过，按照RFC规则惯例，每个头信息都是新占一行的。如果我们可以插入一个新行作为头名称的下一个部份呢？那么下一行到底是新的头，还是我们可以控制的呢？

然而，经测试证明，这种方法不可行。谷歌不允许在头信息中包含换行符。但是，我又注意到一个地方，那就是在“自定义头”的下方存在一个选项：Prepend custom subject，即为每封邮件添加“自定义主题”的选项。前述我们说过，SMTP中并不包含‘subject’ 这一项，它只是‘DATA’内容中的一个头信息。

为此，来看看这个“自定义主题”能否作为利用点。发送邮件时，打开代理工具，往其中的‘subject’中插入新行 (‘\r\n’)，抓包看流量：

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

惊到我了！也就是说我们构造的Payload成功了，其中插入的Payload字符：we\r\nnewlinew\r\nnewlinell，被谷歌邮件服务端解析成了多行了！由于每一个头信息占一行，所以subject之后的Payload：we\r\nnewlinew\r\nnewlinell被推到了后续显示，成为了这里的邮件内容（email body）。这就是一种典型的SMTP注入啊！

接下来，我构造了一个更有意思的Payload，再次对其中的subject设置做了手脚，这一次，我包含进行了邮件发件人的from头信息，即：