DataCon 2020 Coremail郵件安全競賽-賽題一滿分writeup
1 賽題描述
瞭解常見的郵件安全協議，熟悉常見的郵件資料頭部欄位。在此基礎上，自行設計檢測演算法，識別資料集中所有包含“發件人偽造（Sender Spoofing）”攻擊行為的郵件。
資料為5000封左右的郵件資訊，經過主辦方的匿名化處理，僅保留郵件的頭部欄位資訊。每封郵件均有唯一的ID編號，其中僅有100封左右的郵件含有發件人偽造攻擊。
2 最終排名
本次比賽我們“菜雞也要試一下”戰隊第一題得到了滿分100，我們基於規則過濾找到了資料集中包含的所有“發件人偽造”攻擊的所有100個樣本。
3 關鍵知識
3.1 SMTP
SMTP郵件服務商互相傳送郵件是不需要認證的問題，“發件人偽造”攻擊是利用這個問題來實現偽造任意發件人。
SMTP（Simple Mail Transfer Protocol）協議，即簡單郵件傳輸協議，是定義郵件傳輸的協議，它是基於TCP服務的應用層協議，使用者通過SMTP協議所指定的伺服器就可以把郵件傳送到收件人的伺服器上。
由於SMTP傳輸資料的階段是可以人為可控的，所以可能會出現攻擊者人為編造傳輸資料中發件人實現“發件人偽造”攻擊。SMTP協議資料傳輸過程主要是通過以下五個主要命令實現的。
- Helo ：表示與伺服器內處理郵件的程序開始通話"介紹自己"
- Mail from：郵件資訊的來源地址，也就是要偽造的地址
- Rcpt to：郵件接收者/受害者
- Data：郵件的具體內容/可以新增附件等
- Quit：退出郵件
攻擊者可以利用以上命令進行“發件人偽造”攻擊。
目前，為了防範這些問題，有人提出了一些防範技術，如SPF、DKIM、DMARC等。
3.2 SPF
SPF（Sender Policy Framework）發件人策略框架，SPF 是為了防範偽造發件人地址傳送垃圾郵件而提出的一種開放式標準，是一種以 IP 地址認證電子郵件發件人身份的技術。域名所有者通過在 DNS 中釋出 SPF 記錄來授權合法使用該域名傳送郵件的 IP 地址。
當在 DNS 中定義了域名的 SPF 記錄後，為了確認郵件聲稱發件人不是偽造的，郵件接收方首先檢查郵件域名的 SPF 記錄，來確定發件人的 IP 地址是否被包含在 SPF 記錄中，若包含，則認為是一封正確的郵件，否則認為是一封偽造的郵件並退回，或將其標記為垃圾 / 仿冒郵件。
常見SPF記錄驗證可能返回的結果如下圖所示。
3.3 DKIM
DKIM（DomainKeys Identified Mail）域金鑰識別郵件，DKIM 是一種防範電子郵件欺詐的驗證技術，通過訊息加密認證的方式對郵件傳送域名進行驗證。
郵件傳送方傳送郵件時，利用本域私鑰加密郵件生成 DKIM 簽名，將 DKIM 簽名及其相關資訊插入郵件頭。郵件接收方接收郵件時，通過 DNS 查詢獲得公鑰，驗證郵件 DKIM 簽名的有效性。從而確認在郵件傳送的過程中，防止郵件被惡意篡改，保證郵件內容的完整性。
DKIM 標準的模糊性，缺乏安全預設值，以及 MIME 標準的實現的複雜性，靈活性都可以產生改變郵件的主要資訊，比如主題，甚至改變整個郵件的內容。包括新增新的惡意附件，從而可以實現利用現有郵件創造欺詐郵件。DKIM欄位含義如下圖所示。
3.4 DMARC
DMARC（Domain-based Message Authentication, Reporting & Conformance）基於域的訊息認證，報告和一致性。
DMARC 是一種基於現有的 SPF 和 DKIM 協議的可擴充套件電子郵件認證協議，在郵件收發雙方建立了郵件反饋機制，便於郵件傳送方和郵件接收方共同對域名的管理進行完善和監督。
DMARC 要求域名所有者在 DNS 記錄中設定 SPF 記錄和 DKIM 記錄，並明確宣告對驗證失敗郵件的處理策略。郵件接收方接收郵件時，首先通過 DNS 獲取 DMARC 記錄，再對郵件來源進行 SPF 驗證和 DKIM 驗證，對驗證失敗的郵件根據 DMARC 記錄進行處理，並將處理結果反饋給傳送方。
DMARC記錄標籤解釋如下所示。
4 解決方法
基於規則過濾“發件人偽造”攻擊樣本
經過閱讀分析郵件協議頭欄位的含義和提交答案嘗試驗證，我們決定使用規則對比賽資料進行過濾，從而找出資料中的“發件人偽造”攻擊樣本。
-
規則1: smtp.mail和From
如果Authentication-Results欄位裡的smtp.mail和From欄位裡最後那個發件人的地址不一樣，就認為是攻擊樣本。示例如下：
-
規則2: SPF記錄結果不為pass
如果Authentication-Results欄位裡的spf=後面結果不是pass，就認為是攻擊樣本。示例如下：
-
規則3:多個From欄位
如果郵件協議頭裡有多個From，就認為是攻擊樣本。示例如下：
-
規則4: Sender和From不一樣
如果郵件協議頭裡Sender和From不一樣，就認為是攻擊樣本。示例如下：
-
規則5: From裡有特殊字元
如果From郵件地址裡有這些特殊符號[’~’,’!’,’#’,’$’,’%’,’^’,’&’,’*’,’:’,’;’,’[’,’]’,’–’]，就認為是攻擊樣本。示例如下：
-
規則6: dkim.d和From不一致
如果DKIM-Signature欄位裡的d=和From不一致，就認為是攻擊樣本。示例如下：
-
規則7: Authentication-Results欄位裡的header.i和stmp.mail域名不一致
如果Authentication-Results欄位裡的header.i和stmp.mail域名不一致，就認為是攻擊樣本。示例如下：
-
規則8: Return-Path和From不一樣
如果Return-Path和From不一樣，就認為是攻擊樣本。示例如下：
-
規則9: X-Return-Path和From不一樣
如果X-Return-Path和From不一樣，就認為是攻擊樣本。示例如下：
最後，將所有規則過濾出的結果copy到一個list轉set去重即可得到最後的結果。
5 思考總結
我們是第一次參加安全相關的比賽，本科不是做安全出身，對郵件安全也不瞭解，以上規則都是參加本次比賽現學現賣找出的。比賽一開始覺得Received欄位是一個強特徵，但是解析麻煩，後來也發現這個欄位可以偽造，且過濾出結果太多，不太準確，同時前兩天有些別的事情沒有花太多時間閱讀協議欄位含義導致了沒有成功得分。後來，第三天定下心來認真閱讀協議頭部欄位含義後，逐漸找到了有效的過濾規則，分數逐漸提升，最後得到了100分。
通過做這道題還是學到了“發件人偽造”攻擊原理和郵件協議頭欄位含義相關的郵件安全知識。菜雞第一次參賽可以得到一題滿分，很開心了！
可能是運氣好碰巧找到了所有過濾規則，請各位大佬不要笑我這個菜雞，哈哈哈
6 參考文獻
- https://zhuanlan.zhihu.com/p/49443988
- http://tools.ietf.org/html/rfc7208
- http://www.openspf.org/Introduction
- https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/email-validation-and-authentication?view=o365-worldwide
- https://service.mail.qq.com/cgi-bin/help?subtype=1&no=1001505&id=16
- https://blog.csdn.net/qq_34101364/article/details/108062913