php截取邮箱技巧_拆分电子邮件原子运用解析器绕过访问控制

在本文中，我将向您展示如何将电子邮件解析差异转变为访问掌握绕过分至 RCE。

一些规定电子邮件地址格式的 RFC 已经存在了 50 多年，它们被拼凑在一起形成了过于宽松的电子邮件地址标准。
电子邮件可以有引号值、注释、转义符和各种编码。
如果您面临着编写电子邮件解析器的事情，从技能上讲，您该当遵照规范，但由于所有这些繁芜性，这是一项艰巨的事情。
Web 运用程序将这种繁芜性外包给电子邮件解析库，因此它们实际上并不知道电子邮件是如何解析的。
当他们决定根据电子邮件域做出安全决策时，这会导致问题。

如果您查看 RFC2822 的3.2.5 和 3.2.2， 它许可您利用带引号的值和转义符。
它们使您能够利用电子邮件地址本地部分常日不许可的字符。
以下是一些示例：

"@"@example.com"\""@example.com

在第一个示例中，由于本地部分被引号括起来，因此 at 符号将用作目标邮箱，并删除引号。
在第二个示例中，它展示了如何在引号内确当地部分中利用转义符，以将双引号用作目标邮箱。
如果我们深入研究同一 RFC 部分 3.2.3 ，我们可以看到它支持注释。
注释利用括号布局，可以包含空格，乃至可以嵌套。
以下是一些利用注释的“有效”电子邮件示例：

(foo)user@(bar)example.com

您不仅限于字母数字值；您可以在注释中放置多个字符。
这统统彷佛都很随意马虎被滥用，由于它会在解析器、运用程序和邮件程序之间造成稠浊。
我的研究之旅始于考试测验通过滥用转义符和注释来制造这种稠浊。

我并不为我创造这个漏洞的故事感到自满，但这是事实。
我并没有花几个小时用调试器查看 Postfix 和 Sendmail 源代码，这个中肯定有随机性和运气的身分。

事情开始于我登录一个用于测试的盒子时，我安装了一个不决名的运用程序并开始测试它的电子邮件解析差异。
我一无所获。
我考试测验的统统都失落败了，我曾想过完备放弃研究。
然后，出于绝望，我把运用程序利用的分外字符粘贴到我的电子邮件地址中。
我知道这是有效的，由于它是他们许可的所有字符，但我只是想看看邮件程序会发生什么。

我检讨了盒子的系统日志，创造我收到了一个带有无效主机的 DSN（通报状态关照）。
对此感到惊异，我开始深入挖掘。
我开始从电子邮件地址中删除字符，以缩小 Sendmail 认为它是无效主机的缘故原由。
末了，我把范围缩小到感叹号，并想起了 我在进行这项研究时读过的UUCP 协议 。

UUCP 是一种古老的协议，在互联网和电子邮件涌现之前就已存在。
它许可您在 Unix 系统之间发送，代表 Unix To Unix Copy。
它的事情事理是利用感叹号作为域和用户部分之间的分隔符，但顺序与传统电子邮件地址相反。

这太猖獗了，纯粹是运气不好，我粘贴的字符以反斜杠结尾，转义了 at 符号，然后感叹号将该地址视为 UUCP 地址！
以下是我创造的所有亮点：

最初的创造：

!#$%&'+\/=?^_`{|}~-collab\@psres.net

当然，我必须跟进不同的 Collaborator 域，以确保它确实转到不同的做事器：

oastify.com!collab\@example.com

利用 Sendmail 8.15.2 时，上述示例转到 Collaborator 域“oastify.com”，而不是 example.com。
这对我来说真的很令人愉快，由于我证明了这项研究确实有一定意义。
下一步是找到导致这种行为的其他字符，以是我很快就编写了一个 SMTP 模糊测试器。
我创造 Postfix 没有这种行为，由于它更安全，对吧？好吧，我便是这么想的，直到我通过模糊测试器在 Postfix 3.6.4 中创造了一个变体：

collab%psres.net(@example.com

这实际上会转到 psres.net 而不是 example.com，并利用另一个称为 源路由的古老协议。
源路由许可您利用一系列做事器发送邮件。
其想法是用逗号分隔每个主机，然后在末端包含终极目的地。
还有所谓的“百分比黑客”，即邮件程序将 % 或不同的选定字符转换为 at 符号，然后将电子邮件转发到做事器。
此示例解释了这一点：

foo%psres.net@example.comfoo@psres.net

在此过程中，电子邮件最初发送到 example.com，之后百分号转换为 at 符号，电子邮件发送到 foo@psres.net。
这正是向量所发生的情形，括号注释掉了电子邮件地址的域部分，然后 Postfix 利用本地部分作为源路由，将电子邮件发送到意外目的地。
Postfix 实际上也支持 UUCP。
我后来创造如果你利用单括号技巧。

这些创造让我相信，表面存在着大量的缺点，因此我开始探求更多的缺点。

这项研究中我必须办理的紧张问题之一是天生壅塞字符。
由于许多 Web 运用程序会壅塞多个 at 符号。
这便是我开始研究 unicode 溢出的缘故原由。

我正在测试一个不决名的目标，并把稳到当利用更高的 unicode 字符时，它们会天生其他 ASCII 字符。
这种模式起初彷佛是随机的，但后来我明白了发生了什么。
从 PHP 中 chr() 算法的事情事理的图像中可能可以最好地解释这一点。
chr() 函数返回由整数代码点指定的字符：

-

在示例中，PHP 循环遍历字节并检讨它是否小于零，如果是，则添加 256 直到它为正数。
然后它实行模数运算以使值适宜 0-255 的范围。
这意味着如果您通报大于 255 的字节值，它将溢出并由于模数运算而逼迫进入 0-255 范围。
这正是 unicode 溢出的事情事理；我们只需供应一个代码点大于 255 的字符即可天生其他字符。
最好用一个大略的例子来解释这一点：

String.fromCodePoint(0x100 + 0x40)

在上面的例子中，我利用 fromCodePoint 函数天生一个字符，我通报一个十六进制值 0x100，转换为十进制的 256，然后添加 0x40，这是 at 符号的十六进制数。
然后，当系统实行类似 PHP 中的 chr() 函数的操作时，unicode 代码点将溢出并适宜 0-255，然后天生 at 符号。

创造这一点后，我开始利用 Turbo Intruder 对不决名目标进行模糊测试，并把稳到其他字符也表现出这种行为。
起初它彷佛是随机的，但后来我意识到发生了什么，0x100 只是可以用来实行溢出的数字之一。
如果利用更高的字符，则可以利用中间的任何字符。

String.fromCodePoint(0x100 + 0x40) // ŀ → @String.fromCodePoint(0x1000 + 0x40) // ၀ → @String.fromCodePoint(0x10000 + 0x40) // → @...0x10ffff

上述每个十六进制值都会产生溢出，由于模数运算将导致零，并且这种情形会持续到当前最大 unicode 代码点 0x10ffff。
此目标许可所有类型的 unicode 字符创建其他字符：

'✨' === '(''✩' === ')''✻' === ';''✼' === '<''✽' === '=''✾' === '>''❀' === '@'

如果对每个字符实行 256 模运算，将天生如下字符：

//Mod each code point by 256'❀'.codePointAt(0) % 256 === 0x40String.fromCodePoint(0x40)// @

只管我能够假造各种字符，但我无法用这种技能将电子邮件拆分到这个不决名的目标上。
但这只是一个开始，我证明了天生被阻挡的字符是可能的。
这给了我探求更多内容的信心。

我研究得越多，电子邮件 RFC 就越想给出答案。
在进行这项研究之前，我曾假设电子邮件常日是字母数字，本地部分带有点。
我从未想过存在一个完全的繁芜编码系统，许可您实行多层编码。
然而，这便是我创造的。
仔细查看 RFC 时，我把稳到 rfc2047 和 coded-word，该编码系统许可您利用十六进制和 base64 表示字符。

如果我们利用编码的电子邮件作为示例解释：

“=?” 表示编码字的开始，然后您指定字符集（在本例中为 UTF-8）。
然后问号将下一个命令分别隔，即“q”，表示“Q-Encoding”，之后是另一个问号，表示编码格式的结束和编码数据的开始。
Q-Encoding 只是带有相等前缀的十六进制。
在此示例中，我利用 =41=42=43，即大写的“ABC”。
末了，?= 表示编码的结束。
当通过电子邮件库解析时，电子邮件目的地将是 ABCUSER@psres.net！

有了这些信息，我开始探求利用这种编码解析电子邮件的真实系统。
为理解决这个问题，我想出了两个探测器，它们在大多数有这种行为的网站上都有效：

最初我利用字符集“x”来减小探测的大小，但有些系统会谢绝未知的字符集并会失落败。
最好利用这两个探测，由于我在测试了大量网站后创造它们是最常见的许可字符集。
利用 Collaborator 天生有效负载，并用天生的有效负载更换上面的“collab”。
然后，如果您在 SMTP 对话的 RCPT TO 命令中得到与电子邮件的 SMTP 交互：

abccollab@psres.net

这就证明电子邮件解析器正在利用“编码词”解码电子邮件。

我创造很多网站都有这种行为，它们都有一个共同点。
Ruby。
它们彷佛都利用了同一个 Ruby Gem，名为“Mail”，下载量超过 5.08 亿次。
我开始查看源代码，创造该库正在 解码 UTF-7！
在我的测试平台上，我考试测验重现此情形：

这太猖獗了！
电子邮件现在可以采取 UTF-7 了！
然后一个想法溘然涌如今我的脑海里：如果有 Q 编码和字符集，你能同时利用两者吗？令人惊异的是，这个问题的答案是肯定的。
你可以将 UTF-7 与 Q 编码稠浊利用！

之后我开始考试测验利用 base64 编码，由于“encoded-word” 在电子邮件中当然支持这种编码！
你只需在编码类型中利用“b”代替“q”就可以利用它。

上述示例利用 base64 编码的字符串“foobar”，该字符串由解析器解码。
我知道你在想什么，或者大概只是我的想法，但你确实可以利用 UTF-7 和 base64 编码的数据：

在此示例中，有一个利用 UTF-7 字符集的 base64 编码地址。
首先，电子邮件解析器将解码 base64。
然后，电子邮件解析器将解码 UTF-7 字符集。
末了，电子邮件将被解码为 foobar@psres.net。
此时，您可能会对严格遵照 RFC 有一些疑问。
特殊是当我在测试邮件库时见告您这在域部分也有效时。
把稳，我在这里利用的是字母数字值，但您当然也可以对任何分外字符进行编码。

到目前为止，我们已经理解了如何创建电子邮件域稠浊和令人惊异的编码，但现在是时候利用这些知识来利用实际系统了。
我测试的第一个目标之一是 Github。
我专门针对 Github，由于我知道它是用 Ruby 编写的。

我利用了前面提到的两个探测器来确认 Github 支持“编码字”。
电子邮件在 Collaborator SMTP 对话中被解码！
以是我开始进一步测试。
我须要做的是利用“编码字”来天生另一个 at 符号。
起初，我开始利用带引号确当地部分值，并成功将原始 at 符号嵌入到带引号的值中。
大概我可以在带引号确当地部分中利用“编码字”来冲破带引号的值并天生两个不同的地址？我考试测验了 =22（双引号）和 =40（at 符号），但没有任何成功。

这项研究的问题在于，有时你得不到任何反馈，由于它通过了电子邮件验证，但在到达邮件程序之前失落败了。
你可以利用 DNS 交互作为线索，但它们常日险些毫无用途，由于你无法确定无法到达邮件程序的缘故原由。

经由多次考试测验，我开始考虑 SMTP 对话，并考试测验放置大于号字符。
这里的想法是，我可以利用它来结束 SMTP 对话中的 RCPT TO 命令：

RCPT TO:<"collab@psres.net>collab"@psres.net>

上述示例显示了一个引用确当地部分，个中包含原始 at 符号和大于号。
您可以开始看到攻击是如何形成的。
您有两个地址，利用大于号的想法将使您能够忽略 SMTP 对话中的第二个地址。
有了这个想法，我开始利用编码向量来构建攻击。

我很快创造双引号对 Github 毫无用途，缘故原由是它总是留下一个打开的双引号，这会导致验证失落败。
我考试测验对其进行编码并转义，但没有成功。
我删除了引号并利用“编码字”天生 at 符号和大于号，它通过了验证，但我没有收到电子邮件。
没有 SMTP 对话。
什么都没有。
考虑到这一点，我想大概电子邮件末端的垃圾导致邮件程序因非常或验证而失落败。
如果我可以引入一些可以避免非常或验证的字符会若何？我考试测验了编码空格但失落败了，然后我考试测验了编码空值，然后就成功了！
我与以下电子邮件进行了交互：

对付 Github，字符集无关紧要，因此我利用了“x”，编码的 at 符号 (=40) 转换为 at，大于 (=3e) 完成 RCPT TO 命令，末了 null (=00) 使邮件程序忽略之后的所有内容，您须要在编码后放置一个有效确当地部分，因此我利用了“foo”，这成功通过了验证并拆分了电子邮件。
然后我可以验证我喜好的任何电子邮件域。
我已经在我的测试帐户上验证了 microsoft.com、mozilla.com 和 github.com 上的地址：

这已经是一个缺点了，由于你不应该能够验证你不拥有的地址。
然后我的同事 James Kettle建议我看看 Cloudflare “零信赖”，看看是否可以将其配置为信赖某些电子邮件域。
我创建了一个测试帐户并深入研究了配置，创造你可以利用 Github 作为 IdP，并利用电子邮件域来确定你是否有权访问某个网站。
这可以是内部网络或任何其他受零信赖保护的域，条件是他们利用 Github 作为 IdP。

Zendesk：访问受电子邮件域保护的支持中央

在 Github 上取获胜利后，我开始探求利用 Ruby 并具有某种电子邮件域验证形式的运用程序。
Zendesk 引起了我的把稳，由于大概你可以访问受保护的支持台？在考试测验拆分电子邮件地址之前，我搜索了他们的文档，创造你须要打开支持中央，许可注册，然后选择许可注册的域。

支持中央配置完毕后，我开始测试。
我考试测验了在 Github 上利用的所有攻击，但都没有成功。
大概他们利用了不同的邮件程序或验证？我考试测验了一些新想法，利用电子邮件的引用本地部分，并且通过我在 Collaborator 中得到的交互，它看起来比我在 Github 上测试时更有希望。

我创造利用两个重复的 Collaborator 域很有用，这样我总能得到交互，通过检讨 SMTP 对话，你可以看到正在转换的内容。
我发送了以下内容：

Input:=?x?q?=41=42=43collab=40psres.net=3e=20?=@psres.net

并得到以下返回：

Output:RCPT TO:<"ABCcollab@psres.net> "@psres.net>

这次互动让我明白了很多事情，首先，它们许可大写。
其次，它们许可转换后的空格；第三，它们彷佛引用理解码时本地部分常日不许可的值。
大概我可以滥用这种行为？

经由多次考试测验，我终于取得了一些进展。
我欺骗理解析/验证，将字符转换为阻挡的字符，重复编码的引号并天生将被其代码删除的字符，直到末了我布局了一个有效的电子邮件拆分攻击：

利用这封“电子邮件”，我能够绕过支持中央设置的限定。
这次攻击的关键是嵌入的编码引号，这些引号被解析器解码。
然后 =3c22 天生一个小于号字符，该字符被删除，然后完成引号，因此它通过了他们的验证/非常。
您会把稳到“=3e=00”与我在 Github 上利用的序列相同，因此它们显然共享一些相同的代码，但它们的相应办法有很大不同，因此攻击更加完全。

为了探求更多 Ruby 新手，我转向了 Gitlab。
他们是一家 IdP，供应企业产品，因此它彷佛是一个很好的测试目标。
James 有一个他之前测试过的 Gitlab 做事器，以是我首先开始查看它。
您可以将其配置为许可利用特定域进行注册。
以是这立即引起了我的把稳。
我考试测验了我在 Github 和 Zendesk 上利用的向量，但它们不起浸染。
然后我想起“encoded-word”许可您利用下划线作为空格，这个向量是我迄今为止展示的最优雅的向量：

我利用 Postfix 作为已配置的企业实例的邮件程序。
您可以利用 =20 来做同样的事情，但下划线是 1 个字符，我喜好优雅的矢量！

这意味着我可以访问利用基于域的注册限定的 Gitlab Enterprise 做事器。
正如我所提到的，Gitlab 也是一个 IdP，以是我也开始测试 Web 运用程序。
Enterprise 黑客在这里不起浸染。
我认为这是由于他们利用了不同的 Mailer。
然而，我很快就找到了另一个向量。
现在我网络了一堆向量，以是我有一个 Turbo Intruder 脚本，它遍历了所有已知向量，也考试测验了其他向量。
它利用编码空间找到了一个新向量，这是有道理的，由于它在 Enterprise 产品上有效，只是须要一种不同的方法来利用：

它与 Github 漏洞非常相似，但它须要有效的字符集，并且须要空格不为空。
在图中我利用了“x”，但在实际攻击中，你会利用“iso-8859-1”。

不幸的是，我没有充分利用我测试的所有功能，而且失落败了很多次。
每一次失落败都是一个学习过程，但这个案例研究的有趣之处在于，“encoded-word” 是在基于 Ruby 的系统之外的系统上进行解析和解码的。

我已经根据 James 的建议构建了一个测试平台，因此我开始测试 PHPMailer 如何解析电子邮件。
我进行了黑盒和白盒测试，创造它没有解析电子邮件地址本地部分或域部分中的“编码词”。
但是，它确实解析并解码了电子邮件地址之外的名称部分中的“编码词”！

=?utf8?q?=61=62=63?=<collab@psres.net>

剖析代码时，尖括号是必需的，这意味着它常常会在 Wordpress 等运用程序中验证失落败。
我考试测验将有效载荷嵌入各种运用程序的名称参数中，但无法利用这个特定的库。
不过，我敢打赌，你可以用“编码词”嵌入 XSS 有效载荷，这在某些地方会起浸染。
如果你能做到，请与我联系，我很乐意听听你的意见。

我们已做生意量了如何操纵电子邮件解析以绕过 访问掌握。
但让我们更进一步。
如果电子邮件地址可以被武器化以获取远程代码实行 (RCE) 怎么办？在本节中，我们将先容 Punycode 攻击以及我如何利用 Joomla。

Punycode 是当前 DNS 系统中表示 Unicode 字符的一种办法。
Punycode 始终以 xn-- 开头，后跟连字符和字母数字字符。
非 ASCII 字符利用表示这些字符的分外算法进行编码。
该算法将 Unicode 字符序列转换为仅利用 ASCII 字符的表示形式。
该算法规定，常日输入中不构成 Unicode 字符的任何 ASCII 字符都将按原样添加到输出中。
例如，域 münchen.com 利用以下 Punycode 序列进行编码。

xn--mnchen-3ya.com

Punycode 的事情办法本身就使其难以测试，由于根据算法的事情办法，变动一个字符可能会影响全体输出和字符位置。
我们想要做的是在解码编码值时天生恶意字符，而做到这一点是一项巨大的寻衅。
在以下示例中，您可以看到当修正一个字节时，unicode 字符的位置会发生变革。

foo@xn--mnchen-2ya.com → foo@ümnchen.comfoo@xn--mnchen-3ya.com → foo@münchen.comfoo@xn--mnchen-4ya.com → foo@mnüchen.comfoo@xn--mnchen-5ya.com → foo@mncühen.com

在 Wikipedia 上阅读了所有干系信息后，我点击了一个在线 Punycode 转换器的链接。
该转换器利用了 IDN PHP 库。
然后我开始考试测验各种 Punycode 地址。
我创造，如果在开头利用两个零，可能会天生意想不到的字符：

Input:psres.net.com.xn--0049.com.psres.netOutput:psres.net.com.,.com.psres.net

这是我第一次成功创建格式缺点的 Punycode。
输入包含 Punycode“xn--0049”，由于库有缺陷，该代码解码为逗号。
我能够利用此技能天生更多字符：

Input:foo@xn--0117.example.comOutput:foo@@.example.com

天生相同字符的方法有很多。
我考虑过电子邮件拆分攻击，但我得出的结论是，发送电子邮件时 Punycode 地址不会被解码，由于它是无效的。
更有可能的是，在显示电子邮件时解码。
自然而然，我问自己的问题是，你能创建XSS向量吗？

这是模糊测试器的事情。
我开始构建一个模糊测试器，它立即开始产生有趣的结果：

x@xn--42 → x@,x@xn--024 → x@@x@xn--694 → x@;x@xn--svg/-9x6 → x@<svg/x@xn--svg/-f18 → x@<svg/x@xn--svg/-fq1 → x@<svg/

我认为这是探求利用 IDN PHP 库的运用程序的好机遇。
在 Github 上搜索后，我创造了一个利用该库的有趣目标：Joomla！
这很棒，由于如果我得到 XSS，那么我就可以进行 RCE。
进行源代码剖析时，我把稳到他们在对 Punycode 进行解码之前对用户的电子邮件进行了转义。
这意味着如果我可以天生一些格式缺点的 Punycode，当解码天生 HTML 时，我就可以获取 XSS，但这并不随意马虎。

考试测验利用 Joomla

我愉快地回到模糊测试器，开始天生数百万个字符组合。
我设法构建了部分 XSS 向量，但碰着了几个问题。
我只能通过利用多个 Punycode 子域来天生两个 ASCII 字符。
这种限定源于 Punycode 算法、PHP 的特定事情办法以及有缺陷的 PHP IDN 库的怪癖。
正如您在示例中看到的，我很靠近成功，但这些问题使得利用 Joomla 变得非常困难。

xn--x-0314.xn--0026.xn--0193.xn--0218 → <x.. .=xn--x-0314.xn--0026.xn--0193.xn--54_52932 → <x.. .='

我得出结论，XSS 是不可行的，由于只管我能够天生单引号 HTML 属性，但它须要下划线字符。
然而，Joomla 不许可在电子邮件地址的域部分利用下划线。

那么故事就这么结束了吗？不完备是。
我想了一下子，创造如果利用单个 Punycode 子域名，则可以天生任何打开标签！
终极，经由大量测试，我得出结论，唯一可利用的向量是打开样式标签：

别的的现有 Joomla HTML 代码将添加一个空格和右尖括号。
电子邮件输出在用户列表页面上。
这意味着它是持久的，乃至不须要激活帐户。
您只需注册一个用户，它就会是持久样式注入！
但我们如何将邪恶的 CSS 放入个中？要做到这一点，您须要一个不被阻挡的地方来放置 CSS。
用户的名称字段是一个不错的选择，您可以利用 @import 来导入邪恶的样式。

我碰着的问题是，样式注入后涌现的所有 HTML 代码都将被视为 CSS！
要办理这个问题，您只需欺骗 CSS 解析器，让它认为这都是无效的 CSS 选择器，这意味着只需利用 {}。
因此，如果您将 after 放在名称字段的开头，则可以在 after 导入样式。
攻击的事情事理如下：

请把稳，第一个帐户名称带有“a”，第二个帐户名称带有“x”，这是为了确保样式注入首先发生，第二个帐户利用@import。
花括号用于将导入之前涌现的所有 HTML 视为无效的 CSS 选择器。
Chrome 的严格 CSS mime 类型检讨也不适用于此处，由于利用了内联样式。

我们现在须要做的是通过 CSS 提取 CSRF 令牌，幸运的是，这方面有很多好文章。
最好的方法是利用导入链并利用 d0nut 和 Pepe Vila开拓的工具之一。
我决定利用我的CSS 盲目提取研究来定制我已经开拓的工具， 个中包括让它提取特定的 Joomla 令牌。
我将在文章的后面分享 Github repo 中的定制代码。

在我的 CSS 盗取器运行后，我注册了这两个帐户，并利用超级管理员帐户访问了用户页面。
盗取器显示了管理员的 CSRF 令牌，因此下一步便是向管理员供应利用盗取令牌的 CSRF 漏洞。
我的盗取器还构建了 CSRF 漏洞 。
然后，漏洞会激活攻击者的帐户并使他们成为超级管理员。
然落后击者可以修正管理模板以获取 RCE！

以下是这次攻击的演示：

在视频中，左侧是管理员浏览器的浅色部分，右侧是攻击者浏览器的深色部分。
攻击者注册了两个账户，第一个账户用于从格式缺点的 Punycode 地址注入样式标签，第二个账户用于注入 CSS 透露样式表。
然后，管理员访问后端和用户列表页面，恶意 CSS 会立即加载并在几秒钟内透露令牌。

一旦发生这种情形，攻击者就会收到管理员的 CSRF 令牌关照，然后开始与管理员进行即时对话。
管理员点击攻击者发送的链接，然后利用 CSRF 编辑后端模板，注入一些调用系统命令 cat /etc/passed 的 PHP。

在进行这项研究时，我开拓了一种在测试时非常有用的方法。
探测、不雅观察、编码和利用。
首先利用本文中提到的探测，然后在 Collaborator 等工具中不雅观察结果。
重复此过程，直到得到攻击所需的字符。
然后，当此过程完成后，进行利用。
您可以将此方法运用于编码词和 Punycode 攻击。

首先探测“编码词”，不雅观察解码后的电子邮件以确认它受支持。
然后对各种字符进行编码并不雅观察它们如何解码。
然后跟进滥用这些字符的漏洞。

为了不雅观察结果，我利用了 Burp Collaborator ，它许可我查看 SMTP 交互。

为了帮助查找电子邮件拆分攻击，我创建了几个 Hackvertor 标签。
Hackvertor 是 我编写的免费 Burp Suite 扩展，它许可您在要求中利用标签并对数据实行嵌套转换。
您只需将标签放在您希望发生 unicode 溢出的位置，然后将要转换的字符放在标签内：

<@_unicode_overflow(0x100,'...')>@</@_unicode_overflow><@_unicode_overflow_variations(0xfff,'...')>@</@_unicode_overflow_variations>foo<@_encoded_word_encode('...')>@<@/_encoded_word_encode>example.com<@_encoded_word_decode('...')>=41=42=43<@/_encoded_word_decode> <@_email_utf7('...')><@/_email_utf7> <@_email_utf7_decode('...')><@/_email_utf7_decode> <@_encode_word_meta('iso-8859-1','...')><@/_encode_word_meta>

第一个标签创建一个 unicode 溢出，并利用标签参数 0x100（十进制为 256）来创建溢出。
第二个标签利用标签参数作为最大 unicode 代码点，并天生尽可能多的字符，这些字符会溢出到标签内指定的字符。
第三个标签将许可您实行编码字转换，在本例中，我对 @ 符号进行了编码。
第四个标签将解码编码字序列。
还有其他标签可帮助创建和解码 UTF-7 电子邮件和编码字元字符。

要利用这些标签，您须要在 Hackvertor 菜单中启用“许可代码实行标签”。
然后单击同一菜单中的“查看标签存储”。
然后，您可以通过单击标署名称并利用安装按钮来安装这两个标签。

当我创造最初几个漏洞时，我创造自动化对付查找其他漏洞非常有用，而 Turbo Intruder常日 对付自动化此过程非常有用。
Turbo Intruder 是 James Kettle编写的另一个免费 Burp 扩展。
我创建了一个 Turbo Intruder 脚本来帮助利用邮件程序。
当您确定做事器支持编码字但想知道邮件程序是否许可您利用空值或其他字符拆分电子邮件时，可以利用此脚本。

它利用了我在测试 Github、Zendesk、Gitlab、Bugcrowd 和许多其他程序时创造的一系列已知拆分电子邮件的技能。
您可以轻松自定义脚本以实行本演示文稿中提到的其他攻击。
要利用它，您只需将 validServer 变量变动为要欺骗的目标域。
然后，将 %s 放在想要添加电子邮件的要求中，然后右键单击要求并发送到 Turbo Intruder 并利用修正后的脚本。
然后运行攻击。
如果攻击成功，您该当在 Turbo Intruder 中收到互助者交互。
这意味着电子邮件域是可欺骗的。
如果您碰着有速率限定的运用程序（就像我一样），您可以变动 REQUEST_SLEEP 变量以与这些做事器很好地合营利用。

针对畸形 Punycode 进行模糊测试

我创建了一个 Punycode 模糊测试器来帮助查找格式缺点的 Punycode。
我与 PortSwigger 的同事分享了它，并创建了一个寻衅，看看是否有人可以在我所设定的限定内天生 XSS 向量。
没有人成功做到这一点，但我还是通过 CSS 渗透得到了 RCE。
模糊测试器的事情事理是给它输入一些 Punycode 地址，然后用随机数字、字符或空格更换占位符。
匹配和包含只是匹配模糊输出的正则表达式。
它在查找可以天生哪些字符方面非常有效。

在 DEF CON 上，由于我有 5 分钟的额外韶光，以是我展示了一些褒奖向量。

RFC 许可所谓的 SMTP 可选参数。
个中一个参数“ ORCPT ”可用于偷运电子邮件地址的域部分并变动其目的地。
由于许多运用程序常日接管带引号确当地部分但缺点地处理转义字符，您可以滥用它来变动电子邮件目的地：

​"foo\\"@psres.net> ORCPT=test;admin"@example.com

此技能在 Postfix 中有效，但可能在其他邮件程序中也有效。

另一个好处是，我创造了 Postfix 中一些更令人惊异的电子邮件解析行为。
我无法利用这些来绕过访问掌握，但它们仍旧很有趣，并寻衅了您对电子邮件地址解析办法的假设。
第一个利用 UUCP，无论引号如何都会发送。

Input: "psres.net!collab"(\"@example.comResults in email to: collab@psres.net

第二个利用源路由，乃至利用方括号语法。

Input: collab%psres.net@[127.0.0.1]Results in email to: collab@psres.net

我建议您在利用电子邮件解析库时禁用“编码词”。
作为末了的手段，您可以利用以下正则表达式在电子邮件地址中查找“编码词”的开头和结尾字符来阻挡它被利用：

=[?].+[?]=

纵然电子邮件地址来自 Github 等 SSO 供应商，您也该当始终对其进行验证。
切勿将电子邮件域用作唯一的授权办法，由于正如我们所见，它很随意马虎被欺骗。

译：https://portswigger.net/research/splitting-the-email-atom

标签：利用电子邮件