挖洞经验 | Gsuite邮件发送功能中的SMTP注入漏洞分析
字数 1219 2025-08-15 21:31:21

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

漏洞概述

本漏洞存在于Gsuite的邮件发送功能中,允许攻击者通过SMTP注入技术伪造@google.com域的发件人身份。该漏洞获得了谷歌$3133.7的漏洞奖励。

背景知识

SMTP协议基础

SMTP(简单邮件传输协议)是发送电子邮件的标准协议,主要包含以下基本命令:

  1. MAIL FROM: 指定发件人邮箱地址(可伪造)
  2. RCPT TO: 指定收件人邮箱地址
  3. DATA: 邮件内容部分

邮件头信息(如Subject、From、To、Cc等)都包含在DATA部分中,每个头信息占一行,格式为头名: 值

邮件身份验证机制

当前邮件系统主要依赖DNS域名验证(SPF、DKIM、DMARC)来验证发件人身份。如果能够伪造来自可信域(如@google.com)的邮件,将极大提高攻击成功率。

漏洞发现过程

Gsuite邮件功能分析

在Gsuite管理界面(admin.google.com)中,存在以下路径:

Apps -> G Suite -> Settings for Gmail -> Advanced settings -> Routing

其中包含两个关键功能:

  1. 自定义邮件头(自动添加"X-"前缀)
  2. 自定义邮件主题(Prepend custom subject)

初步测试

  1. 自定义邮件头测试

    • 尝试插入换行符控制后续内容 → 失败(谷歌过滤了换行符)
  2. 自定义主题测试

    • 在主题字段插入换行符(\r\n) → 成功注入
    • 示例Payload:we\r\nnewlinew\r\nnewlinell
    • 结果:换行符后的内容被解析为邮件正文

漏洞利用

构造特殊主题Payload:

任意主题\r\nFrom: admin@google.com\r\n其他头信息

效果:

  • 成功伪造来自admin@google.com的发件人身份
  • 可构造任意@google.com域的发件地址

技术原理

  1. SMTP注入本质

    • 通过注入换行符,将主题字段的剩余内容"推"到DATA部分
    • 服务端错误解析导致将注入内容视为新的邮件头
  2. 关键突破点

    • 自定义主题功能未正确过滤换行符
    • 邮件系统将注入内容误解析为合法邮件头

漏洞复现步骤

  1. 登录Gsuite管理后台
  2. 导航至邮件路由设置:
    Apps -> G Suite -> Settings for Gmail -> Advanced settings -> Routing
    
  3. 在"Prepend custom subject"字段输入Payload:
    Test Subject\r\nFrom: admin@google.com\r\n其他控制头
    
  4. 发送测试邮件
  5. 验证收件箱中显示的伪造发件人

防御措施

  1. 输入验证

    • 严格过滤用户输入中的特殊字符(特别是换行符)
    • 对邮件头字段实施白名单验证
  2. 输出编码

    • 对动态生成的邮件内容进行适当的编码
  3. 协议层面

    • 实施严格的SMTP命令解析
    • 分离邮件头与用户提供的内容
  4. 架构设计

    • 使用专门的邮件生成库而非字符串拼接
    • 实施内容安全策略

总结

该漏洞展示了即使像谷歌这样的技术巨头,在实现传统协议(SMTP)时也可能犯下看似简单的错误。关键在于:

  1. 理解协议底层实现
  2. 寻找用户输入与协议解析的交汇点
  3. 测试边界情况和特殊字符处理

此案例也凸显了电子邮件系统固有的安全弱点,强调了实施SPF、DKIM和DMARC等现代邮件认证机制的重要性。

Gsuite邮件发送功能中的SMTP注入漏洞分析教学文档 漏洞概述 本漏洞存在于Gsuite的邮件发送功能中,允许攻击者通过SMTP注入技术伪造 @google.com 域的发件人身份。该漏洞获得了谷歌$3133.7的漏洞奖励。 背景知识 SMTP协议基础 SMTP(简单邮件传输协议)是发送电子邮件的标准协议,主要包含以下基本命令: MAIL FROM : 指定发件人邮箱地址(可伪造) RCPT TO : 指定收件人邮箱地址 DATA : 邮件内容部分 邮件头信息(如Subject、From、To、Cc等)都包含在DATA部分中,每个头信息占一行,格式为 头名: 值 。 邮件身份验证机制 当前邮件系统主要依赖DNS域名验证(SPF、DKIM、DMARC)来验证发件人身份。如果能够伪造来自可信域(如 @google.com )的邮件,将极大提高攻击成功率。 漏洞发现过程 Gsuite邮件功能分析 在Gsuite管理界面( admin.google.com )中,存在以下路径: 其中包含两个关键功能: 自定义邮件头(自动添加"X-"前缀) 自定义邮件主题(Prepend custom subject) 初步测试 自定义邮件头测试 : 尝试插入换行符控制后续内容 → 失败(谷歌过滤了换行符) 自定义主题测试 : 在主题字段插入换行符( \r\n ) → 成功注入 示例Payload: we\r\nnewlinew\r\nnewlinell 结果:换行符后的内容被解析为邮件正文 漏洞利用 构造特殊主题Payload: 效果: 成功伪造来自 admin@google.com 的发件人身份 可构造任意 @google.com 域的发件地址 技术原理 SMTP注入本质 : 通过注入换行符,将主题字段的剩余内容"推"到DATA部分 服务端错误解析导致将注入内容视为新的邮件头 关键突破点 : 自定义主题功能未正确过滤换行符 邮件系统将注入内容误解析为合法邮件头 漏洞复现步骤 登录Gsuite管理后台 导航至邮件路由设置: 在"Prepend custom subject"字段输入Payload: 发送测试邮件 验证收件箱中显示的伪造发件人 防御措施 输入验证 : 严格过滤用户输入中的特殊字符(特别是换行符) 对邮件头字段实施白名单验证 输出编码 : 对动态生成的邮件内容进行适当的编码 协议层面 : 实施严格的SMTP命令解析 分离邮件头与用户提供的内容 架构设计 : 使用专门的邮件生成库而非字符串拼接 实施内容安全策略 总结 该漏洞展示了即使像谷歌这样的技术巨头,在实现传统协议(SMTP)时也可能犯下看似简单的错误。关键在于: 理解协议底层实现 寻找用户输入与协议解析的交汇点 测试边界情况和特殊字符处理 此案例也凸显了电子邮件系统固有的安全弱点,强调了实施SPF、DKIM和DMARC等现代邮件认证机制的重要性。