ICMP Redire
背景
DNS查询
- Stub Resolver:电脑内置DNS解析
- Forwarder:路由器转发DNS
- Resolver:8.8.8.8
DNS投毒
前三者发送DNS查询数据包时,若攻击者能在接收者之前响应该查询,并猜对DNS包中的TxID字段(16位),受害者则会错误的接收该响应,并将攻击者的回复保存到缓存中
DNS投毒防御
现有的最广泛的防御是源端口的随机化
- 在发送查询时,会使用随机的端口号(16位)
- 错误的端口号或TxID都会导致攻击者的回复被丢弃
- 将随机性从16位扩大到了32位
接下来要介绍的一篇论文呢,通过分而治之的方式,先猜测端口号,再猜测TxID,攻破了这种防御
UDP协议
UDP编程指导(RFC 8085)
- UDP数据报可以直接发送和接收,而无需任何连接设置。使用sockets API,应用程序可以在单个UDP套接字上接收来自多个IP源地址的数据包
- 为了确保应用程序只从一个特定的源地址接收数据,这些应用程序必须在应用层执行相应的检查,或者明确要求操作系统过滤接收到的数据
不仅针对UDP服务器,也针对客户端
- 公开端口
- 客户端调用sendto()发送后,在同一套接字上调用recvfrom会接收来自任何IP的数据包。意味着源端口会向公众开放,可以被攻击者扫描
- 攻击者命中源端口时,被操作系统接收,在应用层被丢弃
- 未命中时,返回ICMP不可达
- 私有端口
- UDP套接字也可以使用connect绑定到一对特定的地址和端口
- 操作系统丢弃IP和端口不符数据包,返回ICMP端口不可达
基于UDP的端口扫描
公开端口
攻击者发送UDP端口猜测包,命中时被接收。未命中则受害者返回ICMP不可达。
私有端口
攻击者在伪造IP地址后,发送的探测包才会被接收。命中时被接收,未命中时,ICMP不可达会被返回到攻击者伪造的IP地址。
直接扫描的障碍
操作系统对发送ICMP的速率进行了限制,以Linux为例,使用了token bucket style的实现方法
- 单个IP最多一次发送6个ICMP包,每秒恢复1
- 全局最多一次发送50个ICMP包,每毫秒恢复1,两次恢复相距至少20ms
DNS Cache Poisoning Attack Reloaded: Revolutions with Side Channels(CCS 20)
这篇文章使用全局速率的侧信道进行UDP端口扫描
公开端口扫描
- 伪造50个不同IP以绕过单个IP的速率限制,发送50个UDP探测包
- 若未命中端口,触发50个ICMP端口不可达(攻击者无法直接观察到)。攻击者使用真实IP向已知关闭端口发送数据,此时受害者触发ICMP速率限制,受害者不会响应。
- 若命中了n个UDP端口,触发50-n个ICMP数据包。攻击者使用真实IP向已知关闭端口发送数据,受害者会进行ICMP响应。
- 若命中开放端口,使用二分法确定端口。若未命中端口,等待至少50ms,再次扫描
每秒可进行1000次尝试,枚举65536个端口需要60多秒。但可以通过重复实验,来增加在短时间内成功的概率
私有端口扫描
理论上私有端口只接收源IP为name server的数据包,此时受到单个IP速率的限制,每秒只能扫描1个端口
但在Linux实现中,Linux有意地先检查全局速率限制,再检查单个IP速率限制
这是因为单个IP速率检查开销较大。但这导致了,即使由于单个IP速率限制,不应该发送ICMP数据包,仍会消耗全局速率限制的额度
- 伪造50个IP为name server的数据包,发送50个UDP探测包
- 若未命中端口,触发1个ICMP不可达,消耗50个全局速率限制,受害者不会响应来自攻击者的直接探测。
- 若命中了n个端口,触发1个ICMP不可达,消耗了50-n个全局速率限制,受害者会响应来自攻击者的直接探测。
- 若命中开放端口,使用二分法确定端口。若未命中端口,等待至少50ms,再次扫描
DNS Cache Poisoning Attack: Resurrections with Side Channels(CCS 21)
这篇论文提出基于ICMP的端口扫描
ICMP消息不要求回复,攻击者无法观察到
ICMP协议
ICMP协议用于传输出错报告控制信息
例如这篇文章使用的ICMP Frag Needed 发送者向某一接受者发送IP数据包 传输路径中的某台主机发现数据包的大小超过了自己的MTU(网络能够传输的最大数据包大小),向发送者发送ICMP Frag Needed,告知其发送到数据包过大,需要分片
发送者接收到ICMP Frag Needed请求后,之后向该接收者发送的数据包都不会超过ICMP分片中指定的大小
问题:ICMP分片可以由路径上任一路由器/主机发出,发送者无法验证该数据包是否真的由路径上的节点产生
对ICMP协议数据包的检查
- IP报头
- 源IP地址:可能是任意主机
- 目的IP地址:自身
- 嵌入数据包的前28个字节:引起该ICMP的数据包
- IP报头(20字节)
- 源IP地址:自身
- 目的IP地址:通信目标
- UDP/TCP报头(8字节)
- 源端口号/目的端口号
- TCP的ACK序列号
- IP报头(20字节)
- Linux系统的额外检查
- 源端口是否存在套接字
基于ICMP Frag Needed的端口扫描
ICMP消息不要求回复,攻击者无法观察到。作者的解决方法是发送ICMP Frag Needed包,观察后续的ICMP Echo包是否被分片:
- 如果端口号猜测正确,攻击者的MTU被更新
- 发送ping,则响应被分片
私有端口扫描
上述方法只适用与公开端口扫描,私有端口只接收指定IP地址的数据包,攻击者必须伪造IP,也只能为该IP更新MTU。导致无法直接ping进行观察
ICMP异常缓存
Linux中异常缓存为一个IP到异常的映射
对于ICMP Frag Needed,异常为更新后的MTU
以IP为键,哈希到2048个桶中
每个桶有5个slot解决冲突
到达极限后,逐出最旧的异常
ICMP异常侧信道
- 找到5个与服务器冲突的IP(攻击者至少控制1个IP:C1,其他可以伪造),占领缓存异常的5个slot
- 猜测端口号,如果正确,为服务器更新MTU,逐出异常缓存中C1
- 使用C1发送ping,观察是否被分片
寻找冲突的IP
直接查找5个冲突IP较困难
破解系统使用的散列函数的秘密:32位,只有在重启时生成
租用3500个服务器,获取随机的IP地址。找到哈希碰撞集,通过哈希碰撞计算出唯一的秘密
Off-Path Network Traffic Manipulation via Revitalizing ICMP Redirect Attacks(USENIX 22)
ICMP重定向
ICMP重定向机制被路由器用来通知始发者从始发者到其目的地的更优化的路径。它减少了到达目的地所需的跳跃次数。
当发起方的网关接收到IP数据包时,网关将检查其路由表,以确定下一个网关的地址
如果下一个网关和由数据包的源IP地址标识的发起方在同一网络上,则将从网关向发起方发送ICMP重定向消息。生成的ICMP重定向消息建议始发者将其目的地网络的流量直接发送到下一个网关,而不是当前网关,因为直接通过下一个网络转发到目的地的路径更短。
对ICMP重定向数据包的检查
- IP报头
- 源IP地址:默认网关
- 目的IP地址:自身
- 嵌入数据包的前28个字节:引起该ICMP的数据包
- IP报头(20字节)
- 源IP地址:自身
- 目的IP地址:通信目标
- UDP/TCP报头(8字节)
- 源端口号/目的端口号
- TCP的ACK序列号
- IP报头(20字节)
- Linux系统的额外检查
- 源端口是否存在套接字
现有的规避检查的方法
- 伪造源IP地址
- 互联网上大约四分之一的自治系统不会过滤离开其网络的伪造IP地址的数据包
- 本论文发现5100多个自治系统没有执行有效的入口过滤
-
源端口与序列号的随机化
使路径外攻击者难以攻击
ICMP合法性检查的漏洞
与TCP不同,UDP是无状态协议,没有序列号来表示已发生的连接
Linux进行额外检查,自Linux2.6.20版本起,检查源端口是否存在套接字。防御了之前的攻击
如下图所示:第106行检查是否存在套接字。如果存在,第113行进行重定向。
本文提出新的攻击思路
- 现代操作系统默认为轻量级服务(例如,NTP、SNMP、DHCP、DNS和TFTP)打开几个已知的UDP端口
- 攻击者首先在受害者身上探测这样一个打开的UDP端口
- 诱骗受害者在探测的开放端口上为远程目的地生成一个可预测的UDP套接字
- 攻击者伪造了一条ICMP重定向消息给受害者,该消息嵌入了已知的UDP套接字和一些任意填充数据
- 除了UDP,作者还发现ICMP、GRE、IPIP和SIT等无状态协议也可能被路径外的攻击者利用来逃避ICMP合法性检查机制
受影响的实现
- Linux 2.6.20(2007年2月发布)及更高版本、FreeBSD 8.2(2011年2月发行)及更高版本、Android 4.3(2012年6月发行)及其更高版本,以及Mac OS 10.11(2015年9月发行)和更高版本
- ICMP重定向机制在Linux系统、FreeBSD系统、内核版本6.0之前的Android系统和内核版本10.11.6之前的Mac操作系统中默认启用
- 在安卓系统中,一旦内核中启用了ICMP重定向机制,普通用户很难手动禁用该机制,因为禁用操作需要root权限
- 对于内核版本10.11.6之后的Mac操作系统,一旦通过sysctl参数启用ICMP重定向机制,Mac操作系统也会变得易受攻击
攻击实现的条件
伪造的ICMP数据包能在互联网中进行转发
- 根据ICMP规范,ICMP重定向消息只能通过当前的第一跳网关发送到连接的主机,这意味着ICMP重定向消息不应在互联网上跨网络转发
- 如果ICMP重定向消息出现在互联网上,它们应该被只允许合法流量通过网络的过滤机制无声地丢弃
- 然而,作者发现,伪造的ICMP重定向消息仍然可以在一定数量的AS之间传输,从而在互联网上成功转发
实验
- 选取4个大洲的19个位置
- 从其中9个位置发送ICMP重定向包到其余10个位置
- 没有进行任何IP伪造,仅测试是否能够送达
实验结果:每次ICMP重定向消息均能送达
受害者发起人所在的目标AS不会丢弃伪造的ICMP重定向消息
消息进入受害人所在AS时,AS发现源IP地址为AS内部的网关,应该将其过滤
实验
实验结果:实验总共检测到185个国家的5184个易受攻击的AS
威胁模型
DOS攻击
- 受害发送者(网络服务器、开放的DNS解析器、Tor中继节点)
- 受害发送者的邻居
- 受害接收者(网站客户端、权威域名服务器、下一条Tor节点)
- 路径外攻击者
目的将受害发送者向受害接收者的网关重定向到受害发送者的邻居
主机默认关闭转发,受害发送者的流量无法到达接受者
-
寻找网关IP地址
确认受害者IP后,可通过traceroute观查其网关的IP地址
-
伪造源IP地址
作者通过租用bullet-proof-hosting服务,将IP报头的源IP地址伪造为网关IP地址
最近研究表明,69.8%的AS不对进入的数据包检查源IP地址
-
探测邻居
受害发起者在更新路由前,会检查ICMP重定向中指定的主机是否有效
攻击者通过ICMP echoes扫描受害者网络,寻找在线主机
攻击流程
- 攻击者探测受害接收者相邻主机
- 攻击者伪造IP为受害接受者,并伪造UDP数据报到受害发送者监听的一个UDP端口
- 受害者-发起者被诱骗建立了攻击者可预测的UDP套接字
- 攻击者假装是受害发送者的网关(通过IP地址欺骗),然后使用第三步的UDP四元组,伪造ICMP重定向包
- 伪造的ICMP重定向消息通过了受害发送者的检查
- 受害发送者更新其路由缓存,并将后续网络流量重定向到邻居主机
- 重定向的流量被禁用转发的邻居主机丢弃
- 受害接受者无法接收到来自受害发起者的任何响应
实验环境
- 受害发起者:Alexa排名前一百万的网站
- 受害发起者邻居:使用ICMP echoes探测
- 受害接受者:分布在6个地区,作者选取的最初可以访问到这些网站的客户端
- 攻击者:位于俄罗斯,使用IP伪造服务
实验结果
排名前100万的网站中,4.3%的网站易受攻击
排名越低的网站,越有可能易受攻击
攻击失败的原因
- 网关对伪造的数据包进行了过滤/不受影响的操作系统
- 静默网关
- 不泄露自己的IP地址
- 无法访问网站/无法解析域名
- 由审查或ISP过滤引起
- 计算总成功率时未考虑
对服务器的攻击
除了针对个人用户(阻止个人访问网站),还可以对服务器与服务器之间的通信进行攻击,这会造成更大的影响
- 阻止DNS解析器访问下游权威域名服务器
- 阻止Tor relay nodes之间的通信
网络流量劫持攻击
不同点:攻击者与受害者在同一网络下
例如同一公网IP下的NAT客户端、学校或企业网络
攻击目标:将受害发送者的路由重定向为自己,进行中间人攻击
解决措施
- 网络层面
- 入口过滤
- 阻止外来的ICMP消息与伪造IP地址都消息
- 无法抵御局域网内的攻击者
- 入口过滤
- 协议层面
- ICMP合法性检查
- 在UDP协议报头中嵌入额外机密
- 需要对所有可利用的无状态协议进行更改,难以在现实中部署
- ICMP合法性检查
- 主机层面
- 禁用对无状态协议包的ICMP重定向
- 禁用不会导致连通性问题,只可能导致次优路由而产生额外的网络延迟
- 禁用对无状态协议包的ICMP重定向
TFTP测试
-
带宽10Gbps的服务器
-
一个更快的网关和一个较慢网关
-
较慢网关的延迟分别设置为3.39ms,6.71ms和9.21ms
-
默认使用次优网关
-
开启重定向后,会更新路由到最佳网关
测试结果:下载文件的时间
- 对小文件影响显著
- 大于1MB时,开销17%
- 大于100MB时,开销1%
总结
在本文中,作者研究了ICMP规范中的漏洞,非路径攻击者可以利用该漏洞来逃避检查机制。
在这种出现在各种主要操作系统中的漏洞的帮助下,作者证明ICMP重定向攻击可以在现实世界中造成严重损害
作者展示了远程的非路径攻击者可以对互联网上的公共服务器进行隐蔽的DoS攻击,并且互联网上的大量公共服务器容易受到作者的攻击
作者还证明,如果偏离路径的攻击者和受害者位于同一网络中,攻击者可能能够通过发布伪造的ICMP重定向消息来构建MITM攻击
作者针对攻击制定了不同的应对措施。部署在主机上的增强ICMP重定向机制证实了作者的对策的有效性,且对网络性能的副作用有限