針對電子郵件發件人欺騙攻擊的大規模分析

作為一種基本的通信服務，電子郵件在個人和公司通信中都扮演著重要角色，這也使其成為最常見的攻擊媒介之一。多個協議、角色和服務的身份驗證鏈確保了電子郵件的真實性，任何失效的部分都可能破壞整個基于鏈的防御。本文系統地分析了電子郵件的傳輸，并確定了一系列能夠繞過SPF，DKIM，DMARC和用戶界面保護的新攻擊。特別是通過進行cocktail組合攻擊，可以偽造更真實的虛假電子郵件來滲透電子郵件服務，例如Gmail和Outlook。本文對30種流行的電子郵件服務和23個電子郵件客戶端進行了大規模驗證，發現它們都容易受到某些類型的攻擊。已將發現的漏洞功能及時報告給相關的電子郵件服務提供商，并從包括Gmail，Yahoo，iCloud和Alibaba在內的11家公司收到了肯定的答復。

Introduction

電子郵件服務是當下必不可少的通信服務，這使其成為網絡攻擊的主要目標。但是，電子郵件傳輸協議遠不能抵抗潛在的攻擊。電子郵件系統的安全性依賴于由各種電子郵件服務維護的多方信任鏈，這增加了其對網絡攻擊的系統脆弱性。如下圖所示，電子郵件傳輸過程中的身份驗證涉及四個重要階段。

正如木桶理論所揭示的，桶的容量取決于其最短的板，電子郵件的真實性取決于身份驗證鏈中最薄弱的環節。首先，盡管存在各種用于識別欺騙電子郵件的安全擴展協議（例如SPF，DKIM和DMARC），但由于受不同協議保護的實體不一致，欺騙攻擊仍可能成功。其次，電子郵件的身份驗證涉及四個不同的角色：發件人，收件人，轉發者和UI渲染器。每個角色應承擔不同的安全職責。如果角色都無法提供適當的安全防御解決方案，則無法保證電子郵件的真實性。最后，安全機制是由具有不一致處理策略的不同電子郵件服務實現的。這些安全機制是由不同的開發人員實現，其中一些在處理帶有模糊header的電子郵件時會偏離RFC規范。因此，不同的服務之間存在許多不一致之處。攻擊者可以利用這些不一致來繞過安全機制，并向電子郵件瀏覽器端和電子郵件客戶端呈現虛假結果。

這項工作系統地分析了電子郵件傳遞過程中身份驗證的四個關鍵階段：發送身份驗證，接收驗證，轉發驗證和UI呈現。發現14種電子郵件欺騙攻擊能夠繞過SPF，DKIM，DMARC和用戶界面保護。通過組合不同的攻擊，欺騙電子郵件可以完全通過所有當前流行的電子郵件安全協議，并且收件人的MUA上不會顯示任何安全警告。

為了了解欺騙電子郵件攻擊對電子郵件生態系統的實際影響，對30種流行的電子郵件服務進行了大規模實驗，這些服務的用戶總數達數十億。此外還在不同的操作系統上測試了23個流行的電子郵件客戶端，以衡量攻擊對UI級別的影響。它們都容易受到某些類型的攻擊，包括信譽良好的電子郵件服務，例如Gmail和Outlook。已經向涉及的電子郵件服務提供商妥善報告了所有已發現的問題，并從其中的11家（例如Gmail，Yahoo，iCloud，Alibaba Cloud）獲得了積極的回應。

Attack Model and Experiments

A.攻擊模型

如上圖所示，電子郵件欺騙攻擊的攻擊模型包括一個受信任的電子郵件發送者（Alice，在a.com下擁有電子郵件帳戶），一個受害者接收者（Bob，在b.com下擁有一個電子郵件帳戶）和一個攻擊者（Oscar）。Oscar的目標是向Bob發送電子郵件，偽裝成Alice@ a.com并繞過所有安全驗證。通常，電子郵件欺騙攻擊有以下三種常見類型。

共享MTA攻擊（Shared MTA Attack）：假設Oscar擁有一個電子郵件帳戶（Oscar@ a.com），該帳戶不同于Alice的帳戶（Alice@ a.com）。Oscar可以通過修改Mail From / From / Auth username header，通過a.com的MTA發送欺騙性電子郵件。由于發件人的MTA IP信譽是影響垃圾郵件引擎決策算法的重要因素，因此欺騙電子郵件可以輕松進入受害者的收件箱。發件人的MTA的IP在a.com的SPF范圍內。發件人的MTA可能還會自動將DKIM簽名附加到欺騙電子郵件中。Oscar繞過SPF / DKIM / DMARC驗證并欺騙Alice@ a.com幾乎沒有困難。

直接MTA攻擊（Direct MTA Attack）：Oscar還可以通過自己的電子郵件服務器發送欺騙性電子郵件。請注意，發送者的MTA與接收者的MTA之間的通信過程沒有身份驗證機制。Oscar可以通過指定Mail From和From header來欺騙任意發件人。這種攻擊模型可以確保所有欺騙性電子郵件都到達收件人的MTA，而不會受到發件人MTA嚴格發送檢查（strict sending check）的影響。

轉發MTA攻擊（Forward MTA Attack）：Oscar可以通過濫用電子郵件轉發服務來發送欺騙性電子郵件。首先，Oscar將欺騙性電子郵件發送到Oscar@ a.com，這是轉發電子郵件服務上屬于Oscar的電子郵件帳戶。接下來，他可以配置轉發服務以自動將此欺騙郵件轉發給受害者（Bob@ b.com）。此攻擊模型具有三個主要優點。首先，此攻擊與共享MTA攻擊模式具有相同的優勢，因為收件人的MTA（b.com）認為電子郵件來自合法的MTA（a.com）。此外，此攻擊還可以繞過發件人MTA的嚴格發送檢查（例如，Mail From和From header之間不匹配）。最后，轉發服務可以為轉發的電子郵件提供更高的安全性認可（例如，添加不應添加的DKIM簽名）。

因此，發件人身份驗證問題可以分為四個階段，包括發送身份驗證，接收驗證，轉發驗證和UI呈現，這些階段可以緩解潛在的安全威脅。此外，將成功攻擊的目標定義如下：（1）接收者的MUA錯誤地呈現了發件人地址，因為它來自合法域名，而不是攻擊者的真實域名；（2）收件人的MTA錯誤地驗證了欺騙電子郵件的發件人；（3）收件人的MUA不顯示任何用于欺騙電子郵件的安全警報。

上圖顯示了使用直接MTA攻擊和轉發MT攻擊模型成功進行電子郵件發件人欺騙攻擊的示例。。所有這三種電子郵件安全協議都會為欺騙性電子郵件提供“pass”驗證結果。此外，接收方的MUA不顯示任何安全警報。受害人幾乎無法識別來自這種看似真實的欺騙電子郵件的任何攻擊痕跡。因此，即使對于具有技術背景的人來說，要弄清這種電子郵件是否是欺騙也是具有挑戰性的。

B.目標選擇

本研究系統地分析了30種電子郵件服務，包括最受歡迎的免費公共電子郵件服務，企業級電子郵件服務和托管的電子郵件服務。總共選擇22種流行的電子郵件服務，它們的用戶超過10億，他們的安全問題可能會使廣泛的普通用戶受到威脅。此外還選擇了Office 365，Alibaba Cloud和Coremail等5種流行的企業電子郵件服務，以測試對機構用戶的威脅影響。對于托管電子郵件系統，構建\部署和維護3個著名的電子郵件系統（即Zimbra，EwoMail，Roundcube）。此外，測試了針對不同桌面和移動操作系統中23個廣泛使用的電子郵件客戶端的攻擊，以評估對UI呈現的影響。

C.方法

這項工作旨在涵蓋整個電子郵件傳遞過程中所有可能的驗證問題。因此進行了五個步驟的安全性分析：首先系統地分析電子郵件規范。在語法方面提取ABNF規則，重點關注與身份驗證相關的header（例如Mail From / From / Helo / Sender）。在語義方面，關注是RFC中每個階段的電子郵件身份驗證。其次，收集合法的電子郵件樣本，并根據ABNF語法生成帶有認證相關header的測試樣本。由于普通郵件服務通常拒絕處理具有高度變形header的電子郵件，因此將指定某些header的值。例如，將domain的值限制為幾個著名的電子郵件域名（例如，gmail.com，icloud.com）。第三，在協議模糊化中引入了常見的變異方法，例如header重復，插入空格，插入Unicode字符，header編碼和大小寫變化。第四，使用生成的樣本在四個階段中測試目標電子郵件系統的安全驗證邏輯。最后分析并總結了使電子郵件發件人欺騙在實踐中成功的對抗技術。

D.實驗設置

成功的攻擊：如果滿足以下四個條件之一，則認為電子郵件欺騙攻擊成功。

（1）在電子郵件發送驗證階段，攻擊者可以任意修改標識符（例如，Auth username/ MAIL From/ From）。

（2）在電子郵件接收驗證階段，即使被欺騙域名已經部署了嚴格的SPF / DKIM / DMARC策略，收件人的MTA也會給出“none/pass”驗證結果。由于驗證結果并不總是顯示在電子郵件header中，因此可以通過檢查電子郵件是否已進入收件箱作為替代來推斷結果。此外，如果欺騙性電子郵件被放入垃圾郵件箱，則認為攻擊失敗，這意味著收件人的MTA已檢測到欺騙性并采取了防御措施。為避免意外情況，將每個攻擊重復三遍，以確保欺騙電子郵件實際上已滲透到安全協議中。只有所有三遍都起作用的攻擊才被視為成功攻擊。

（3）在電子郵件轉發階段，轉發者對轉發的電子郵件給予更高的安全性認可。此外，如果攻擊者無需任何身份驗證就可以將轉發的電子郵件自由配置到任何帳戶，則攻擊也被認為是成功的。

（4）在電子郵件UI呈現階段，顯示的電子郵件地址與真實電子郵件地址不一致。在此階段，由于僅需要檢查，因此使用IMAP協議的APPEND功能將欺騙的電子郵件發送到收件箱，因為只需要檢查UI呈現結果，而不是繞過垃圾郵件引擎。最后，收集信息并根據UI級別上的電子郵件瀏覽器端和電子郵件客戶端分析結果。

測量偏差最小化：首先，為了排除垃圾郵件檢測的影響，選擇了某個行業合作伙伴（一家著名的電子郵件提供商）提供的合法、良性和不敏感的電子郵件樣本作為欺騙電子郵件的內容。這些電子郵件的內容是合法且無害的，不能被視為垃圾郵件。其次，所有欺騙電子郵件都是從位于不同區域的15個IP地址發送的，間隔為10分鐘。此外為攻擊者的域名和IP地址部署MX / TXT / PTR記錄。第三，為了測試收件人的MTA如何處理帶有“fail” SPF / DMARC驗證結果的電子郵件，針對目標30個電子郵件服務進行了欺騙實驗，發現其中有23個拒絕帶有“fail”的SPF / DMARC驗證結果的電子郵件。其余的將它們標記為垃圾郵件。

E.實驗結果

發送方欺騙攻擊的實驗結果如上表，總結了以下實驗結果。首先，測量了這些電子郵件服務對電子郵件安全協議的部署和驗證。所有電子郵件服務都在發件人一方部署SPF協議，而只有23個服務部署全部三種協議。出乎意料的是，所有電子郵件服務都在接收方運行SPF，DKIM和DMARC檢測。但是，只有12個服務執行發件人不一致檢查。其次，所有目標電子郵件服務和電子郵件客戶端都容易受到某些類型的攻擊。最后，組合攻擊使攻擊者能夠偽造看上去更真實的欺騙電子郵件。具體攻擊方法（A1-A14）在下文中介紹。

Email Sender Spoofifing Attacks

將攻擊分為四類，分別對應于電子郵件傳遞過程中的四個身份驗證階段。

A.郵件發送認證中的攻擊

電子郵件發送驗證是確保電子郵件真實性的必要步驟。電子郵件發送身份驗證中的攻擊可能會濫用知名電子郵件服務的IP信譽。他們甚至可以繞過SPF / DKIM / DMARC協議的所有驗證，這對電子郵件安全生態系統構成了重大威脅。這些攻擊主要用于共享攻擊模型（Model a）。

電子郵件發送過程中有三個發件人標識符：(1) Auth username; (2) Mail From; (3) From。攻擊被認為是成功的，當它可以在電子郵件發送認證過程中任意控制這些標識符。

Auth username和MailFrom header之間不一致（A1）：如上圖a所示，攻擊者可以假裝是當前域名下的任何用戶，以發送在電子郵件發送身份驗證期間Auth username（Oscar@ a.com）和Mail From（Alice@ a.com）不一致的欺騙電子郵件。SMTP協議不提供任何內置的安全功能來保證auth username和Mail From header的一致性。因此，這種類型的保護僅取決于電子郵件開發人員的軟件實現。

在欺騙實驗中，大多數電子郵件服務都沒有發現此類問題，并禁止用戶發送與其原始身份不一致的電子郵件。但是，這種類型的問題仍然出現在某些著名的公司電子郵件軟件（即Zimbra，EwoMail）中。在默認安全配置下，這兩個電子郵件服務容易受到攻擊。電子郵件管理員需要升級其安全配置，以手動防止此類問題。

MailFrom與From之間的不一致（A2）:攻擊者可以發送帶有不同Mail From和From header的欺騙電子郵件。上圖b顯示了這種類型的攻擊。盡管允許某些用戶使用電子郵件別名來發送帶有不同的From header的電子郵件，但不應允許任何用戶將From header隨意修改為任何值（例如admin@ a.com）以防止受到攻擊。僅應在有限的合法值內設置From header。許多流行的電子郵件服務（例如Outlook，Sina，QQ郵件）和大多數第三方電子郵件客戶端（例如Foxmail，Apple Mail）僅顯示From header，而不顯示Mail From header。對于具有不同Mail From和From header的郵件，受害者甚至無法在MUA上看到任何安全警報。

RCPT To和To header之間也存在類似的不一致。在現實世界中，有些場景會導致不一致，例如電子郵件轉發和密件抄送。但是，這種靈活性增加了攻擊面并引入了新的安全風險。例如，即使電子郵件的From header不是受害者的地址，攻擊者也可以將電子郵件發送給受害者。在這種情況下，攻擊者可以進一步使用此方法來獲取通常無法獲得的帶有DKIM簽名的欺騙電子郵件，這對于進一步的攻擊很有幫助。單獨使用時，此技術可能無效，但與其他攻擊技術結合使用時，通常可以達到出色的欺騙效果。

在實驗中，有14種電子郵件服務容易受到此類攻擊。此外，還發現某些電子郵件服務（例如Outlook，Zoho，AOL，Yahoo）已經意識到了這些風險，并實施了相應的安全限制。他們拒絕在SMTP發送過程中發送帶有不一致的MailFrom和From header的電子郵件。但是，仍然可以通過兩種類型的攻擊（即A4，A5）來繞過這些防御措施。例如，可以在Yahoo中發送帶有From header為< Oscar@ a.com>和 From header為< Alice@ a.com，Oscar@ a.com>的欺騙電子郵件，這引入了另一種歧義源，并最終繞過了電子郵件協議驗證。因此，即使發件人已經部署了相關的安全措施，仍然可能發送這種欺騙性電子郵件。

B.電子郵件接收驗證中的攻擊

SPF，DKIM和DMARC是用于抵抗電子郵件欺騙攻擊的流行機制。如果攻擊者可以繞過這些協議，則也可能對電子郵件安全生態系統構成嚴重的安全威脅。可以使用三種攻擊模型來發起這種類型的攻擊：共享MTA攻擊，直接MTA攻擊和轉發MTA攻擊。當接收方的MTA錯誤地獲得“none/pass”驗證結果時，攻擊成功。

空Mail From攻擊（A3）：RFC 5321明確描述了允許一個空的Mail From，主要用于防止回彈回送并允許某些特殊消息。但是，也可以濫用此功能來發起電子郵件欺騙攻擊。如下圖所示，攻擊者可以發送帶有空的Mail From header的電子郵件，而From header構成了Alice的身份（Alice@ a.com）。

SPF協議規定，如果Mail From header為空，則接收者的MTA必須根據Helo字段完成SPF驗證。但是，現實生活中濫用Helo字段使某些電子郵件服務違反了標準并采取了更為寬松的驗證方法，因此，當收件人處理這些電子郵件時，他們無法基于Helo字段完成SPF驗證，而是直接返回“none”。此類錯誤使攻擊者可以繞過SPF保護。結果，攻擊者可以將此攻擊的SPF結果從“fail”更改為“none”。

13種電子郵件服務（例如Yahoo，Yeah，126，Aol）容易受到此類攻擊。幸運的是，已經有17個電子郵件服務解決了此類安全問題，其中有5個（例如Zoho.com，iCloud.com，exmail.qq.com）已將此類電子郵件丟棄為垃圾郵件。

多From header（A4）：From header有多種變形，例如在From之前和之后添加空格，大小寫轉換以及插入不可打印的字符。如上圖所示，攻擊者可以構造多個From header來繞過安全策略。RFC5322表示通常會拒絕具有多個From字段的電子郵件。但是，仍然有一些電子郵件服務無法遵循協議，無法接受帶有多個From header的電子郵件。它可能會在電子郵件接收驗證階段引入不一致之處，從而可能導致其他安全風險。上圖c顯示了一個示例，顯示的發件人地址為Alice@ a.com，而收件人的MTA可以使用Oscar@ attack.com進行DMARC驗證。

只有4個郵件服務（即Gmail，Yahoo，Tom和Aol）拒絕具有多個From header的電子郵件，而這種攻擊會影響19個郵件服務。大多數經過測試的電子郵件服務傾向于在網絡郵件上顯示第一個From header，而6個服務（例如iCloud，Yandex，Alibaba Cloud）選擇顯示最后一個From header。此外，有7家供應商已針對此類攻擊制定了特定的安全法規，例如在網絡郵件上同時顯示兩個發件人地址（例如QQMail，Coremail）或將此類電子郵件放入垃圾郵件文件夾（例如Outlook，rambler.ru）。

多郵件地址（A5）：使用多個電子郵件地址也是繞過協議驗證的有效技術。多個地址的使用最早是在RFC2822中提出的，并在RFC5322中仍被明確允許。它適用于以下情況：具有多個作者的電子郵件應在發件人中列出所有作者。然后，添加“Sender”字段以標記實際發件人。如上圖a所示，攻擊者可以使用多個電子郵件地址（< Alice@a.com>，< Oscar@ attack.com>）繞過DMARC驗證。此外，還可以對這些地址進行基于規則的更改，例如[Alice@ a.com],\< Oscar@ attack.com>。

15個郵件服務（例如QQ郵件，21cn.com和onet.pl）仍將接受此類電子郵件。只有4個服務（例如Gmail和Mail.ru）直接拒絕這些電子郵件，其他5個服務（例如zoho.com，tom.com，outlook.com）將它們放入垃圾郵件，其余6個服務（例如139.com ，cock.li和Roundcube）顯示所有這些地址，從而使欺騙電子郵件更難以欺騙受害者。

解析不一致攻擊（A6）：Mail From和From header為富文本格式，具有非常復雜的語法格式，正確解析顯示名稱和真實地址是一項挑戰。這些不一致之處可以使攻擊者繞過身份驗證并欺騙其目標電子郵件客戶端。

郵箱地址是這兩個header的基本組成部分之一。首先，當郵箱地址包含在“ <”and”>”中時，允許其在真實發件人地址的前面具有路由部分。因此，郵箱（< @ a.com，@ b.com：admin@ c.com>）仍然是合法地址。其中，@ a.com，@ b.com是路由部分，“ admin@ c.com”是真實發件人的地址。其次，允許使用郵箱列表和地址列表并且它們可以具有“null”成員，例如< a@ a.com>，< b@ b.com>。第三，注釋是用括號括起來的字符串。允許在本地部分和域的句點分隔的元素之間，例如< admin(username)@ a.com(domainname)>。最后，在From header中有一個可選的顯示名稱。它指示發件人的姓名，顯示給收件人。下圖顯示了基于解析不一致的三種類型的攻擊。

截斷字符是終止字符串分析的一系列字符。當從電子郵件header中解析和提取目標域名時，被截斷的字符將結束解析過程。上圖d顯示，當從字符串“ admin@ a.com\x00@ attack.com”解析目標域名時，程序獲取的域名不完整（a.com）。攻擊者可以使用這些技術來繞過電子郵件安全協議的驗證。總的來說，這項工作在電子郵件字符串解析過程中發現了三種截斷的字符。首先，NUL（\ x00）字符可以使用C編程語言終止字符串，在電子郵件字段中具有相同的作用。其次，一些看不見的Unicode字符（例如\uff00-\uffff,\x81-\xff）也可以終止字符串解析過程。第三，某些語義字符，例如“ “[,],{,},\t,\r,,;”，可用于指示詞法分析中的標記化點。同時，這些字符也影響字符串的解析過程。發現在這種攻擊下，有13個電子郵件服務在UI呈現階段存在問題。對于Gmail和Yandex，可以使用這些攻擊技術繞過DMARC。

基于編碼的攻擊（A7）：RFC 2045（MIME）描述了一種表示文本正文部分的機制，這些正文部分以各種字符集編碼。這些部分的ABNF語法如下:=?charset?encoding?encoded-text?=。“charset”字段指定與未編碼文本關聯的字符集；“ encoding”字段指定編碼算法，其中“ b”代表base64編碼，“ q”代表帶引號的可打印編碼；“encoded-text”字段指定編碼的文本。攻擊者可以使用這些編碼的地址來逃避電子郵件安全協議的驗證。上圖a顯示了這種攻擊的細節。對于諸如From:=?utf-8?b?QWxpY2VAYS5jb20=?=這樣的編碼地址，大多數電子郵件服務在驗證DMARC協議之前不會對地址進行解碼，因此無法提取準確的域并在其中獲得“無”以下DMARC驗證。但是，某些電子郵件服務在MUA上顯示解碼的發件人地址（Alice@ a.com）。此外，該技術可以與截斷的字符串結合使用。如上圖b所示，攻擊者可以將From header構造為“ b64(Alice@ a.com>b64(\uffff)@ attack.com”）。電子郵件客戶端程序可能會獲得不完整的用戶名（即Alice@ a.com），但它仍將使用攻擊者的域（attack.com）進行DMARC驗證。7個電子郵件服務受此漏洞的影響，其中包括一些擁有超過十億用戶的流行服務（例如Outlook，Office 365，Yahoo）。

子域攻擊（A8）：攻擊者可以從不存在的知名電子郵件服務的子域（沒有MX記錄）發送欺騙電子郵件（例如admin@ mail.google.com）。因此，沒有相應的SPF記錄。欺騙電子郵件僅收到none”驗證結果，收件人的MTA不會直接拒絕它。盡管父域（例如google.com）部署了嚴格的電子郵件策略，但攻擊者仍然可以這種方式進行攻擊。不幸的是，許多公司使用子域來發送業務訂閱電子郵件，例如Paypal，Gmail和Apple。結果，普通用戶傾向于信任此類電子郵件。

不幸的是，RFC 7208聲明不鼓勵使用通配符記錄來發布SPF記錄。很少有電子郵件管理員在現實世界中配置通配符SPF記錄。此外，收件人的MTA通常可以拒絕來自沒有MX記錄的域的電子郵件。但是RFC 2821提到，當域沒有MX記錄時，SMTP會假定A記錄就足夠了，這意味著具有A記錄的任何域名都可以被視為有效的電子郵件域。此外，許多知名網站都部署了通配符DNS A記錄，從而使這種攻擊更加適用。結果，收件人的MTA很難確定是否拒絕此類電子郵件。

實驗結果表明，有13種電子郵件服務容易受到此類攻擊。在實驗中，只有一個電子郵件服務（Mail.ru）為SPF記錄部署了通配符DNS條目。默認情況下，為組織域設置的DMARC策略應適用于任何子域，除非已為特定子發布了DMARCrecord -領域。但是，實驗結果表明，即使接收方的MTA進行了DMARCcheck，攻擊仍然有效。

C.電子郵件轉發驗證中的攻擊

這項工作表明，攻擊者可以濫用電子郵件轉發服務來發送欺騙性電子郵件，而這種欺騙性電子郵件將在sharedMTA攻擊模型中失敗。此外，轉發服務可以為轉發的電子郵件提供更高的安全性認可。攻擊者可以利用這兩種情況發送欺騙性電子郵件。

未經授權的轉發攻擊（A9）：如果攻擊者可以在不進行任何身份驗證驗證的情況下將轉發的電子郵件自由配置到任何帳戶，則電子郵件服務存在未經授權的轉發問題。首先，攻擊者應在電子郵件轉發服務上擁有一個合法的電子郵件帳戶。因為這些電子郵件是從一個熱門的電子郵件轉發MTA發送的，因此收件人的MTA通常會接受此類電子郵件。當目標域名與轉發域名相同時，還可以利用轉發服務繞過SPF和DMARC協議。此攻擊如下圖所示。基于此攻擊，攻擊者可以濫用眾所周知的MTA的信譽來制作真實的欺騙性電子郵件。

在實驗目標中，有12個電子郵件服務具有此類漏洞。7電子郵件服務不提供電子郵件轉發功能。其他電子郵件服務已經意識到了風險，并進行了相應的轉發驗證以解決此問題。

DKIM簽名欺騙攻擊（A10）：轉發服務可以為轉發的電子郵件提供更高的安全性認可。但是攻擊者可能濫用此功能來發送欺騙性電子郵件。如果轉發的電子郵件沒有DKIM簽名或之前未通過DKIM驗證，則轉發者不應添加其域名的DKIM簽名。否則，攻擊者可以欺騙合法DKIM簽名的轉發服務。但是，RFC 6376和RFC 6377均建議轉發者將其簽名添加到轉發的電子郵件中。這進一步導致更多的電子郵件服務出現此類問題。

上圖說明了攻擊的完整過程。電子郵件轉發服務（a.com）無需嚴格驗證即可對所有轉發的電子郵件簽名并添加DKIM簽名。首先，攻擊者可以在電子郵件轉發服務下注冊一個帳戶（Oscar@ a.com）。其次，他可以將所有接收的電子郵件配置為轉發到另一個攻擊者的電子郵件地址（Oscar@ c.com）。然后，攻擊者可以通過直接MTA攻擊模型通過From: Alice@ a.com, To: Bob@ b.com到Oscar@ a.com發送欺騙電子郵件。轉發服務（a.com）在此欺騙電子郵件中添加了合法的DKIM簽名。結果，攻擊者收到了帶有由a.com簽名的合法DKIM簽名的欺騙電子郵件。在實驗中，Alibaba Cloud，Office 365和Yahoo Email都容易受到此類攻擊。

ARC問題（A11）：ARC是一種新提出的協議，它提供了一條信任鏈，可以在電子郵件轉發過程中鏈接SPF，DKIM和DMARC的驗證結果。在實驗中，只有三個電子郵件服務（即Gmail，Office 365和Zoho）部署了ARC協議。但是研究發現Office 365和Zoho都在ARC協議實現方面存在安全問題。此外，除了A10攻擊外，ARC無法防御上面討論的大多數攻擊。

對于Zoho電子郵件服務，如果電子郵件未通過發件人不一致檢查，它將為用戶顯示警報。但是，Zoho的ARC實施存在錯誤。當通過Gmail自動將欺騙性電子郵件轉發到Zoho郵箱時，Zoho添加的ARC-Authentication-Results（AAR）header顯示了錯誤的“通過” DMARC驗證結果。更糟糕的是，這種錯誤的ARC實現也可能繞過發送方不一致檢查。Zoho不會向用戶顯示有關此欺騙電子郵件的警報。Office 365在ARC的實現中也有錯誤。它在AAR標header中傳遞了SPF，DKIM和DMARC的錯誤驗證結果。這將破壞ARC信任鏈，從而引入更多的安全風險。

D.電子郵件UI呈現中的攻擊

電子郵件系統的最后也是最關鍵的部分是確保正確呈現電子郵件。一旦攻擊者可以在此階段采取防御措施，就很容易在不知不覺中通過欺騙郵件欺騙普通用戶。顯示的地址是MUA上顯示的發件人地址，但實際地址是SMTP通信中使用的發件人身份（From）。如果攻擊者可以使顯示的地址與真實地址不一致，則認為攻擊成功。此外，某些MUA向未通過發件人不一致檢查的電子郵件添加安全指示符。如果攻擊者可以繞過發件人的不一致檢查，它也被視為一種有效的攻擊技術。

電子郵件UI呈現階段存在各種攻擊，其中一些類似于前面討論的A6，A7攻擊，不同之處在于UI級別攻擊的目標是繞過發件人不一致檢查并欺騙為用戶顯示的電子郵件地址，而不是繞過三個電子郵件安全性協議的驗證。因此，通常構造模糊From header而不是Mail From header。

IDN同形異義詞攻擊（A12）：同形異義詞攻擊是一個已知的Web安全問題，但尚未系統地討論其對電子郵件系統的安全風險。熱門電子郵件提供商逐漸支持來自國際化域名（IDN）的電子郵件，此攻擊可能會產生更廣泛的安全影響。

Punycode是一種將無法以ASCII顯示的單詞轉換為Unicode編碼的方法。值得注意的是，當原始地址不同時，Unicode字符在屏幕上的外觀可能相似。上圖顯示了一個欺騙電子郵件，該電子郵件似乎來自地址（admin@ paypal.com），但實際上來自地址（admin@ xn–aypal-uye.com）。

現代瀏覽器已針對IDN同形異義詞攻擊實施了一些防御措施。例如如果域標簽包含多種語言的字符，則不應呈現IDN，不幸的是電子郵件系統中幾乎沒有類似的防御措施。實驗結果表明，10種電子郵件服務（例如Gmail，iCloud，Mail.ru）顯示出支持IDN電子郵件。當前，只有Coremail可以修復此漏洞。基于本研究，Coremail在地址欄中的Unicode字符前后添加了空格。這樣，用戶可以輕松區分ASCII字符和Unicode字符，以防止此類攻擊。

UI呈現丟失攻擊（A13）：本文還發現許多字符會影響MUA的呈現。在呈現過程中可能會丟棄某些字符。此外，某些字符還可能導致電子郵件地址被截斷（類似于攻擊A6）。這些字符包括不可見字符（U+0000-U+001F,U+FF00-U+FFFF）和語義字符（@,:,;,”）。例如，MUA呈現地址admin@ gm@ ail.com作為admin@ gmail.com。仍有12種電子郵件服務（例如zoho.com，163.com，sohu.com）容易受到這類攻擊。其他服務拒絕接收此類電子郵件，或者只是將此類電子郵件扔入垃圾郵件箱。

RTRO（Right-to-left Overrid）寫攻擊（A14）：設計了幾個字符來控制字符串的顯示順序。其中之一是“RIGHT-TO-LEFT OVERRIDE”字符，U+202E告訴計算機以從右到左的順序顯示文本。它主要用于書寫和閱讀阿拉伯語或希伯來語文本。盡管此攻擊技術在其他地方已經討論過，但尚未充分研究其對電子郵件欺騙的安全風險。攻擊者可以將字符串構造為\u202emoc.a@\u202dalice，該字符串顯示為Alice@ a.com。由于帶有RTL字符的欺騙性電子郵件可能會直接丟入垃圾郵件箱，因此通常對有效載荷（采用utf-8模式）進行編碼以進行攻擊。11種電子郵件服務（例如Outlook，Yahoo，Yandex）仍然容易受到此攻擊。10個服務（例如cock.li，daum.net，onet.pl）無法正確呈現此類電子郵件地址。其他電子郵件服務直接拒絕了此類郵件。

Combined Attacks

根據電子郵件傳遞過程中的四個認證階段，將攻擊分為四類。但是，這些攻擊有一定的局限性。首先，某些攻擊（例如A2，A3）可能對配方產生欺騙作用。但是，他們無法繞過所有電子郵件欺騙保護。例如，通過來自攻擊者的空郵件（A3）的欺騙電子郵件繞過SPF驗證，但在DMARC驗證中失敗。此外，大多數電子郵件供應商已修復了單獨進行的攻擊，該攻擊可以繞過實驗中的所有三個電子郵件安全協議。因此，在實踐中組合不同階段的多種攻擊更為可行。通過結合不同攻擊技術的cocktail組合攻擊，可以輕松構建可以完全通過三種電子郵件安全協議和用戶界面保護驗證的欺騙電子郵件。最后，此欺騙電子郵件與合法電子郵件在收件人的MUA上沒有顯示任何區別。通過在4個身份驗證階段組合3種類型的攻擊模型和14種攻擊技術，可以實現多種可行的組合攻擊。選擇兩個最具代表性的示例來說明組合欺騙攻擊的效果，下表列出了兩個示例的關鍵信息。

相同攻擊模型下的組合攻擊：總共確定了14種電子郵件欺騙攻擊技術，其中14種攻擊技術可以在相同的攻擊模型下進行組合以達到更好的攻擊效果。此外，盡管某些供應商可以通過一項安全檢查來修復漏洞，但攻擊者可以準確地組合其他攻擊技術來繞過相應的安全檢查。

上圖顯示了共享MTA攻擊模型下的代表性示例。Yahoo電子郵件執行簡單的發件人檢查策略以防御A2攻擊。它禁止用戶使用不同的Mail From和From header發送電子郵件。但是，攻擊者仍然可以通過A4攻擊繞過此發件人檢查策略。具體來說，可以發送帶有第一個發件人header（Oscar@ yahoo.com）的欺騙郵件，該郵件與Mail From頭相同，然后添加第二個發件人header（Admin@ paypal.com）。iCloud不會拒絕具有多個From header的此類欺騙電子郵件。更糟糕的是，iCloud使用第一個From header執行DMARC驗證并通過yahoo.com獲得“pass”結果，而第二個From（Admin@ paypal.com）header則顯示在網絡郵件的用戶界面上，供用戶使用。因此，這種組合攻擊最終可能繞過所有三個電子郵件安全協議并欺騙MUA。

不同攻擊模型下的組合攻擊：攻擊者還可以通過組合不同的攻擊模型來進行更有效的攻擊。電子郵件系統是具有多方信任鏈的復雜生態系統，它依賴于由多方實施和部署的安全措施。在不同的攻擊模型下，多個參與方可能具有不同的漏洞。例如，如果電子郵件服務的發送MTA在發送身份驗證時進行嚴格檢查，則很難通過共享MTA攻擊模型進行攻擊。但是，一旦在其他階段未能提供正確且完整的安全防御解決方案，攻擊者仍可以繞過并通過其他兩種攻擊模型發送欺騙性電子郵件。

上圖通過組合直接MTA和正向MTA攻擊模型顯示了成功的欺騙攻擊。例如，Oscar使用攻擊技術（A2，A3）發送帶有空Mail From和精心構造的From header的欺騙電子郵件。與受害者的帳戶不同，Oscar擁有一個合法帳戶（Oscar@ aliyun.com）。因此，Oscar可以將該帳戶配置為自動將接收到的電子郵件轉發到他的一個帳戶（Oscar@ attack.com）。Alibaba Cloud服務為所有轉發的電子郵件添加了DKIM簽名，而無需進行必要的驗證檢查（A10）。通過電子郵件發送合法的DKIM簽名。然后，Oscar可以通過直接MTAattack模型通過MailFrom:< admin@ attack.com>頭發送此欺騙電子郵件，如上圖b所示。

對于此欺騙電子郵件，SPF協議驗證attack.com域，而DKIM和DMARC協議驗證aliyun.com域。因此，該電子郵件可以通過所有三個電子郵件安全協議，并進入Gmail收件箱。此外，沒有電子郵件服務會向用戶顯示有關具有三種協議的不同已驗證域的電子郵件的警報。這進一步使這類攻擊對普通用戶更具欺騙性。

Root Causes and Mitigation

A.根本原因

如前所述，電子郵件系統的安全性依賴于多個由多方分別實施的保護策略。因此，這些多方之間的不一致可能會造成更多漏洞，并導致嚴重的欺騙攻擊。確定攻擊的根本原因如下。

多協議之間的弱鏈接：由于電子郵件規范的含糊不清，缺乏最佳實踐以及MIME標準的復雜性，協議驗證過程是身份驗證鏈中的薄弱環節之一。在SMTP通信過程中，協議的多個字段包含發送者的身份信息（即Auth username，MAIL From, From, Sender）。這些字段的不一致為電子郵件欺騙攻擊提供了基礎。

SPF，DKIM和DMARC均已提出并進行了標準化，以防止從不同方面進行電子郵件欺騙攻擊。但是，只有在所有協議都得到很好實施的情況下，電子郵件系統才能防止電子郵件欺騙攻擊。在這種基于鏈的身份驗證結構中，任何鏈接的失敗都會使身份驗證鏈無效。

多角色之間的弱鏈接：在電子郵件系統中，自動確定發件人的身份是一個復雜的過程。它涉及四個重要角色：發送者，接收者，轉發者和UI渲染器。標準安全模型的假設是，每個角色都正確開發并實施相關的安全驗證機制以提供整體安全性。但是，許多電子郵件服務在所有四個角色中均未實現正確的安全策略。

許多電子郵件服務（例如iCloud，Outlook，Yeah.com）在電子郵件轉發階段并未注意到由未授權轉發攻擊（A9）引起的安全風險。另外，該規范沒有規定電子郵件安全驗證中四個角色（即發送者，接收者，轉發者和UI渲染器）的任何明確職責。

多服務之間的弱鏈接：不同的電子郵件服務通常具有不同的配置和實現方式。某些服務（例如Gmail，Yandex.com）禁止發送帶有歧義header的電子郵件，但會接收。相反，某些公司（例如Zoho，Yahoo）傾向于允許發送帶有不明確header的電子郵件，但在電子郵件接收驗證階段進行非常嚴格的檢查。安全策略之間的差異使攻擊者可以將來自具有容忍發送策略的服務中的欺騙電子郵件發送給接收策略寬松的服務。

此外，一些電子郵件提供商在處理帶有模糊header的電子郵件時會偏離RFC規范。當MUA處理帶有多個From header的郵件時，某些服務（例如Outlook，Mail.ru）會顯示第一個header，而其他服務（例如iCloud，yandex （.com）顯示最后一個header。此外，不同的供應商都不同程度地支持Unicode字符。一些供應商（例如21cn.com，Coremail）已經意識到由Unicode字符引起的新安全挑戰，但是一些供應商（例如163.com，yeah.net）則不知道。特別是，某些（例如zoho.com，EwoMail）甚至還不支持Unicode字符的呈現。

最后，只有少數電子郵件提供商顯示可視UI通知，以警告用戶欺騙電子郵件，并且只有12個供應商實施發件人不一致檢查。特別是，由于缺乏統一的實施標準，實際中的發件人不一致檢查非常多樣化。缺乏有效和合理的電子郵件安全通知機制也是造成電子郵件欺騙屢禁不止，卻從未消除的原因之一。

B.緩解

由于電子郵件欺騙是一個涉及多方的復雜問題，因此需要多方協作來解決相關問題。

更精確的標準：請注意，電子郵件提供商可能無法通過電子郵件協議中含糊不清的定義來提供安全可靠的電子郵件服務。因此，提供更準確的電子郵件協議描述對于消除多方協議的實踐中的不一致是必要的。例如，DKIM標準應指定何時應將DKIM簽名添加到轉發的電子郵件中。對于轉發者而言，添加DKIM簽名以提高電子郵件的信譽是合理的；但是，他們不應在從未通過DKIM驗證的電子郵件中添加DKIM簽名。

UI通知：電子郵件UI呈現是影響用戶對電子郵件真實性的感知的重要部分。不幸的是，在實驗中，大多數電子郵件瀏覽器端和電子郵件客戶端僅顯示From header，而沒有更多身份驗證詳細信息。因此，普通用戶很難判斷電子郵件的真實性。此外，某些視覺攻擊（例如A12，A13）無法在協議級別進行防御。一種有效的防御方法是提供用戶友好的UI通知，并警告用戶其收到的電子郵件可能是電子郵件欺騙。

如上圖所示，用戶可以根據UI通知直觀地識別所接收的電子郵件是否包含惡意行為。著名的電子郵件服務提供商Coremail已采納了本研究的建議，并在其Webmail和電子郵件客戶端上實現了UI通知。此外，本研究還發布了針對Chrome的Chrome擴展程序，名為“ NoSpoofing”（ https://chrome.google.com/webstore/detail/nospoofing/ehidaopjcnapdglbbbjgeoagpophfjnp ）的評估工具。已經在GitHub（https://github.com/mo-xiaoxi/EmailSpoofingTestTool ）上公開發布了測試工具，供電子郵件管理員評估和提高其安全性。配置目標電子郵件系統信息后，該工具可以與目標系統進行交互，并評估目標系統是否容易受到攻擊。已經向30個相關的電子郵件供應商詳細報告了此工作中發現的7個披露漏洞。本項目一直在與這些實體聯系，以幫助他們緩解檢測到的威脅，聯系結果總結如下。

Alibaba Cloud對攻擊很感興趣，并與本文研究者就規范進行了深入討論。RFC 6376建議在電子郵件轉發階段添加DKIM簽名以提高電子郵件的可信度。他們現在已經認識到在沒有驗證的情況下添加DKIM簽名的風險，并承諾評估和修復此類問題。他們還建議本文研究者聯系相關RFC的作者，以達成一致的解決方案。Gmail已經確認本文的報告，并將在后續更新中解決相關問題。他們聯系本文研究者討論這些安全問題背后的根本原因。iCloud與本文研究者討論了攻擊的詳細信息及其潛在后果。特別是，蘋果iCloudEmail通過與本項目的合作已經解決了相關的安全問題。Sina認為此問題是高風險漏洞，并在內部評估了相應的保護措施，提供了≈$ 90的獎勵。Yandex接受本研究的報告并確認漏洞，同時提供200美元的獎金用于感謝。Yahoo確認了該漏洞，但是聲稱這不是直接的風險。Coremail感謝本研究的報告，尤其感謝UI攻擊的問題。為了解決這些安全問題，采納了建議并開始實施UI通知，以保護用戶免受電子郵件欺騙攻擊。QQ Mail和163.com感謝了本研究的工作，并告知將通過反垃圾郵件解決這些安全問題。Outlook和Mail.ru聲稱嚴格按照RFC標準運行其電子郵件服務，將這些問題歸類為網絡釣魚電子郵件，并承諾將更加關注此類攻擊的影響。已與其他相關的電子郵件供應商聯系，并期待收到他們的反饋。

Conclusion

本文探討了電子郵件生態系統中鏈式身份驗證結構的漏洞。具體而言，在此基于鏈的結構下，任何部分的錯誤都可能破壞整個鏈，即電子郵件的真實性取決于電子郵件認證鏈中最弱的鏈接。本文提出了一系列新攻擊，可以通過對電子郵件傳遞過程的系統分析來繞過SPF，DKIM，DMARC和用戶界面保護。此外，對30種流行的電子郵件服務和23個電子郵件客戶進行了大規模分析。實驗結果表明，它們所有人都容易受到新攻擊的攻擊，其中包括著名的電子郵件服務，例如Gmail和Outlook，許多電子郵件服務尚未實施適當的保護措施。本研究集中于欺騙攻擊對整個基于鏈的電子郵件身份驗證過程的影響，分析了這些攻擊的根本原因，并將問題報告給了相應的電子郵件服務提供商。還為電子郵件協議設計者和電子郵件提供商提出了緩解措施，以防御電子郵件欺騙攻擊。本文工作致力于幫助電子郵件行業更有效地保護用戶免受電子郵件欺騙攻擊，并改善電子郵件生態系統的整體安全性。