STARTTLS，是一種明文通信協(xié)議的擴展，能夠讓明文的通信連線直接成為加密連線(使用SSL或TLS加密)，而不需要使用另一個特別的端口來進行加密通信，屬于機會性加密。

電子郵件客戶端和服務(wù)器之間的連接提供了兩種使用 TLS 保護的方法：隱性 TLS 從一開始就對連接進行加密并在單獨的端口上運行，而 STARTTLS 提供了一種將現(xiàn)有未加密連接升級到 TLS 的機制。

[[427081]]

有時 STARTTLS 被視為一種機會加密模式，僅在可用時提供 TLS 保護。這很容易受到降級攻擊。但是，現(xiàn)代電子郵件客戶端通常期望強制執(zhí)行 STARTTLS，并且在啟用時，不可能進行未加密的通信。

通過STARTTLS升級連接是很脆弱的，容易受到許多安全漏洞和攻擊的影響。我們在 STARTTLS 實現(xiàn)中發(fā)現(xiàn)了 40 多個漏洞。我們的結(jié)論是，這些漏洞是如此普遍，所以我們建議盡可能避免使用STARTTLS。

我們假設(shè)中間人 (MitM) 攻擊者可以修改電子郵件客戶端和提供商的電子郵件服務(wù)器之間建立的連接。

通過命令注入使用 SMTP 和 IMAP 竊取登錄憑據(jù)

2011 年，Postfix 開發(fā)人員 Wietse Venema 描述了 STARTTLS 實現(xiàn)中的一個漏洞，該漏洞允許注入服務(wù)器將其解釋為加密連接的一部分的明文命令。這是通過使用 STARTTLS 命令向同一 TCP 段中的服務(wù)器發(fā)送附加命令來實現(xiàn)的。

我們發(fā)現(xiàn)，盡管自2011年以來人們就知道這個漏洞，但它仍然非常普遍。截止目前共發(fā)現(xiàn)了15個易受攻擊的實現(xiàn)場景，在掃描中，2%的郵件服務(wù)器顯示了這個漏洞。

此命令注入可用于通過 SMTP 和 IMAP 協(xié)議竊取憑據(jù)。

我們的攻擊需要一個中間人 (MitM) 攻擊者，該攻擊者可以修改網(wǎng)絡(luò)流量并在同一服務(wù)器上擁有自己帳戶的登錄憑據(jù)。攻擊者可以注入對其進行身份驗證的命令，然后開始發(fā)送 (SMTP) 或存儲 (IMAP) 電子郵件，受害者發(fā)送的登錄憑據(jù)將存儲在攻擊者可以訪問的電子郵件中。

命令注入還可用于跨協(xié)議攻擊，以使用郵件服務(wù)器的證書提供 HTTPS 內(nèi)容。

通過響應(yīng)注入偽造郵箱內(nèi)容

我們發(fā)現(xiàn)了一種類似于電子郵件客戶端應(yīng)用程序中的命令注入的攻擊，稱之為響應(yīng)注入。此漏洞影響了許多流行的郵件客戶端，包括 Apple Mail、Mozilla Thunderbird、Claws Mail 和 Mutt。

通過在 TLS 握手之前向服務(wù)器消息注入額外的內(nèi)容以響應(yīng) STARTTLS 命令，我們可以注入服務(wù)器命令，客戶端將處理這些命令，就好像它們是加密連接的一部分一樣，這可用于偽造郵箱內(nèi)容。

通過 PREAUTH 和 REFERRAL 竊取憑據(jù)的 IMAP 連接降級

在 IMAP 協(xié)議中，服務(wù)器可以通過 PREAUTH 命令在第一條消息中通知客戶端它已經(jīng)通過了身份驗證。該協(xié)議禁止在已驗證狀態(tài)下使用 STARTTLS 命令。因此，如果客戶端應(yīng)用程序接受 PREAUTH，則它無法強制執(zhí)行 STARTTLS。

中間人攻擊者可以使用它來阻止 STARTTLS 升級連接并強制客戶端使用未加密的連接。該漏洞最初于2014年在Trojitá中被發(fā)現(xiàn)。我們發(fā)現(xiàn)，其他多個電子郵件客戶端應(yīng)用程序也容易受到同一漏洞的攻擊。

此漏洞與 IMAP 功能登錄引用和郵箱引用結(jié)合使用時尤其嚴重，這些命令允許服務(wù)器指示客戶端登錄到另一個 IMAP 服務(wù)器。通過使用 PREAUTH 來防止加密連接，攻擊者可以使用引用來強制客戶端將憑據(jù)發(fā)送到攻擊者控制的服務(wù)器。幸運的是，許多客戶端不支持推薦功能。我們發(fā)現(xiàn)只有一個客戶—— Alpine，容易受到這種 PREAUTH 和推薦組合的影響。

總結(jié)

本文描述的所有漏洞都依賴于不安全連接到安全連接的轉(zhuǎn)換，隱性 TLS 沒有這樣的轉(zhuǎn)換，因此不容易受到這些攻擊。因此，我們認為隱性 TLS 比 STARTTLS 更安全。

我們還指出 STARTTLS 總是引入至少一個額外的連接，所以隱性 TLS 通常提供更好的性能。

安全影響

我們認為本文所講的攻擊難以大規(guī)模執(zhí)行，主要用于有針對性的攻擊。因此，你應(yīng)該始終更新軟件并重新配置電子郵件客戶端以只使用隱性 TLS。

安全建議

對于電子郵件客戶端用戶

如果可能，我們建議用戶檢查并配置他們的電子郵件客戶端，以在專用端口上使用帶有隱性 TLS 的 SMTP、POP3 和 IMAP，即SMTP/Submission端口465，POP3端口995，IMAP端口993。某些郵件服務(wù)提供商，尤其是 Microsoft 和 Apple，不支持SMTP/Submission的隱式TLS。我們建議用戶讓他們的郵件服務(wù)提供商提供更安全的隱性 TLS 選項。

對于應(yīng)用程序開發(fā)人員

默認情況下，電子郵件服務(wù)器和客戶端應(yīng)用程序都應(yīng)提供隱性 TLS。從長遠來看，軟件開發(fā)人員可能會決定根本不支持 STARTTLS，從而簡化他們的代碼和配置對話框和文件。

我們建議在服務(wù)器端和客戶端審核所有支持 STARTTLS 的應(yīng)用程序，因為應(yīng)用程序需要確保沒有未加密的內(nèi)容作為加密連接的一部分被處理。 IMAP 應(yīng)用程序必須確保它們不允許將 PREAUTH 與 STARTTLS 結(jié)合使用，可以使用EAST 工具包，它允許測試應(yīng)用程序。

對于郵件服務(wù)器管理員

確保你使用的服務(wù)器支持所有支持的協(xié)議的隱性 TLS，如果可能，請考慮為 IMAP、POP3 和 SMTP 提交禁用 STARTTLS。

如果你確實需要支持 STARTTLS，建議使用建議的工具針對所有支持的協(xié)議的命令注入漏洞測試服務(wù)器。如果服務(wù)器軟件易受攻擊，立馬應(yīng)該進行安全更新。

常見問題

STARTTLS不安全嗎?

STARTTLS有兩種“模式”，“機會主義模式”和“強制模式”。電子郵件客戶端在提交新郵件或訪問現(xiàn)有郵件之前必須使用用戶名和密碼進行身份驗證。對于這些連接，必須嚴格執(zhí)行通過STARTTLS傳輸?shù)絋LS的轉(zhuǎn)換，因為降級將暴露用戶名和密碼，并給予攻擊者對電子郵件帳戶的完全訪問權(quán)。

如何測試使用的軟件是否易受攻擊?

我們了提供允許測試電子郵件客戶端和服務(wù)器的 EAST 工具包。

使用我們的命令注入測試器測試電子郵件服務(wù)器的命令注入相對容易。 testssl.sh(開發(fā)版)和 TLS-Attacker/TLS-Scanner也會檢查命令注入。

其他支持 STARTTLS 或類似機制的協(xié)議是否受到影響?

我們希望在其他使用 STARTTLS 的協(xié)議中看到類似的漏洞，例如 XMPP、FTP、IRC 或 LDAP。因此，我們建議避免 STARTTLS 并盡可能使用隱性 TLS。

郵件服務(wù)器之間的通信(MTA到MTA)如何處理?

傳統(tǒng)上，電子郵件服務(wù)器之間的 STARTTLS 只能防止被動攻擊，容易受到主動攻擊，例如 STARTTLS 攻擊。