一种新的email欺骗漏洞-SMTP走私

2023年马上要结束了，祝大家2024年顺利~！

这种新的漏洞手段来自SEC漏洞实验室，在 SEC Consult 漏洞实验室的研究项目中，很出名的DNS协议攻击专家 @timolongin)发现了一种针对另一种互联网协议——SMTP (Simple Mail Transfer Protocol) 的全新利用技术。攻击者可以利用全球范围内的易受攻击的 SMTP 服务器，从任意电子邮件地址发送恶意电子邮件，进行有针对性的网络钓鱼攻击。由于该漏洞本身的性质，这种类型的漏洞被称为 SMTP 走私。

https://sec-consult.com/vulnerability-lab/responsible-disclosure-polic

SMTP走私漏洞详情：

总的来说就是通过利用SMTP协议的解释差异，可以实现走私/发送伪造的电子邮件 ，且同时仍可通过SPF对齐检查。在此研究中，发现了两种类型的SMTP走私，即出站和入站。这些允许从数百万个域（例如[email protected]）向数百万个接收SMTP服务器（例如Amazon、PayPal、eBay）发送伪造的电子邮件。

说SMTP走私漏洞前先提下HTTP走私漏洞，利用HTTP协议中请求和响应的解析和处理方式的不一致性。攻击者通过构造特定的恶意请求，以欺骗服务器和代理服务器，从而绕过安全机制，执行未经授权的操作。HTTP请求走私漏洞通常涉及两个或多个HTTP请求的组合，攻击者可以利用HTTP报文中的头部或其他元数据来混淆和欺骗服务器或代理服务器的解析逻辑。如下图是PortSwigger对http请求走私的简单例子（https://portswigger.net/web-security/request-smuggling）：

再说SMTP走私，SMTP会话一般如下：

同HTTP请求走私一样，SMTP 走私的基本思想就是：

当SMTP对数据结束部分数据（<CR><LF><CR><LF>）有不同解释时，就会发生SMTP走私，如果SMTP服务器对消息数据结束的位置有不同的理解，攻击者可能会破坏消息数据。还可能执行指定任意SMTP命令，甚至发送单独的电子邮件。

如下是用于分析出站SMTP服务器的SMTP分析设置

我们在支持通过SMTP提交邮件的各电子邮件提供商注册电子邮件帐户（与Tutanota和ProtonMail不同），这个研究项目使用了以下提供商:

• outlook.com 

• gmail.com 

• gmx.net 

• icloud.com 

• zoho.com 

• fastmail.com 

• runbox.com 

• startmail.com 

• mailbox.org 

• aol.com 

• yahoo.com 

• web.de 

通过向这些提供商的出站SMTP服务器发送电子邮件，并在入站SMTP分析服务器上接收，我们可以看到SMTP协议实现的初步差异。

查看SMTP分析客户端后，可以立即看到一些SMTP产品与其他产品“不同”。例如，以下是发送DATA SMTP命令后从电子邮件提供商收到的响应：

• -250 以 <CR><LF>.<CR><LF> 结束数据

• -250 开始邮件输入；以 <CRLF>.<CRLF> 结束数据

• -250 以 <CRLF>.<CRLF> 结尾并发送数据

这结果的SMTP走私漏洞测试来说并不理想

经过进一步分析，一些SMTP服务器返回了以下更有希望的响应：

• -输入消息，以 "." 结尾，一行一个

• -输入邮件，以 "." 结尾，一行一个

这个就很有价值了，因不同的操作系统对“行”有不同的理解。Windows上的 "." 行将通过两个回车换行符 (<CR><LF>.<CR><LF> 或 rn.rn) 进行分隔，而Linux上的 "." 行将通过两个换行符 (<LF>.<LF> 或 n.n) 进行分隔。

因此，我们试着使用 <LF>.<LF> 来结束电子邮件的消息数据，如下

因此，对于这种情况，我们将需要确保在数据发送完毕后发送正确的结束序列，根据接收入站SMTP服务器的不同，这可能是完全无害的。但是，如果入站SMTP服务器将<LF><LF>解释为数据序列结束呢？

而出站SMTP服务器通常通过不同的方式处理这种“麻烦的”序列：

• "点"填充（用另一个点来转义单个点）：<LF>..<LF>

• 用<CR><LF>替换它

• 对其进行编码（例如，通过可打印的引号）：=0A.=0A

• 删除整个序列

• 不发送消息

• 也有直接被丢弃的情况

因此，如果<LF><CR><LF>被解释为数据结束序列，我们现在可以在入站SMTP服务器上解析消息数据。

我们继续向所有已注册的电子邮件地址发送一封包含以下消息数据的电子邮件

测试结果发现，很多中招的，我们收到了下面这种邮件，也说明并没有结束邮件数据，是存在SMTP走私漏洞的。

甚至发现了更严重的情况，从GMX到Fastmail的SMTP走私漏洞成功后，接管了管理员，如下：

Received-SPF: pass(gmx.net: 212.227.15.15 is authorized to use '[email protected]' in 'mfrom' identity (mechanism 'ip4:212.227.15.0/25' matched))receiver=mx4.messagingengine.com;identity=mailfrom;envelope-from="[email protected]";helo=mout.gmx.net;client-ip=212.227.15.15

将消息指定了一个不同的接收方电子邮件地址，并只向目标发送走私的消息。使用web.de作为发件人域成功地将跨域SMTP从GMX走私到Fastmail。如下

在这种情况下，我们的目标甚至获取相关管理员的个人资料图片，如下为[email protected]真实的个人资源：

SPF验证结果也出来了：

Received-SPF: pass  (web.de: 212.227.17.22 is authorized to use '[email protected]' in 'mfrom' identity (mechanism 'ip4:212.227.17.0/27' matched))  receiver=mx4.messagingengine.com;  identity=mailfrom;  envelope-from="[email protected]";  helo=mout.gmx.net;  client-ip=212.227.17.22

但这才是个开始：

我们最初只分析了 GMX，但问题比设想要严重得多。与许多大型电子邮件提供商一样，GMX 正在使用名为 NemesisSMTPd 的自定义 SMTP 服务器。由于 GMX 是 Ionos 的一部分，Ionos 提供的电子邮件服务也使用 Nemesis SMTPd。我们在 Ionos 注册了一个电子邮件域，并检查 SMTP 走私是否有效。漏洞可以正常触发，但通过自定义电子邮件域走私似乎并不是必要的。注册的电子邮件域的 SPF 记录包括“_spf-eu.ionos.com”，gmx.net 的 SPF 记录包括“_spf.gmx.net”。查看允许的 IP 范围：

$dig _spf-eu.ionos.com TXT "v=spf1 ip4:212.227.126.128/25 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:82.165.159.0/26 ip4:217.72.192.64/26 ?all"  $dig _spf.gmx.net TXT "v=spf1 ip4:212.227.126.128/25 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:82.165.159.0/24 ip4:74.208.4.192/26 ip4:217.72.207.0/27 ip4:82.165.229.31 ip4:82.165.230.21 ip4:213.165.64.0/23 ip4:74.208.5.64/26 ~all"

所以，无论哪种方式，这不仅允许欺骗gmx.net和web.de，还允许欺骗Ionos托管的一百万个其他域名，但稍后将详细介绍

通过微软exchange进行走私漏洞利用：

来自admin（at）outlook.com的消息确实被送达了，并没有被当作垃圾邮件，并且还回复了我哈哈。

邮件显示如下：

我们可以通过查看消息头再次确认SPF对齐情况：

Received-SPF: Pass (mx3.atos.net: domain of admin(at)outlook.com designates 40.92.75.68 as permitted sender)   identity=mailfrom; client-ip=40.92.75.68;   receiver=mx3.atos.net; envelope-from="[email protected]";   x-sender="[email protected]"; x-conformance=spf_only;   x-record-type="v=spf1"; x-record-text="v=spf1   ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/14   ip4:104.47.0.0/17 ip6:2a01:111:f400::/48   ip6:2a01:111:f403::/49 ip6:2a01:111:f403:8000::/50   ip6:2a01:111:f403:c000::/51 ip6:2a01:111:f403:f000::/52 -all" 

由于之前的例子都是基于文本的，攻击者还可以使用HTML，制作一些更具说服力的钓鱼邮件：

与之前一样，SPF检查在域对齐方面成功，因为sec-consult.com正在使用Exchange Online，并且SPF记录中包含各自的Exchange Online SPF域spf.protection.outlook.com。

Received-SPF: Pass (mx4.atos.net: domain of ceo(at)sec-consult.com   designates 40.92.48.103 as permitted sender)   identity=mailfrom; client-ip=40.92.48.103;   receiver=mx4.atos.net; envelope-from="[email protected]";   x-sender="[email protected]"; x-conformance=spf_only;   x-record-type="v=spf1"; x-record-text="v=spf1   ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/14   ip4:104.47.0.0/17 ip6:2a01:111:f400::/48   ip6:2a01:111:f403::/49 ip6:2a01:111:f403:8000::/50   ip6:2a01:111:f403:c000::/51 ip6:2a01:111:f403:f000::/52 -all" 

通过Amazon,PayPal,eBay...进行CISCO走私漏洞利用：

我们批量使用扫描程序，扫描程序会向入站SMTP服务器发送电子邮件，但会使用特殊的数据结束序列。如果与入站SMTP服务器的连接超时，则说明忽略特殊的数据结束序列。否则，可能会存在SMTP走私漏洞。

payloda的可以用：

数据序列结尾中断：
<CR><LF>x00.<CR><LF>
<CR><LF>.x00<CR><LF>
使用不完整 CRLF 的数据结尾序列:
<LF> <LF>
<CR><LF>.<CR>
<CR> <LF>
消息头中的数据结尾序列等

比如利用空字节结尾数据如下：

现在，通过扫描前Alexa Top 1000，识别出了接受此类序列的各种入站SMTP服务器！但是，这些序列中似乎只有一个对许多SMTP服务器有效：<CR><CR>

• Amazon

• PayPal

• eBay

• Cisco

• The IRS

他们都有一个共同点，那就是他们使用思科安全电子邮件，使用思科安全电子邮件网关或基于云的安全电子邮件网关。而且，出于某种奇怪的原因，sec-consult.com也在使用思科安全电子邮件网关。

，们现在可以从admin(at)icloud.com向我们的目标sec-consult.com发送电子邮件，因为与许多其他出站SMTP服务器一样（在SMTP走私影响中进一步讨论），<CR><CR>不会被过滤，POC如下（结尾使用<CR>.<CR>）：

效果有多好呢，如下为伪造为[email protected]发邮件：

当然，SPF检查在域对齐方面没有任何问题

Received-SPF: Pass (mx4.atos.net: domain of admin(at)icloud.com   designates 17.57.155.23 as permitted sender)   identity=mailfrom; client-ip=17.57.155.23;   receiver=mx4.atos.net; envelope-from="[email protected]";   x-sender="[email protected]"; x-conformance=spf_only;   x-record-type="v=spf1"; x-record-text="v=spf1   ip4:17.58.0.0/16 ip4:17.57.155.0/24 ip4:17.57.156.0/24   ip4:144.178.36.0/24 ip4:144.178.38.0/24 ip4:112.19.199.64/29   ip4:112.19.242.64/29 ip4:222.73.195.64/29 ip4:157.255.1.64/29   ip4:106.39.212.64/29 ip4:123.126.78.64/29   ip4:183.240.219.64/29 ip4:39.156.163.64/29 ~all" 

也因些，DMARC也通过了：

Authentication-Results-Original: mx4.atos.net; dkim=none (message not signed)  header.i=none; spf=Pass [email protected]; spf=None  [email protected]; dmarc=pass (p=quarantine  dis=none) d=icloud.com

并且有个cisco的利用点，我们可以影响到全球。

漏洞影响：

简单统计了下：

通过 GMX 和 Ionos 电子邮件服务进行 SMTP 走私允许来自大约 135 万个不同域的 SMTP 走私，且MX记录到Ionos，以下这些SPF记录都允许_spf-eu.ionos.com 发送电子邮件

支持入站SMTP服务：Fastmail , Runbox，不过在对一些流行的电子邮件软件的默认配置进行测试后，发现Postfix和Sendmail可以走私。从全球来看涉及到很多很多。

微软Exchange：

这两个巨头影响就更大了，涉及域名过百万，还有些价值非常高的目标，如microsoft .com、msn.com、github.com、outlook.com、office365.com、openai.com 等，还有客户的域，如tesla.com、mastercard.com、nike.com 等，在shodan上简单搜了下设计postifix的，如下：

CISCO思科电子邮件网关/云网关：

思科安全电子邮件网关及其云对应产品思科安全电子邮件云网关均“易受攻击”。简单通过DNS被动数据库里找了下，大概4万条涉及的域名，其实中Alexa TOP 1000中有至少以下35个，这还是不考虑没有MX记录的服务，更没找SMTP服务器：

• amazon.com 

• amazon.co.jp 

• amazon.co.uk 

• amazon.it 

• amazon.fr 

• marriott.com 

• cisco.com 

• amazon.co.jp 

• amazon.in 

• paypal.com 

• amazon.ca 

• goodreads.com 

• webex.com 

• custhelp.com 

• amazon.in 

• imdb.com 

• intuit.com 

• ndtv.com 

• amazon.cn 

• makemytrip.com 

• amazon.com.au 

• amazon.com 

• amazonaws.com 

• primevideo.com 

• amazon.es 

• irs.gov 

• amazon.com.br 

• aastocks.com 

• ebay.com 

• amazon.de 

• ebay.de 

• ebay.co.uk 

• ebay.com.au 

• mayoclinic.org 

• audible.com

更多：

在测试过程中，发现很多奇特的入站SMTP服务器，解释数据规则也很多，还有很多探索空间

原文始发于微信公众号（军机故阁）：一种新的email欺骗漏洞-SMTP走私