电子邮件场景中STARTTLS的安全分析

今天分享的论文主题为电子邮件场景中STARTTLS的安全分析，主要研究者来自德国明斯特应用技术大学。TLS是当今使用最广泛的网络加密协议之一。在电子邮件通信场景中，TLS通常不会被直接使用，而是通过STARTTLS进行协商。该论文首次对SMTP、POP3和IMAP三种主流邮件协议中的STARTTLS展开安全研究工作，实现了涵盖多种邮件攻击的半自动测试工具EAST，并利用该工具在28种邮件客户端和23种服务器中发现了40多个STARTTLS安全问题，可导致邮箱欺骗、凭证窃取等安全威胁。论文发现，STARTTLS的标准定义不够明确、具体实现容易出错，因此建议邮件管理员尽可能避免使用STARTTLS。论文发表于网络安全领域顶级学术会议USENIX Security 2021（录取率246/1316 =18.7％）。

01【背景介绍】

在协议设计之初，SMTP、POP3及IMAP等主流电子邮件协议均以明文方式传输报文内容，无法保证交互报文的机密性和完整性。IETF曾为各协议分别设置了额外的支持TLS协议的通信端口（即以隐式TLS方式传输）。但由于人们更希望使用原有的端口、以升级配置的方式支持TLS加密，STARTTLS技术便应运而生。

在STARTTLS中，每个连接都以明文开始，通过协议特定的消息交换升级为TLS。如图表1所示，服务器宣布它有能力发起STARTTLS（第1行），而客户端用STARTTLS命令（第2行）启动向TLS的过渡。在STARTTLS命令得到肯定的回应后（第3行），双方最终开始TLS握手。目前，STARTTLS已得到广泛部署和应用，被几乎所有的邮件客户端和服务器支持。

图表1：STARTTLS转向TLS的消息交换流程

STARTTLS适用于难以强制执行加密的通信场景。许多SMTP服务器的TLS配置存在诸多问题，譬如使用不规范的或者过期的TLS证书。如果目标服务器强制要求进行TLS验证，将导致邮件发送失败。在这种场景下，如果使用STARTTLS，在TLS协商失败的情况下，SMTP服务器将退回到明文，邮件的发送不会完全中断。也就是说，对于配置了STARTTLS的邮件服务而言，加密保护是“机会性”的。然而，对于电子邮件服务而言，这种明文回退也会带来一些问题，因为客户端可能向用户报告TLS异常，并交由用户决定停止或继续邮件服务。从这个角度看，使用STARTTLS将会徒增邮件协议的复杂性和通信的往返次数。

STARTTLS已经被证实存在诸多安全问题，最著名的为STARTTLS降级攻击，即攻击者以中间人的方式篡改服务器响应、移除STARTTLS支持信息，将连接降级为明文。此外，Postfix SMTP服务器的作者Wietse Venema在Postfix中发现了一个命令注入的错误[1]，如果客户端在STARTTLS命令后附加一个额外的命令，该命令会被缓冲并过渡到TLS连接建立后实行，即实质上导致了攻击者可在加密会话中注入某段明文。

然而，目前无论是标准化机构还是学术相关的文献，都还没有对STARTTLS应用安全性进行系统性的分析。本篇论文的作者将已有的STARTTLS进行了系统化的梳理，分为协商、缓冲、篡改、会话固定和UI欺骗等不同的攻击类别，并设计了半自动测试工具EAST，利用该工具发现了多家邮件客户端和服务器中的STARTTLS漏洞。

02【实验设计】

1. STARTTLS安全问题定义及分析

作者将STARTTLS安全问题定义为：如果邮件协议直接使用隐式TLS（而不是STARTTLS）就不会出现的问题。也就是说，从实验的角度来看，假设一个会话在测试中达到的状态等同于它通过隐式TLS达到的初始状态，测试就可以终止了（说明未找到由于STARTTLS引起的问题）；而没能达到这种状态的会话（即STARTTLS协商出现问题，或者经过STARTTLS后得到了和隐式TLS不同的状态）则将被留作进一步研究。

为系统地研究STARTTLS安全问题，作者对已有的相关学术论文、博客、邮件列表及CVE数据库等进行了广泛地调研，梳理已有的安全问题并进行了扩展。例如，SMTP命令注入攻击虽已被提出，但尚未有利用该问题开展实际攻击，例如盗取受害者邮件的具体方案。作者则提供了具体的攻击实施方法，并引入了一个跨协议攻击，允许在受影响的电子邮件服务器的证书下托管HTTPS网站。

2. 探索协议消息空间

图表2：SMTP中最小的STARTTLS会话

图表2显示了SMTP中STARTTLS以最简单的方式完成一次协商的会话流程，具体过程及可能出现安全问题的步骤介绍如下：

（A）表示SMTP服务器的响应，包括问候语，一个状态代码,大致表示 "good"、"bed "或 "incomplete"。

（B）一个可读的文本信息。网络攻击者可以改变这些信息、导致客户端处理出错，而在出现错误的情况下，客户端必须决定是否向用户显示可读的文本。

（C）表示为了获得列表，客户端必须发出的EHLO命令。

（D）攻击者可能会假装服务器不理解EHLO命令，并将状态代码改为 "bad"，导致降级攻击。

（E）此行为明文，没有经过验证，客户端一般不对其进行处理。

（F）为EHLO命令之后的第一个命令。

（G）服务器确认STARTTLS命令后客户端应该检查响应代码，并且只在有 "good "的响应时开始TLS握手，否则可能受到STARTTLS stripping攻击。

（H）客户端不应该显示任何未经认证的错误信息。

（I,J）TLS握手之后，状态与连接时的初始状态略有不同，但其他所有应用的状态都应该被重置到初始状态，否则可能会导致命令注入攻击。

（K）由于旧的E行信息被丢弃，需要再一次查询新的信息。

可以看出，即使在最简单的STARTTLS协商情形下，客户端需要处理的情况也很复杂、可能会导致许多安全问题。那么，应该如何设计测试实验触发客户端出现这些安全问题呢？作者认为，对一个自动化的测试协议安全测试工具而言，最关键的便是回答：When do we send which messages? 即在什么阶段发送何种消息。具体而言，作者的解决思路为：

Q1-何时发送消息？

由于SMTP和POP3采用的是step-by-step的信息处理方式，按照通信的顺序，只需要在明文阶段回复客户端发来的消息即可；而对于IMAP而言，攻击者理论上可以在任意时间向客户端发送包含篡改后的能力(capabilities)的未标记响应。因此，作者详细研究了IMAP的标准，把所有在TLS握手之前可能改变MUA状态的未标记响应都找了出来。测试工具将只在所发送的测试载荷可能会被客户端处理的阶段，才会发送消息。

Q2-发送哪些信息？

分为两种情况进行讨论。在STARTTLS命令之前，客户端发送的任何命令都会尝试回复所有可能的响应内容。因为根据标准，客户端能够发送的命令是非常有限的，这种“枚举式”回复具有实操性；而对于STARTTLS命令之后的消息，作者通过分析协议标准和已有的安全漏洞，保留了一些可能会更改客户端状态或者直接触发漏洞的消息类型，将可能与STARTTLS 安全无关的消息排除。

基于上述思路，作者设计了半自动化的测试工具EAST，通过配置测试案例、控制在协议会话中的何种阶段向某个命令发送什么响应进行测试。文中还解释了如何通过一些假设来减少测试用例的数量，使得测试在可以接受的时间内完成，具体细节可阅读论文原文。注意，之所以为“半自动化”的测试，是因为类似UI欺骗这样的问题很难被自动检测到，需要人工参与。

由于本文涉及到的攻击种类较多，下面将选择性地对其中几种攻击原理和实施方式进行介绍，更多细节请参照原文。

3. 攻击原理举例介绍

命令注入：如图表3所示，客户端在一个TCP段中发送了两条命令（第2-3行）。服务器将完整的请求附加到一个缓冲区，并最终从该缓冲区中解析和分割出命令。服务器确认了STARTTLS命令后将立即启动向TLS的过渡，并将所有普通的TCP套接字包裹在TLS套接字中。然而，STARTTLS命令之后的尾部数据（第3行）仍然留在缓冲区中。如果不刷新，服务器可能会认为该命令确实是通过TLS发送的，尽管它实际是明文阶段的剩余数据（第7行）。在这个例子中，服务器没有刷新缓冲区，在TLS内部解释NOOP命令，并以加密的答案回应（第8行），导致了命令注入攻击。

图表3：命令注入

响应注入：如图表4所示，服务器在STARTTLS响应后注入了额外的数据（第4-5行）。当客户端发出NOOP（第7行）时，它通常会等待服务器的响应。然而，由于服务器响应已经在客户端的响应缓冲区中，其被直接送到第8行，导致响应注入攻击。

图表4：响应注入

4. 具体攻击实现举例介绍

STARTTLS Stripping：如图表5所示，当客户端受到STARTTLS降级影响时，用户凭证将通过明文发送。此外，还有一些更微妙的STARTTLS降级攻击场景，例如客户端虽不会泄露用户凭证，但会以明文方式上传起草和发送的电子邮件。

图表5：用STARTTLS降级攻击绕过STARTTLS

PREAUTH STARTTLS Blocking：图表6中，攻击者通过发送PREAUTH命令（第1行）绕过了STARTTLS。客户端没有终止连接，继续进行SELECT收件（第2行）。攻击者将模仿一个良性的IMAP服务器篡改客户端的邮箱数据，如果客户端同步草稿邮件和已发送的邮件，敏感数据就会被泄露（第4到8行）。

图表6：用PREAUTH问候语阻止STARTTLS过渡

03【主要发现】

1. 评估结果

如图表7所示，在28种邮件客户端中，有15个可以被降级为明文并泄露敏感数据。其中，STARTTLS降级攻击在10个客户端上有效，PREAUTH问题在5个客户端上有效，包括Gmail，Gmail Go和Samsung Email在内的多家著名邮件厂商都受到影响。

图表7：对28个电子邮件客户端进行测试的结果

大多数测试服务器都没有受到命令注入漏洞的影响，但也还有7家厂商的服务器即使在最新版本中仍有被攻击的可能，如图表8所示。

图表8：受命令注入和会话固定漏洞影响的邮件服务器

2. 缓解措施

作者认为，最好的解决方式是直接将隐式TLS作为默认选项，即放弃使用STARTTLS。此外，作者针对当前STARTTLS的使用也提出了一些缓解安全风险的建议：

•隔离明文阶段：由于明文数据可能被处理或缓冲的地方很多，不应该允许STARTTLS在向TLS过渡转换前（即明文发送阶段）发送额外的命令。

•修复缓冲问题：不得将明文发送的内容解释为加密连接的一部分。在明文阶段未被隔离、使用一个单独缓冲区的情况下，在STARTTLS命令后启动TLS握手时，应对该缓冲区进行清除。

•简化协商：协商应该被精简，即将客户端发出STARTTLS命令作为第一条也是唯一一条命令。

04【结论】

论文针对电子邮件场景下STARTTLS协议进行系统性的安全分析，通过设计并部署半自动化的测试工具，在多家知名电子邮件客户端和服务器中发现了40多个STARTTLS漏洞。依据实验结果，文章作者认为STARTTLS协议存在系统性的安全风险，并提出了一些改进建议。

原文链接

https://www.usenix.org/conference/usenixsecurity21/presentation/poddebniak

参考文献

[1] Wietse Venema. Plaintext command injection in multiple implementations of STARTTLS (CVE-2011- 0411). http://www.postfix.org/CVE-2011-0411. html, March 2011. Accessed: 2020-06-01.

仓永康弘，编辑&审校|张一铭、刘保君

声明：本文来自NISL实验室，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。