基于DTLS协议的反射攻击深度分析

0x00概述

      德国软件公司Anaxco GmbH的Marco Hofmann首次发现黑客利用Citrix ADC网关上的DTLS服务（UDP：443）作为反射源实施DDoS放大攻击，之后国内多个安全团队针对此类攻击进行过解读。

      百度智云盾团队在2021年1月也捕获到此类攻击，经过深入分析，我们确认了这次攻击是黑客利用DTLS协议未启用HelloVerifyRequest安全认证机制的漏洞发起的反射放大攻击。

0x01 事件回顾

      2020年12月19日，德国软件公司Anaxco GmbH的Marco Hofmann在公司的监控系统上发现异常流量告警，在公司防火墙上进行抓包分析，发现流量中有同一客户端IP的大量请求和海量响应，随后跟踪到流量来源为Citrix ADC设备上的DTLS服务（UDP 443）。由于异常流量已经影响到了公司网络，他决定阻断针对UDP 443端口的请求，从而缓解了这次攻击对公司网络的影响。之后他将这次攻击信息发布到社交网站，不久有其他安全研究人员在EUC社区及社交网站上发帖表示也遭受到了这种攻击。

      Citrix ADC是Citrix（思杰）公司的一系列网络产品的统称，ADC的中文名为应用程序交付控制器，也被人称为NetScaler ADC，主要用于帮助提高应用程序性能，它能在保证数据安全性的同时进行流量优化和加速。Citrix ADC网关程序支持DTLS功能，用于保证UDP协议上的安全通信。目前Citrix ADC程序在全球范围内被广泛使用。

      Citrix官方在关注到这些攻击后确认了这一问题，并临时提供了两个解决方案：1、如非必要，禁止使用DTLS服务，2、如果必须使用DTLS服务，启用ACL策略。之后官方在一月份紧急发布新版本，添加”HelloVerifyRequest”功能，用于增强DTLS的安全性，但是该功能需要维护人员手动开启。

0x02 技术分析

      智云盾系统监测到攻击时，自动对流量进行采样，安全专家及时介入对采样包进行深层次分析和演练。本次攻击事件共涉及反射源1567个。

• 攻击分析

      通过对智云盾的攻击采样包发现，反射流量的来源端口是443，下图红色箭头指向的是反射源端口与反射数据包：

图1 反射源端口与反射数据包

      通过分析采样包可知，攻击流量部分符合RFC6347定义的协议规范，皆为DTLS服务器响应的证书消息。实际上RFC规定了DTLS协议首次交互需要使用HelloVerifyRequest安全认证，之后才会进行证书交互，显然上述DTLS服务器没有遵循这一规范的严格实现，导致了这些服务器在收到伪造的客户端请求后直接响应了大量的证书消息。

• DTLS协议原理

      DTLS协议是用于UDP之上的安全传输协议，主要用于保护通信双方的数据隐私，防

范数据被窃取和篡改，可以看做是UDP之上的TLS协议。下图是DTLS协议规范的交互过程：

图2 DTLS协议握手交互过程

      客户端首次发送请求到DTLS服务器，服务器收到后响应HelloVerifyRequest包（携带包含客户端IP的cookie消息），客户端收到后需再次发送请求并携带cookie，之后服务器校验cookie完成安全认证，如果认证不通过，会再次响应HelloVerifyRequest包。

• 攻击验证

      我们抽取本次攻击中的未开启HelloVerifyRequest的服务器，向其发送模拟请求，并对交互信息进行抓包分析，下图为抓包数据：

图3 未开启HelloVerifyRequest的源响应

      分析上图可知，未开启HelloVerifyRequest安全认证的服务器在收到我们发送Hello请求后直接响应证书消息。

      在模拟请求中最大得到的数据包请求211字节、响应5381字节，科学计算放大倍数为5381/211=26.5倍，与之前Marco Hofmann表述的35倍放大效果有差距，这一倍数计算方法应该是用的数据包载荷之比，科学的计算放大倍数可以参阅《MEMCACHED DRDoS攻击趋势》一文。

      再从本次攻击中抽取开启了HelloVerifyRequest的服务器，向其发送模拟请求，下图为抓包数据：

图4 开启HelloVerifyRequest的源响应

      分析上图可知，开启HelloVerifyRequest安全认证的服务器在收到我们发送Hello请求后先响应了HelloVerifyRequest，随后客户端再次发送携带cookie的请求，完成安全认证。

0x03 反射源分析

• 反射源分析

      智云盾系统检测到攻击时，自动对流量进行采样，通过分析采样包我们发现，共计1567个IP参与了此次反射攻击，本次攻击事件中的IP主要来自于美国、德国和英国等10个国家，下图是IP分布：

图5 反射源IP分布

      本次反射攻击中有42个IP未形成放大效果，可能跟Citrix在1月份的紧急升级有关，部分用户的管理员更新并开启了HelloVerifyRequest安全认证功能。

• DTLS协议的使用范围

      DTLS协议可用于Web浏览、邮件、即时消息传递和VoIP，由于UDP协议的高效性，DTLS协议非常适用于实时传输场景。

      DTLS协议还被应用于各类应用程序，如：F5 VPN、CiscoAnyConnectVPN、OpenConnectVPN、ZScaler 2.0、思科InterCloud Fabric以及本次攻击中被利用的Citrix ADC程序均使用DTLS协议来保护UDP上的安全数据传输。DTLS协议通常还会与其他协议同时使用，比如与安全实时传输协议（SRTP）一起定义用来实现WebRTC，目前Google Chrome、Opera和Firefox均提供支持。

      为了调查DTLS协议在全球范围内的使用情况，我们及时与ZoomEye团队进行了技术沟通，ZoomEye是国内最优秀的网络空间搜索引擎之一，ZoomEye团队在收到反馈后及时针对全网进行扫描，很快获取到4118个IP使用了DTLS服务（截止统计时，扫描还在继续），这些IP在全球范围内均有分布，主要来自于美国、德国、英国等10个国家，下图是IP的地图分布情况：

图6 反射源IP地图分布

图7 反射源Top5

0x04防范建议

      反射攻击与传统的flood攻击相比，能更好的隐藏攻击者，并且产生较大流量，因为反射攻击越来越受到黑客青睐。

      建议参考以下方式提升防护：

• 默认开启DTLS协议的HelloVerifyRequest验证

• 升级DTLS协议到最新版本

• 选择接入DDoS云安全服务对抗大规模的DDoS攻击

0x05参考文章

[1] https://www.zoomeye.org/

[2] https://tools.ietf.org/html/rfc6347

[3] https://msandbu.org/citrix-netscaler-ddos-and-deep-dive-dtls-protocol/

百度安全应急响应中心

百度安全应急响应中心，简称BSRC，是百度致力于维护互联网健康生态环境，保障百度产品和业务线的信息安全，促进安全专家的合作与交流，而建立的漏洞收集以及应急响应平台。地址:https://bsrc.baidu.com

长按关注

本文始发于微信公众号（百度安全应急响应中心）：基于DTLS协议的反射攻击深度分析