基于中间盒的TCP反射放大攻击研究与实战分析
2022-4-26 19:19:57 Author: blog.nsfocus.net(查看原文) 阅读量:36 收藏

阅读: 167

一、 c前言

2021年8月在USENIX大会上,来自马里兰大学Kevin Bock等提出了一种利用中间盒(MiddleBox)TCP会话识别机制的漏洞,发起的新型TCP反射放大攻击手法。具体详细报告可参见:https://geneva.cs.umd.edu/papers/usenix-weaponizing-ddos.pdf

同时绿盟科技国际云清洗中心捕获了该TCP反射放大攻击的样本,本文将从理论和实战的角度对该攻击进行深度剖析,并提供防护建议。

 二、 什么是TCP反射攻击?

典型的分布式的TCP反射攻击场景如上图所示,

  1. 攻击者利用指令控制肉鸡资源行为,肉鸡资源包括已被入侵的IoT设备或者失陷主机等。
  2. 肉鸡资源伪造源IP为受害者IP地址的SYN包,向公网上的TCP服务器(例如HTTP服务器,FTP服务器,邮件服务器等)发送。
  3. TCP服务器收到伪造的SYN包后,由于该SYN包的源IP为受害者IP地址,因此会向被攻击服务器发送响应的SYN/ACK, ACK,RST等报文。

因此该类TCP反射攻击主要利用的是TCP握手的机制,对于被攻击服务器来说,攻击源为合法的TCP服务器,因此增加了防护难度,但是流量放大效果差,放大效果主要依赖于TCP服务器SYN/ACK报文重传(若被攻击服务器回复RST报文,则TCP服务器不会重传)。

TCP反射攻击的研究可参见http://blog.nsfocus.net/tcp-syn/

三、 TCP反射放大攻击

相比于UDP反射放大攻击,为什么TCP反射放大这么困难?

由于TCP协议的机制,数据访问需要三次握手完成,而在TCP反射攻击场景下,攻击者很难伪造成功的三次握手。如下图所示:

由于攻击者无法获取到受害者侧的流量信息,因此构造的第三步的ACK报文的ack_seq序列号很难匹配中第二步SYN/ACK报文的seq序列号(该字段为4字节,理论范围为0-2^32),同时即使匹配中序列号,受害者在收到SYN/ACK包后,会回复RST报文,导致TCP服务器连接建立不成功,因此无法进行后续的攻击行为。

但是对于中间设备例如防火墙,入侵检测等安全设备,为了网络的可靠性,通常采用如下部署方式:

  1. 旁路部署,因此中间设备通常只能收到单向流量,不能同时接收双向流量。
  2. 旁挂部署,通常镜像或者分光流量到中间设备,可双向也可单向。

对于旁路部署,牵引单向流量的场景为例,对于访问WEB服务器的TCP三次握手流量,仅SYN,ACK包经过中间设备,而SYN/ACK包不经过中间设备,因此对于中间设备来说,仅能通过下行流量的数据包来判定会话是否建立,更有甚者,由于中间设备可能是临时牵引下行流量,无法监测到握手的任何报文或是出于其他相关原因,直接放弃了会话的检查。

而这类中间设备通常具有审查功能,例如对于访问请求的域名进行合法性审查,若HTTP域名非法,则返回一个阻断页面,提示该域名非法或者直接回复RST包阻断会话,利用中间设备发起的反射攻击如下图所示。

在Kevin Bock的报告中,提到了可通过组合报文或者单包(都带有非法的域名访问)可获得反射放大的响应报文,如下图所示:

可以看到,采用多包即先发送一个SYN包,再发送一个请求报文的响应成功率最高,这也符合大部分场景下这类中间设备的部署方式。但是也能看到对于单包攻击,也能获得响应报文,即这类设备完全放弃了TCP会话的检查,甚至是数据包类型的检查(SYN包不应该携带数据)。而对于反射的放大倍数研究可参见其详细报告。

四、 现网攻击样本分析

在现网的攻防对抗中,我们捕获到了该类TCP反射放大攻击,通过多个维度对攻击特征进行了深度分析。

1. 报文特征

此类攻击中,最需要关注以及起主要放大作用的,即其中的HTTP响应(阻断)报文,如下图所示:

(1) 可以看到攻击报文的源端口大多为80,也存在少部分端口为443,但报文类型实际上依然是HTTP。据此推测部分中间设备对报文目的端口号未作检查或者检查并不严格,并直接以此目的端口号作为源端口向靶机回复了反射报文,这也导致了可能很难以源端口作为判断依据来防御此类攻击。

(2) 相比于一般的HTTP报文,此类报文的seq号大多明显较为异常(0或者一些固定值),这是因为中间设备并未完整跟踪TCP连接情况,因此只能使用攻击报文中的ack_seq值作为反射报文的seq值。

上图中被隐藏的源IP的AB段相同,我们对捕获到的攻击报文中的源IP地址进行了分析,发现抓包数据中部分源IP地址属于一个C段,从反射报文特征来看,具有相同的报文大小和TTL范围,应该是由同一个中间设备产生。但是对这些IP进行探测,发现有的IP根本未被真正使用,或者并未开放80端口,因此推断中间设备可能无法确定保护范围内的IP和端口使用情况,只要报文能够到达中间设备,中间设备都会进行审查,从而可能形成反射。因此从攻击者角度来说,只需要向中间设备保护范围内的IP地址发送类似于扫段的请求,就可能获得一定的反射放大效果。这也佐证了Kevin Bock的报告中提到了海量IP地址可能被利用发起反射,而这些IP地址根本不需要真实提供业务甚至真实存在。

按照上述分析,这也导致了此类攻击报文的源IP范围大且相对分散,无法精准封禁源地址进行防护。

2. 报文样式与放大倍数

由于反射攻击中涉及到各种各样不同的中间设备,实际的反射攻击报文的样式也多种多样,以下是一种比较典型的反射报文:

可以看出,这正是利用了域名的合规性检查发起的一起反射攻击。攻击报文中,还获取到多类中间设备返回的拦截报文,如下图为捕获到的某中间设备的告警拦截页面。

除此之外,还有其他各种样式的反射报文:

可以看出,不同的中间设备发送的反射报文内容各不相同,大多为各种错误信息,包括使用iframe嵌入错误提示页面(200 OK),页面重定向(302 Moved),页面禁止访问(403 Forbidden),服务不可用(503 Service Unavaliable)等。需要注意的是,由于回复的信息不同,不同中间设备的反射报文长度也各不相同,这也导致了不同的放大系数。因此,如何寻找到一些反射放大系数更大中间设备,也成为了发动此类攻击的一个重点。例如,以下反射源就能够得到一个较大的放大系数:

3. 其他报文

不同的中间设备除了会反射不同样式和长度的反射报文之外,其中某些中间设备还可能会额外发送一些其他报文,例如FIN/ACK报文:

报文中还观察到除了阻断报文外,还会有RST/ACK报文,推测该类报文可能是由中间设备保护的目标发出,即对于攻击者发出的非法请求,中间设备回复阻断页面,而非法请求到中间设备保护的目标时,该目标回复RST/ACK报文。

最后,虽然主要目标是利用中间设备发起攻击,但是在攻击报文中也发现了基础的TCP反射报文的证据,这是因为伪造会话的SYN包到了真实服务器上,真实服务器回复了SYN/ACK,ACK等报文,从而导致了TCP反射攻击。

五、 防护建议

  1. 中间设备被攻击者利用发起TCP反射放大攻击,除了造成DDoS攻击外,还会消耗中间设备的性能,占用网络的上行带宽,建议可从以下几个方面考虑:
  • 由于中间设备部署方式的特殊性,导致会话检查不完整,因此中间设备部署时,可选择流量双向接入,保证会话检查的完整性,避免被滥用发起DDoS攻击。
  • 对需要审查的报文先进行类型过滤,例如SYN+HTTP请求,理应不会被处理。
  • 中间设备可对阻断页面做精简优化,减小阻断页面的大小,减轻被攻击者利用时上行带宽的压力。
  • 中间设备可加入源IP判定机制,当超过阻断页面响应次数后,可回复RST报文直接断开请求。
  1. 针对此类DDoS攻击,可采用如下防护策略:
  • 对于反射攻击中的带payload的SYN报文,可直接配置静态规则过滤此类SYN报文。
  • 对于反射攻击中产生的带payload的其他报文,例如PSH+ACK等,可根据情况封禁源端口为80或者443的TCP报文,但是对于有主动向外发起HTTP请求的防护对象的流量会造成误杀,同时攻击报文的源端口可能会变化,无法适应变化的攻击。
  • 可根据情况设置基于地理库的防护策略。
  • 若已部署绿盟的抗DDoS防护设备,无需配置上述静态规则,可直接开启ACK检查算法,该算法通过发送行为挑战报文,检测攻击源会话的真实性,可完全过滤掉来自中间设备的反射流量。

六、 参考文献

  • Kevin Bock, Abdulrahman Alaraj, Yair Fax and Kyle Hurley, Eric Wustrow,Dave Levin. Weaponizing Middleboxes for TCP Reflected Amplification,Kevin Bock,
  • 绿盟科技技术博客.TCP反射攻击研究,2021.
版权声明
本站“技术博客”所有内容的版权持有者为绿盟科技集团股份有限公司(“绿盟科技”)。作为分享技术资讯的平台,绿盟科技期待与广大用户互动交流,并欢迎在标明出处(绿盟科技-技术博客)及网址的情形下,全文转发。
上述情形之外的任何使用形式,均需提前向绿盟科技(010-68438880-5462)申请版权授权。如擅自使用,绿盟科技保留追责权利。同时,如因擅自使用博客内容引发法律纠纷,由使用者自行承担全部法律责任,与绿盟科技无关。

文章来源: http://blog.nsfocus.net/tcp-use/
如有侵权请联系:admin#unsafe.sh