部分終端安全防護軟件的 DNSAML 服務存在缺陷

工作來源

Computers & Security Volume 116, May 2022, 102687

工作背景

由于單一端點上的終端安全防護軟件缺乏對威脅態勢的背景理解、對最新威脅缺乏感知。在遇到未知威脅時，很多終端安全防護軟件會將掃描文件的相關信息回傳給遠端服務，基于全球海量威脅的深度理解做出判斷，響應終端安全防護軟件進行相應的操作，如隔離或者清除惡意軟件。

基于這種機制，利用 DNS 在終端安全防護軟件與遠端服務間完成信息交互的被稱為 DNSAML（DNS anti-malware list）。事實上，這種機制必須確保信息交互的完整性與機密性，否則會影響終端安全防護軟件對惡意文件的判斷。

典型的 DNSAML 整體流程如下所示：

發現可疑文件時，終端安全防護軟件首先基于本地數據進行匹配。未能匹配的情況下，通過 DNS 請求向遠端服務發起查詢，查詢攜帶文件簽名（例如文件哈希）。DNS 請求通過域名系統傳遞給 DNSAML 服務，該服務提供文件對應的判斷作為 DNS 請求的響應返回。終端安全防護軟件得到響應后，按照預定義的方式對文件進行處理。

可以發現，DNSAML 服務的整體架構很大程度上受到域名攔截列表（DNSBL）的啟發，后者可以幫助攔截來自與垃圾郵件有關的流量。但使用 DNS 協議進行數據傳輸，使得這些系統也繼承了 DNS 的固有缺陷，如缺乏來源驗證、缺乏加密等。

工作準備

利用大規模 DNS 數據，數據集覆蓋 3700 萬臺計算機平均每天對超過 3 億個域名發起 520 億次 DNS 查詢。

盡管作者其一為 Akamai 的首席研究員，但數據集并非來自 Akamai，從數據量上看也確實要比 Akamai 小上一個量級。使用 2020 年 11 月的 DNS 流量日志，合計約 1.56 萬億次的 DNS 請求。

基本工具

• 攻擊者主機使用 Kali Linux，利用 Ettercap 工具實現對應操作。
• 受害者主機使用 Windows 10，分別使用 McAfee Endpoint Security Threat Prevention (ESTP) version 10.6.1.1386.8、Nessus Professional Version 8 (8.11.1)、python-tools-cymru。

工作設計

DNSAML 服務需要滿足以下特征：

• 處理大量 DNS 請求，平均每天至少查詢 1000 次，符合條件的有 184046 個域名。
• 由安全服務提供商注冊所有，使用 Webroot Bright Cloud 分類服務進行篩選，選取 Computer and Internet Security 類符合條件的有 220426 個域名。
• 結構化的 DNS 請求，例如 IP 地址、文件哈希或者其他形式的遙測，符合條件的有 55 個域名。
• 至少 10% 的 DNS 請求有 IPv4 地址，符合條件的有 43 個域名。
• 至少 10% 的 DNS 請求由 32 個字母/數字組成，符合條件的有 10 個域名。
• 被 DNS 隧道分類器確認，符合條件的有 51 個域名。

一類和二類的交集有 4884 個域名，符合篩選條件的總共 55 個域名。這些 DNSAML 服務每天要處理由全球 285 萬終端發起的、超過 1.08 億次查詢請求。具體如下所示：

其中五個非常具有代表性的 DNSAML 服務：

• Sophos 可擴展列表（SXL），后端服務為 Sophos Endpoint Cloud，可查詢哈希與 IP 地址。
• McAfee 全球威脅情報（GTI），后端服務為 McAfee Labs，通過 McAfee Endpoint Security、VirusScan 等查詢。
• ESET LiveGrid，通過 ESET ThreatSense 等查詢。
• Tenable MalwareDB，通過 Nessus Professional 查詢。
• Team Cymru 惡意軟件哈希注冊（MHR），匯總了 30+ 反病毒工具結果，盡管沒有官方查詢工具但提供了非正式的開源查詢工具。該服務平均每天查詢接近 9 萬次，應用廣泛。

可以通過三個指標來衡量 DNSAML 服務的普及程度：

• 查詢總量：DNSAML 服務每日平均查詢總量為 1.08 億次，占到所有 DNS 查詢量的 0.2%。
• 查詢端點量：每日查詢 DNSAML 服務的平均端點數為 285 萬個，當然這不代表最終用戶數量，某些服務不只是端點使用也在網關上使用。
• 覆蓋國家/地區量：所有 DNSAML 服務覆蓋 29 個國家/地區，而 McAfee、Sophos 與 ESET 這種頂級廠商至少覆蓋 24 個國家/地區。

依據攻擊能力，攻擊者可以分為三類：

• 中間人攻擊者（MITM）：攻擊者是位于 DNS 解析路徑上的中間人，享有完全控制和篡改的能力。
• 臨近機器攻擊者（OPSAM）：攻擊者能夠控制位于 DNS 解析路徑臨近機器實現 IP 欺騙，大概 30.5% 的自治系統都不會攔截此類數據包，攻擊者享有有限的篡改能力。近期研究也證明，通過網絡棧的側信道攻擊克服源端口隨機化，存在一定概率可以實現對流行 DNS 服務提供商（Google、Cloudflare、OpenDNS、Comodo、Dyn、Quad9 和 AdGuard）的緩存投毒。
• 解析路徑外攻擊者（OP）：攻擊者在 DNS 解析路徑外也能通過某種手段享有有限的篡改能力。例如利用偽隨機數生成器的漏洞對基于 Linux 的 DNS 解析服務進行緩存投毒。

主要威脅如下所示：

• Silencing（告警靜默）：將端點上運行的任意/特定惡意軟件判定為無害，使惡意軟件執行暢通無阻。
• False Alerts（虛假告警）：將端點上運行的良性文件判定為有害，產生告警疲勞或者告警淹沒。
• Information Disclosure（信息泄露）：攻擊者可以獲知受害者安裝終端安全防護軟件的情況、有哪些惡意軟件成功遞送抵達受害者、根據掃描的情況評估組織的安全狀況。

信息泄露攻擊（ATT-ID）、虛假告警攻擊（ATT-FA）、告警靜默攻擊（ATT-S）這三種攻擊的模式實際上都比較簡單，可以理解為類似于重放再匹配，按需篡改影響終端安全防護軟件的判斷。

再次提醒下這一流程能夠成功的前提條件是簽名獨立于端點，通過完全匹配相同的簽名即可確認在不同的端點下有相同的文件。

工作評估

對三個比較典型的產品進行評估，評估結果如下所示：

演示視頻可見

https://youtube.com/playlist?list=PLMhL8ch_vmMBRju0mSA_997WgBp7TK5KU

示例一

虛假的 DNS 響應使 Nessus 將合法文件判定為惡意文件：

示例二

虛假的 DNS 響應使McAfee 將惡意木馬判定為合法文件：

分別討論 — McAfee GTI

McAfee ESTP 請求 avts.mcafee.com 或 avqs.mcafee.com，請求為 32 位簽名做前綴，但未能在 VirusTotal 上查詢到對應文件，應該是內部實現的簽名方案。而作為響應的 IPv4 地址一共發現了 25 種方案，只有 127.64.8.8 會導致文件刪除。在收到刪除響應時，ESTP 會再額外請求 DNS TXT 記錄，響應內容通過加密與 base64 編碼無從得知內容。但如果響應被篡改或者阻攔，ESTP 將不會刪除惡意文件。

McAfee 表示其 Global Threat Intelligence over DNS (GTI-DNS) 服務已經在生產環境中應用 12 年，目前正在將該服務遷移到 GTI-REST 服務上以保持認證與加密。后續，McAfee 打算完全改用 REST API 方案。

McAfee 產品升級與安全公告

https://kc.mcafee.com/corporate/index?page=content&id=SB10354

分別討論 — Tenable MalwareDB

Nessus Professional 請求 chk.l2.nessus.org 確認連接正常再向 l2.nessus.org 拼接發起查詢請求。響應中的標簽與掃描報告間存在關聯，其映射函數如下所示：

Tenable 并不打算大幅修改目前的解決方案，但表示將會在目前情況下加以改進。

分別討論 — Team Cymru

Team Cymru 的 MHR 相對簡單得多，請求 malware.hash.cymru.com。良性文件會返回標準 NXDOMAIN，惡意文件會返回 127.0.0.2。

Cymru 表示其 MHR 實際上提供了四種接口，官方推薦使用 HTTPS 接口，但仍為用戶保留根據自身情況選擇使用方式的權利。

工作思考

終端安全防護軟件的 DNSAML 服務大概是安全廠商“云端主防”體系的一部分，這個服務其實也算是 DNS 隧道的合法濫用形式之一。不得不說這一研究點十分“精巧”，這類域名在進行域名數據的處理與分析時是一個很常見的大類數據，過往由于視角/目標的不同或者能力的局限，筆者并未對此深究。可見，通過對海量數據的不斷深入分析與研究，是可以讓數據“開口說話”的，這應該也是未來發展的方向和趨勢之一。

這些存在缺陷的 DNSAML 服務實際上主要問題在于：① 沒有認證與加密、② 文件簽名方案不存在變化。作者提出了一些可能的改進方案，如下所示：

沒有十全十美的解決方案，要綜合考量安全、性能、兼容性、可用性多方因素，看起來 DoT 似乎是目前來看最合適的改進方案。有類似服務的廠商，可以進行一下自查自檢，如果存在此類缺陷可以盡快修復。有數據視野的也可以嘗試分析下國內的情況，看是否存在類似的問題。