對Cisco Secure Email Gateway SMTP走私漏洞報告的響應

簡介

本文檔提供了有關Cisco Secure Email如何針對SMTP走私 — 欺騙電子郵件全球版(2023年12月18日由SEC Consult發佈)中所述攻擊型別的更多詳細資訊。

在與SEC Consult Vulnerability Lab合作開展的一個研究專案過程中，Timo Longin(@timolongin)發現了另一種利用網際網路協定SMTP（簡單郵件傳輸協定）的新技術。威脅實施者可能會利用全球易受攻擊的SMTP伺服器從任意電子郵件地址傳送惡意電子郵件，從而允許有針對性的網路釣魚攻擊。由於漏洞本身的性質，此類漏洞被稱為SMTP走私。

思科尚未發現任何證據，證明文中所述的攻擊可用於繞過任何已配置的安全過濾器。

技術背景

如果不詳細介紹SMTP協定和消息格式，檢視RFC 5322的幾個部分以獲取一些上下文非常重要。

第2.1節將CRLF字元序列定義為消息的不同部分之間使用的分隔符。

消息被分成字元行。行是一系列字元，用回車符和換行符分隔；即回車符(CR)字元（ASCII值13）後緊跟換行符(LF)字元（ASCII值10）。 （回車符/換行符對通常在本檔案中寫為「CRLF」。）

第2.3節更具體地說明了郵件正文的格式。它明確指出CR和LF字元絕不應作為身體的一部分單獨傳送。任何執行此操作的伺服器都不符合RFC。

消息正文只是幾行US-ASCII字元。對主體的唯一兩個限制如下：

• CR和LF必須僅作為CRLF同時出現；它們不得在身體中獨立出現。
• 正文中的字元行必須限製為998個字元，並且應限製為78個字元（CRLF除外）。

但是，該文檔的第4.1節參考了來自以前修訂的RFC的過時語法（這些語法沒有如此限制），承認該欄位上的許多實現沒有使用正確的語法。

裸機CR和裸機LF出現在具有兩種不同含義的消息中。在很多情況下，未正確使用裸的CR或裸的LF而不是CRLF來指示線路分隔符。在其他情況下，裸的CR和裸的LF僅用作US-ASCII控制字元，具有其傳統的ASCII含義。

根據RFC 5322，總結正確格式的SMTP消息應類似於以下示例：

ehlo sender.example\r\n
mail FROM:<user@sender.example>\r\n
rcpt TO:<user@receiver.example>\r\n
data\r\n
From: <user@sender.example>\r\n
To: <user@receiver.example>\r\n
Subject: Example\r\n
\r\n
lorem ipsum\r\n
\r\n. \r\n

本白皮書嘗試利用RFC 4.1部分中提到的例外情況，在正文中插入或「走私」一條新消息，以繞過傳送或接收伺服器上的安全措施。其目的是使走私的郵件繞過安全檢查，因為這些檢查將僅在郵件中的裸線饋送之前對部分郵件運行。舉例來說：

ehlo sender.example\r\n
mail FROM:<user@sender.example>\r\n
rcpt TO:<user@receiver.example>\r\n
data\r\n
From: <user@sender.example>\r\n
To: <user@receiver.example>\r\n
Subject: Example\r\n
\r\n
lorem ipsum\r\n
\n. \r\n
mail FROM:<malicious@malicious.example>\r\n
rcpt TO:<user@receiver.example>\r\n
data\r\n
From: <malicious@malicious.example>\r\n
To: <user@receiver.example>\r\n
Subject: Malicious\r\n
\r\n
Malicious content\r\n
\r\n. \r\n

Cisco Secure Mail行為

在Cisco Secure Mail上配置SMTP偵聽程式時，有三個配置選項可確定應如何處理裸的CR和LF字元。

清除裸露的CR和LF字元的消息（預設）

在選擇預設選項後，Cisco Secure Mail會使用正確的CRLF序列替換傳入郵件中的所有空的CR和LF字元。

包含走私內容的郵件（如示例中的郵件）將被視為兩個單獨的郵件，並且所有安全檢查(如發件人策略框架(SPF)、基於域的郵件身份驗證、報告和一致性(DMARC)、反垃圾郵件、防病毒、高級惡意軟體防護(AMP)和內容過濾器)均獨立運行。

注意：客戶應瞭解，使用此配置，攻擊者可能能夠仿冒其他使用者走私郵件。在源伺服器託管多個域的情況下，攻擊者可能會產生更大的影響，因為攻擊者可以從伺服器上託管的另一個域中模擬使用者，並且對於走私郵件的SPF檢查仍會通過。

拒絕包含空的CR或LF字元的郵件

此組態選項嚴格執行與RFC的相容性。包含空的CR或LF字元的任何消息均會被拒絕

雖然此組態會防止走私情況，但也會導致來自不符合RFC的伺服器的合法電子郵件遭捨棄。

允許包含裸露的CR或LF字元的消息（已棄用）

最終配置會導致Cisco Secure Mail使用其ASCII含義來處理裸露的CR和LF字元。報文正文按原樣傳送，包括走私內容。

由於走私郵件被視為正文的一部分，Cisco Secure Mail可能無法檢測到作為走私郵件一部分包含的附件。這可能會導致下游裝置出現安全問題。此選項已被棄用，不再使用。

建議的配置

思科建議使用預設的「清除裸露的CR和LF字元的消息」選項，因為它提供了安全性和互操作性之間的最佳折衷。但是，使用此設定的客戶應瞭解與走私內容相關的安全影響。希望強制執行RFC合規性的客戶應選擇「拒絕具有裸CR或LF字元的郵件」，注意潛在的互操作性問題。

在任何情況下，思科強烈建議配置和使用SPF、DomainKeys Identified Mail(DKIM)或DMARC等功能，以便驗證傳入郵件的發件人。

常見問題

Cisco Secure Mail是否容易遭受所述攻擊？
從技術上來說，是的。當郵件中包含裸露的CR和LF字元時，可能導致將部分電子郵件視為第二封電子郵件。但是，由於第二個電子郵件是獨立分析的，因此該行為相當於傳送兩個單獨的郵件。思科尚未發現任何證據，證明文中所述的攻擊可用於繞過任何已配置的安全過濾器。

本文提供了繞過SPF和DKIM檢查的示例。為什麼思科說沒有繞過任何過濾器？
在這些示例中，SPF檢查按預期運行，但由於傳送伺服器擁有多個域，導致通過檢查。

推薦配置是什麼？
對於客戶來說，最合適的選擇取決於其特定需求。建議的選項為預設的「清除」配置或「拒絕」選項。

選擇「拒絕」選項是否會導致誤報？
「拒絕」功能啟動對電子郵件是否符合RFC標準的評估。如果電子郵件不符合RFC標準，將拒絕該電子郵件。如果電子郵件不符合RFC標準，甚至可以拒絕合法電子郵件。

是否存在覆蓋此問題的軟體錯誤？
思科錯誤ID CSCwh10142已失敗。

如何獲取有關此主題的詳細資訊？
任何後續問題都可以通過技術支援中心(TAC)案例提出。