作者:邵喻美 / 臺灣大學計算機及資訊網路中心資訊網路組程式設計師
電子郵件欺騙(Email Spoofing)是透過偽造寄件者名稱的郵件,誤導收件者以為信件來自認識的人或組織,進而相信其宣稱的內容,以達到竊取機敏資料或植入惡意程式的目的。此種冒名郵件詐騙事件影響層面廣大,歷年來從個人、各種規模的企業組織,到國內外政府機構都曾發生過。本文將針對Email Spoofing的定義與實例、防範機制標準與實際運用情境一一介紹。
什麼是Email Spoofing?
電子郵件欺騙(Email Spoofing)是指電子郵件以偽造的寄件者名稱,意圖讓收件者誤以為信件來自認識的人或組織,進而比較容易相信其宣稱的內容,導致誤信而提供重要資訊或操作點選連結。網際網路通行的電子郵件協定由來已久,但協定本身並未包含驗證電子郵件來源的機制,因此很容易被垃圾信件或其他有心人士用來惡意修改電子郵件的來源資訊。
網際網路上透過冒名信件行使詐騙目的的情況由來已久,至今仍屢見不鮮,最常見的不外乎:騙錢、騙個資帳密、入侵系統。例如假冒郵局、UPS通知使用者繳費以取回先前無法遞送的包裹,或者頂著Apple、Spotify名義通知使用者無法成功扣款需更新信用卡或帳戶資訊等。近年來也常見駭客以收件者名義寄信,讓收到信的人以為信件來自自己的信箱,產生自己信箱真的被盜用的假象,進而相信威脅內容而依照指示支付比特幣。
以本校郵件系統而言,經常會收到從校外郵件伺服器寄來顯示寄件者為某@ntu.edu.tw的信件,尤其是冒充admin@ntu.edu.tw、helpdesk@ntu.edu.tw、noreply@ntu.edu.tw等看似來自本校系統管理者的信件,內容可能是警告、通知類型訊息,要收件者點選信中URL連結,或打開附件。但實際上並非真有此郵件地址,或者並非該寄件者透過校外郵件系統寄信。
防範冒名信件(Spoofing)的網際網路標準
對於一般使用者而言,防範冒名郵件首要能夠看穿信件來源資訊,但並非所有人都具備足以正確判斷的能力。由於早年制訂的SMTP(Simple Mail Transfer Protocol)電子郵件協定未考慮安全機制,為了遏止冒名電子郵件,網際網路標準團體開始提出郵件安全相關協定,經過多年來的討論及修改,陸續皆已制訂為標準。以下就針對近年來已逐漸普遍採用的郵件安全協定一一介紹:
SPF(Sender Policy Framework)
SPF(制訂於RFC4408)是一套電子郵件驗證機制標準,用來確認電子郵件的確是由寄件來源網域所授權的電子郵件伺服器發出,可防範網域遭到假冒,以避免有心人士假冒身份寄送釣魚或垃圾郵件。以Gmail為例,自2022年11月起,所有向Gmail個人帳戶傳送電子郵件的新寄件者都必須正確設定SPF,否則信件會被歸類到垃圾郵件,或者直接拒絕並退信。
SPF的運作方式是透過DNS TXT紀錄宣告認可的傳送郵件伺服器IP範圍,以及指示收信伺服器該如何處理經過SPF檢查的信件。收件伺服器在收到看似來自某網域的郵件時,如果有啟用SPF檢查,就會透過查詢寄件網域的DNS TXT或SPF記錄,執行SPF驗證該郵件是否確實是由對方網域授權的伺服器傳送。根據DNS的SPF TXT紀錄,SPF檢查結果可能是Pass、Soft Fail、Fail,收信伺服器可根據檢查結果決定將信件放行、接受或標記為垃圾郵件、或者直接拒絕來自未經授權主機的郵件。
以實際運作範例說明,臺大DNS伺服器上已宣告以下TXT記錄:
ntu.edu.tw. IN TXT "v=spf1 a:mail.ntu.edu.tw a:ccms.ntu.edu.tw a:ms
a.ntu.edu.tw a:smtps.ntu.edu.tw a:wmail1.cc.ntu.edu.tw a:wmail2.cc.ntu.edu.tw a:
ccsun55.cc.ntu.edu.tw a:ccsun56.cc.ntu.edu.tw a:v236.cc.ntu.edu.tw ~all"
記錄中a表示ntu.edu.tw網域授權的郵件主機域名,最後的~all表示soft fail,也就是收信方對於宣稱來自 @ntu.edu.tw 的信件若未通過SPF檢查(亦即並非來自TXT記錄中宣告的郵件主機),可接受也可標記為垃圾郵件。如此設定是因為臺大除了宣告的計中郵件主機外,校內還有單位自行架設的郵件伺服器也會以 @ntu.edu.tw 名義寄信,若設定 -all 硬拒絕,會導致這些單位寄出去的郵件被收信端因SPF檢查失敗而被直接退信。
DKIM(DomainKeys Identified Mail)
DKIM網際網路標準(制訂於RFC6376)也是電子郵件驗證機制,採取公開金鑰加密基礎提供數位簽章與身分驗證的功能,在外寄郵件中加入數位簽名。收信伺服器收到經過DKIM簽署的郵件時,可驗證該郵件確實來自寄件者,而非冒用身分的第三者,DKIM也可以達到確認郵件內容在寄送過程中未遭到更改的作用。
DKIM機制運作方式分成簽署及驗證階段,首先在寄件伺服器端要先產生公鑰(public key)及私鑰(private key),並且啟用DKIM機制。然後透過DNS DKIM記錄宣告公鑰資訊。之後在發送每封郵件時由寄件伺服器在電子郵件的標頭插入經過私鑰簽署的DKIM-Signature電子簽名資訊,然後將信件依正常方式傳送出去。對於有啟用DKIM檢查機制的收信伺服器端,在收到經過DKIM簽署的信件後,會透過DNS查詢寄件者網域的DKIM記錄,取得上面宣告的公鑰資訊,然後對郵件執行簽章解碼,如果公鑰與私鑰能夠配對成功,代表郵件確實為原始寄信伺服器所發出。
以Gmail為例,近年來大力推行SPF及DKIM郵件驗證機制,也逐步要求寄到Gmail的信件必須符合SPF或DKIM標準,設定Google Workspace時也會自動建立DKIM金鑰,並將金鑰加入網域的DNS記錄。但由於啟動DKIM機制必須對每封信進行金鑰簽署,可能會加重郵件伺服器寄信時的負擔,一般網域仍未普遍啟用DKIM機制。
DMARC(Domain-based Message Authentication, Reporting, and Conformance)
DMARC亦即基於網域的郵件驗證、報告與一致性機制,透過DMARC政策讓網域擁有者宣告其電子郵件採取SPF及/或DKIM郵件驗證機制,並且告訴收件伺服器當郵件未通過驗證時該如何處理,例如歸類為垃圾郵件或直接拒絕。透過DMARC機制也可讓收信端回報相關資訊,讓網域管理者瞭解未經驗證電子郵件的狀況,也就是reporting(報告)。藉由DMARC機制,讓收件端可明確處理這些未通過驗證的信件,達到防範假冒攻擊的效果,並防止自身網域成為攻擊者的假冒目標。
DMARC必須在先設好SPF和DKIM的情況下才有用,其運作機制是透過DNS TXT紀錄定義網域對未通過驗證電子郵件的處理方式,包括不對郵件採取任何處置(none)、隔離(quarantine)、或拒絕(reject),除此之外也可以設定套用DMARC政策的可疑郵件百分比值。為了收到網域的DMARC相關報告,在DNS TXT記錄中也可設定接收報告的電子郵件地址。
以一個建置了郵件過濾機制的收信伺服器為例,在採用SPF及DKIM電子郵件驗證機制並引用DMARC政策的情況下,其郵件處理流程就會類似下圖:傳送端(sender)將郵件表頭加上DKIM簽署資訊並傳送出去,接收端(Receiver)收到信件後先經過IP黑名單、郵件伺服器名聲、傳送速率等標準檢查後,會先執行DKIM驗證,再以信件來源資訊進行SPF檢查,最後根據SPF及DKIM檢查結果套用DMARC政策,決定信件的處理方式。
節錄自https://dmarc.org網站
實際運作情境
然而真實環境的運作並非如此簡單完美,網際網路上仍有許多未正確設定SPF資訊的網域。以臺大為例,若為了防範冒名信件,針對所有寄到臺大的信件一律採用最基本的SPF檢查,並將不符合檢查的信件隔離或拒絕,那麼許多校內師生往來通訊的期刊組織、研討會、學術或其他機構等的來信,都會被標示為垃圾郵件、隔離或拒絕。
退而求其次,為了防範從校外傳來宣稱寄件者為 @ntu.edu.tw 的冒名信件,計中郵件安全防護系統已針對此類信件採取SPF檢查。從非本校認可範圍之校外郵件伺服器傳來宣稱寄件者為 @ntu.edu.tw 的信件,將在主旨加上【非可信賴來源信件】警示文字,以提醒收件者注意信件之真偽。此類信件可能是惡意冒名信件,也可能是透過其他未嚴格檢查網域相符性的郵件伺服器寄信所導致的正常信件。
無論如何,系統端盡力判斷並提醒郵件真偽,最後把關還是靠收信者的資安素養與警覺性,把握切勿在信中透露個人資訊、不明附件或可疑內容請主動透過其他管道與對方聯繫確認、以及不隨便點選信中連結等原則,小心保全個人及系統資訊安全。
參考文獻
- 使用SPF防範假冒郵件和垃圾郵件:https://support.google.com/a/answer/33786?hl=zh-Hant
- What is DMARC:https://dmarc.org
- SPF、DKIM、DMARC運作機制:https://www.richesinfo.com.tw/index.php/mxmail/mxmail-faq/267-dkim-dmarc