拆分电子邮件原子：利用解析器绕过访问控制
引言
部分网站通过解析电子邮件地址来提取域名并推断所有者所属的组织。这种模式使得电子邮件地址解析器的差异变得至关重要。预测电子邮件将被路由到哪个域名本应简单，但实际上却异常困难——即使是对于“有效”且符合RFC标准的地址也是如此。
在本文中，我将向您展示如何将电子邮件解析差异转化为访问控制绕过甚至远程代码执行（RCE）。
本文附带一个免费的在线CTF，因此您将能够立即尝试新学到的技能。
您还可以将本文作为打印/下载友好的PDF获取。您还可以从Black Hat获取幻灯片。
我在Black Hat和DEF CON上发表了这次演讲。您可以在此处观看：
大纲
- 引言
- 创建电子邮件域名混淆
- 解析器差异
- Unicode溢出
- Encoded-word
- Encoded-word案例研究
- Github
- Zendesk
- Gitlab
- PHPMailer
- Punycode
- 什么是Punycode？
- 畸形Punycode
- 尝试利用Joomla
- 利用Joomla
- 方法论/工具
- 生成电子邮件拆分攻击
- 自动化利用Encoded-word
- 模糊测试畸形Punycode
- 额外材料
- 防御
- 材料
- CTF
- 时间线
- 参考资料
- 要点
引言
一些规定电子邮件地址格式的RFC已经存在了50多年，它们被混杂在一起形成了一个过于宽松的电子邮件地址标准。电子邮件可以包含引号值、注释、转义和各种编码。如果您面临编写电子邮件解析器的任务，技术上您应该遵循规范，但由于所有这些复杂性，这是一项困难的工作。Web应用程序将这种复杂性外包给电子邮件解析库，因此它们实际上不知道电子邮件是如何解析的。当它们决定基于电子邮件域名做出安全决策时，这会导致问题。
如果您查看RFC2822的3.2.5和3.2.2节，它允许您使用引号值和转义。它们使您能够在电子邮件地址的本地部分使用通常不允许的字符。一些例子是：
|
|
在第一个例子中，由于本地部分被引用，at符号将用作目标邮箱，并移除引号。在第二个例子中，它展示了如何在引用的本地部分内使用转义来将双引号用作目标邮箱。如果我们更深入地研究同一RFC节的3.2.3，我们可以看到它支持注释。注释使用括号构造，可以包含空格甚至嵌套。以下是一些使用注释的“有效”电子邮件示例：
|
|
您不仅限于字母数字值；您可以在注释中放置多种字符。所有这些似乎都 ripe for abuse，通过在解析器、应用程序和邮件程序之间制造混淆。我的研究之旅始于尝试通过滥用转义和注释来制造这种混淆。
创建电子邮件域名混淆
我并不自豪于发现这个过程的故事，但这是事实。我没有花费数小时使用调试器查看Postfix和Sendmail源代码，而且肯定有随机性和运气的成分。
这一切始于我登录一个用于测试的盒子，我安装了一个未命名的应用程序并开始测试其电子邮件解析差异。我一无所获。我尝试的一切都失败了，我甚至考虑完全放弃这项研究。然后，出于绝望，我复制了应用程序使用的特殊字符并将其粘贴到我的电子邮件地址中。我知道这会有效，因为这些都是它们允许的字符，但我只是想看看邮件程序会发生什么。
我检查了盒子的系统日志，注意到我收到了一个带有无效主机的DSN（投递状态通知）。对此感到惊讶，我开始深入挖掘。我开始从电子邮件地址中移除字符，以缩小Sendmail认为它是无效主机的原因。最终，我将其缩小到感叹号，并想起了在进行这项研究时读到的UUCP协议。
UUCP是一种在互联网和电子邮件之前存在的古老协议。它允许您在Unix系统之间发送消息，并代表Unix到Unix复制。它使用感叹号作为域和用户部分之间的分隔符，但顺序与传统电子邮件地址相反。
这太疯狂了，纯粹靠运气，我粘贴的字符以反斜杠结尾，它转义了at符号，然后感叹号将地址视为UUCP地址！以下是我的发现：
原始发现：
|
|
自然，我必须使用不同的Collaborator域名进行跟进以确保它实际上会到达不同的服务器：
|
|
前面的例子在使用Sendmail 8.15.2时