STARTTLS在電子郵件環境中的安全性分析

導讀	STARTTLS，是一種明文通訊協議的擴充套件，能夠讓明文的通訊連線直接成為加密連線(使用SSL或TLS加密)，而不需要使用另一個特別的埠來進行加密通訊，屬於機會性加密。

STARTTLS，是一種明文通訊協議的擴充套件，能夠讓明文的通訊連線直接成為加密連線(使用SSL或TLS加密)，而不需要使用另一個特別的埠來進行加密通訊，屬於機會性加密。

電子郵件客戶端和伺服器之間的連線提供了兩種使用 TLS 保護的方法：隱性 TLS 從一開始就對連線進行加密並在單獨的埠上執行，而 STARTTLS 提供了一種將現有未加密連線升級到 TLS 的機制。

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

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

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

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

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

此命令注入可用於通過 SMTP 和 IMAP 協議竊取憑據。

我們的攻擊需要一箇中間人 (MitM) 攻擊者，該攻擊者可以修改網路流量並在同一伺服器上擁有自己帳戶的登入憑據。攻擊者可以注入對其進行身份驗證的命令，然後開始傳送 (SMTP) 或儲存 (IMAP) 電子郵件，受害者傳送的登入憑據將儲存在攻擊者可以訪問的電子郵件中。

命令注入還可用於跨協議攻擊，以使用郵件伺服器的證照提供 HTTPS 內容。

我們發現了一種類似於電子郵件客戶端應用程式中的命令注入的攻擊，稱之為響應注入。此漏洞影響了許多流行的郵件客戶端，包括 Apple Mail、Mozilla Thunderbird、Claws Mail 和 Mutt。

通過在 TLS 握手之前向伺服器訊息注入額外的內容以響應 STARTTLS 命令，我們可以注入伺服器命令，客戶端將處理這些命令，就好像它們是加密連線的一部分一樣，這可用於偽造郵箱內容。

在 IMAP 協議中，伺服器可以通過 PREAUTH 命令在第一條訊息中通知客戶端它已經通過了身份驗證。該協議禁止在已驗證狀態下使用 STARTTLS 命令。因此，如果客戶端應用程式接受 PREAUTH，則它無法強制執行 STARTTLS。

中間人攻擊者可以使用它來阻止 STARTTLS 升級連線並強制客戶端使用未加密的連線。該漏洞最初於2014年在Trojitá中被發現。我們發現，其他多個電子郵件客戶端應用程式也容易受到同一漏洞的攻擊。

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

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

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

我們認為本文所講的攻擊難以大規模執行，主要用於有針對性的攻擊。因此，你應該始終更新軟體並重新配置電子郵件客戶端以只使用隱性 TLS。

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

預設情況下，電子郵件伺服器和客戶端應用程式都應提供隱性 TLS。從長遠來看，軟體開發人員可能會決定根本不支援 STARTTLS，從而簡化他們的程式碼和配置對話方塊和檔案。

我們建議在伺服器端和客戶端稽核所有支援 STARTTLS 的應用程式，因為應用程式需要確保沒有未加密的內容作為加密連線的一部分被處理。 IMAP 應用程式必須確保它們不允許將 PREAUTH 與 STARTTLS 結合使用，可以使用EAST 工具包，它允許測試應用程式。

確保你使用的伺服器支援所有支援的協議的隱性 TLS，如果可能，請考慮為 IMAP、POP3 和 SMTP 提交禁用 STARTTLS。

如果你確實需要支援 STARTTLS，建議使用建議的工具針對所有支援的協議的命令注入漏洞測試伺服器。如果伺服器軟體易受攻擊，立馬應該進行安全更新。

STARTTLS有兩種“模式”，“機會主義模式”和“強制模式”。電子郵件客戶端在提交新郵件或訪問現有郵件之前必須使用使用者名稱和密碼進行身份驗證。對於這些連線，必須嚴格執行通過STARTTLS傳輸到TLS的轉換，因為降級將暴露使用者名稱和密碼，並給予攻擊者對電子郵件帳戶的完全訪問權。

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

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

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

傳統上，電子郵件伺服器之間的 STARTTLS 只能防止被動攻擊，容易受到主動攻擊，例如 STARTTLS 攻擊。

原文來自：