部分终端安全防护软件的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 似乎是目前来看最合适的改进方案。有类似服务的厂商，可以进行一下自查自检，如果存在此类缺陷可以尽快修复。有数据视野的也可以尝试分析下国内的情况，看是否存在类似的问题。

声明：本文来自威胁棱镜，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。

原文链接：https://www.secrss.com/articles/42429