思维之海

——在云端,寻找我的星匙。

阅《Off-Path TCP Exploit: How Wireless Routers Can Jeopardize Your Secrets》

《Off-Path TCP Exploit: How Wireless Routers Can Jeopardize Your Secrets》是一篇来自USENIX Security(信息安全领域四大顶级学术会议之一)2018年的会议论文。本论文从属于子领域Wireless Attacks(无线攻击)。这篇文章发现了一个timing side channel,其广泛存在于所有基于IEEE 802.11或者WIFI技术的产品上。之前TCP的injection attack一般都是因为软件漏洞,从而可以通过更新软件的方式来让漏洞消失。但是,这篇文章发现的问题是基于IEEE 802.11协议的框架设计的,因此没法利用软件的方式快速解决。这种设计上的缺陷,意味着需要对协议进行比较substantial的改动才能修复。研究员利用这个side channel,成功在多个主流操作系统(macOS, Windows, and Linux)上实施了攻击。而且只需要一台连接到无线路由器网络的设备,和一台可达的攻击服务器。接着,他们展示了一个攻击的Demo。

Among possible attacks scenarios, such as inferring the presence of connections and counting exchanged bytes, we demonstrate a particular threat where an off-path attacker can poison the web cache of an unsuspecting user within minutes (as fast as 30 seconds) under realistic network conditions.

本篇论文源于高等计算机网络课程的阅读任务,领域为“TCP安全 ”。

本文还从属于小组的项目展示,因此需要谨慎对待。同一个系列的其他几篇论文也需要留意。

References

USENIX Security · 2018 论文总结

Off-Path TCP Exploit: How Wireless Routers Can Jeopardize Your Secrets

口头报告和PPT

https://github.com/seclab-ucr/tcp_exploit

RFC6013 这里面也有安全性设计(比如cookie timestamp),但是Google认为安全性useless所以把这部分从linux内核中移除了

Multipath TCP Traffic Diversion Attacks and Countermeasures

Off-Path TCP Exploits: Global Rate Limit Considered Dangerous

Off-Path TCP Injection Attacks

Off-Path TCP Exploits of the Mixed IPID Assignment

基本概念

half-duplex: 半双工

Side-channel attack

Side-channel attack

通过观测、实验各种系统状态和状态变化,来推断系统的某些属性,从而使得攻击成为可能。

Off-Path TCP Exploit

Linux设备TCP连接的有趣漏洞:传说中的Off-Path劫持

Off-Path TCP Exploit:路径外TCP漏洞。

什么样叫做off-path呢?简单来说,就是攻击者不在TCP连接的路径上。众所周知,TCP是有连接的,并且在连接建立以后,这条连接路径在断开前都将保持。

举个例子:传统意义上的中间人攻击就属于处在通讯路径中的典型。

而对off-path型的漏洞的利用,是不需要攻击者接入通讯双方的网络中的。

一旦成功劫持了TCP连接,你就可以控制双方的传输内容,从而插入虚假信息。

中间人攻击 Man-in-the-middle attack

中间人攻击(Man-in-the-middle attack 缩写:MITM)

中间人攻击主要指攻击者在通讯的两端创建独立连接,交换获得数据,可能会对数据进行拦截,篡改,伪造,致使两端的通讯者以为双方的连接是私密连接。

Introduction

Side channels已经成为了一种网络攻击的流行工具。包括 CVE-2016-5696 在内的众多漏洞,使得TCP连接变得不安全,TCP传递的信息可以被监听和篡改。而这些可以被利用的缺陷,从根本原理上说,都是由于attacker和victim之间的资源共享机制导致的。

这种shared resuorces其实大量存在。攻击者通过观察这些共享资源,往往可以得到一些推断。


所有已经存在的off-path TCP exploit都起源于软件设计的问题。大多数这样的漏洞,都通过修改软件来修复:

  • 删掉一些本来在协议中存在的共享资源
  • 减少共享资源泄露信息的机会
    • 设计一种更严格的ACK号检查方法

在这些努力下,几乎所有以前的off-path TCP exploit都已经不再work了。


不同于软件的side channel,本文中提出的是一个更加fundamental的side channel,它深植于IEEE 802.11或WIFI技术——基于半双工的形式。

From its definition: when there are uplink wireless frames being transmitted, downlink frames have to wait, and vice versa.

基础设计上像是benign(良性的)——创造了一个对上行下行的流量非常敏感的timing channel。

For example, a downlink packet measuring the RTT will incur a higher latency if uplink traffic is going on.

这意味着,攻击者如果设计了一个比较合适的数据包序列,就可能劫持TCP流量。

在进一步的实验中,他们还发现这个timing channel具有很强的稳定性,即使攻击者和victim相距遥远(RTT > 20ms)。

主要贡献

  • timing side channel漏洞广泛存在于所有的IEEE 802.11或WIFI技术栈中,而且根深蒂固,几乎不可能从802.11中去除。
  • 文中验证了这个side channel影响maxOS、Windows、Linux等操作系统,而且是目前唯一可行的 off-path TCP exploit。
  • 进行一系列的实验,对比和分析了文中提出的攻击方式在不同的路由器/网络/操作系统/浏览器的组合中的表现。最后还提出了一些如何减轻攻击损失(mitigation)的办法。

Off-path TCP Exploits

上图展示了一个典型的off-path TCP劫持模型,包括三方:a victim client, a victim server and an off-path attacker。(Mallory就是一个attacker的常用名)

和中间人攻击不同的是,attacker无法监听客户C和服务器S之间的消息。它可以做的只是伪造身份发送一些数据包。attacker通过不断地监听共享信息来进行推断,最后达到伪造在TCP层上可以被客户端接收的效果。

在通常的TCP off-path side channel attack中,有两个必要的前提:

  • existence of vulnerable packet validation logic
  • the shared state has to be observable by an attacker

当这两个前提中的任意一个不满足时,相应的attack方式也就失效了。本文中进一步展示了多个之前基于这些前提的假设,并解释了为什么它们失效。

Simply put, they either rely on outdated TCP packet validation logic or shared state that can be easily eliminated.

TCP packet validation logic

作者通过展示最新的RFC标准来解释为什么针对旧版本的attack现在失效了。

尽管不同操作系统对RFC的实现不同,但是它们仍然会尽量地去遵循标准。

上图展示了最新的RFC的logic。其中包含了三种形式的检查,每一种都存在某种易被攻击的点——针对不同的结果,RFC逻辑会输出不同的行为。

读着读着发现一个语法错误:comfirm the loss (of) the previous connection

  • Connection (four-tuple) Identification
    • 检测一个流入的数据包是否属于某个特定已建立的TCP连接
      • 四元组:源端口号,目的端口号,源IP,目的IP
    • challenge ACK:当收到TCP连接的结束信号SYN时,目的端将再发送一个challenge ACK来回应源端,以确保真的结束(防止attacker做伪造断开连接的攻击)
  • Sequence number check
    • 检查,确保数据包的序号落在接收窗口内
    • 防止off-path RST攻击:类似地,只有当新的seq序号和next expected的seq序号匹配的时候,接收方才会中断连接;否则接收方也要发送一个challenge ACK
  • ACK number check
    • RFC中规定了ACK序号的有效值范围(占据ACK序号命名空间的一半),超出这个范围将被认为是无效的ACK
      • 因为占据了一半的命名空间,因此攻击者只需要猜两个ACK序号,就能够成功伪造出合法的ACK序号
    • 若ACK落在窗口外,丢包并发送相应的失败ACK
    • 若ACK在窗口内但没有payload,则进行静默丢包
    • 为了控制challenge ACK的拥塞程度,系统管理者通常会指定一段时间内challenge ACK的最大传输量

ACK和SEQ直接暴力猜测是很难的,因为都是32位的随机数。端口号16位。

Prior Attacks and Side Channels

共享状态(shared state)导致了side channel的出现,与之前所说的TCP packet validation logic组合在一起,形成了许许多多潜在的攻击方法。

Global IPID counter

直到最近,Windows系统是唯一维护了一个全局的自增IPID的操作系统,IPID使用在所有的IP头中,覆盖了所有的连接。

这就创造了一个旁道攻击(side-channel attacks)的可能,攻击者只需要对某段时间内的IPID进行几次拦截获取,就可以轻易地统计出这段时间内数据包的发送总量。有了统计信息后,攻击者就有可能推测出某个伪造的数据包是否触发了response。

不过最新的Windows版本已经对不同IP的连接已经使用了独立的IPID计数。

Browser page read

shared state:browser page

在浏览器网页中,攻击者通过嵌入恶意的Javascript程序来植入数据。

攻击方式主要来源于三方面:

  • 旧版操作系统执行RFC 793——认为ACK命名空间是一半有效的,因此攻击者只需要猜两次就可以猜中一个有效的ACK,从而成功地inject data
    • 大多数现代浏览器消除了这一漏洞,并采用更严格更狭窄的ACK有效空间
  • 现代浏览器过于鲁棒,允许HTTP的response header缺失,并自动填充
  • HTTP pipeline约束:任何提前到达的response都被视为有效
    • 现代浏览器禁用/没有实现这一个pipeline

Global challenge ACK rate limit

Linux内核首次实现了RFC 5961(v3.6)的所有特性,并实现了ACK流量的全局控制。

它引入了一个全局系统变量,控制每秒challenge ACK的最大产生量。

攻击者通过让ACK过载,来使得challenge ACK的产生数量可控,从而判断自己之前发送的伪造数据包是否匹配了被攻击的连接的四元组(源端口号,目的端口号,源IP,目的IP)。

最新的Linux中移除了这一软件性质的漏洞(全局变量),并引入了 per-socket rate limit

System-wide packet counter

Packet counters:记录整合了所有连接的统计数据。

对于side channel来说,这样的记录器就是一个很reliable的共享状态了,可以从中获取一些关键信息。

In the extreme case, for example, a Linux/Android TCP packet named DelayedACKLost is incremented only when it receives a packet with a sequence number smaller than the expected one. This allows an attacker to conduct a binary search on the expected sequence number.

这个side channel目前还存在(Linux and Android 8.0)。

WIFI Timing Channel

WIFI半双工的设计使得“shared resource”在上行和下行流量中产生了。因为不可同时进行双向通信,所以双方要进行某种形式的等待(如:CSMA协议),从而实现对信道的共享/分配。

This effectively creates a timing channel that delays the local transmission if the opposite direction is transmitting at the same time.

当发生碰撞(信道冲突)的时候,造成的timing difference甚至会更明显。

  • 如果伪造的数据包没有trigger一个ACK,将得到更小的RTT
  • 反之,将测得更长的RTT

这个新的side channel允许攻击者判断伪造的探测数据包是否引发了任何的response,凑巧地实现了和global IPID counter类似的目的。

其它内容

暂时没有时间细看了。。

Defenses

WIFI

  • 最直接的方法:把WIFI协议改成全双工信道
    • 但是这样会挤占带宽,在现实应用还存在困难

TCP stacks

One solution is to revisit the specification and look for alternatives.

如果将ACK的rate limit细分为多个类别,那么:the differences in responses (e.g., one response vs. zero) will be small enough and impossible to measure.

Application layer

借助HSTH、HTTPS等应用层的安全协议来防范攻击者。

当检测到任何异常的response时,浏览器立刻中断连接并重启。

总结与展望

本文发现了一个深植于WIFI协议中的基础性side channel,原因在于其的半双工特性。进一步,研究员证明了这个漏洞是可以在实际中利用的,并具有很高的稳定性和攻击性,广泛存在于主流的三大操作系统中。最后他们设计了一系列评估实验。在文章的最后,研究员还提出了一些可能的防卫这种攻击的解决方案。

我个人感觉这种找漏洞发Paper的方式还是有点靠运气、偏工程的,读了好多篇网络方面的paper,似乎主要还是集中在某种改进,某个现象之类的东西。但是,能够发生这样一种根深蒂固在网络协议设计层面上的漏洞,而且看起来短期没有办法消解,还是一个非常有价值的研究。




Presentation Draft

论文展示.pdf

文章介绍

《Off-Path TCP Exploit: How Wireless Routers Can Jeopardize Your Secrets》是一篇来自加州大学河滨分校,发表在USENIX Security(信息安全领域四大顶级学术会议之一)2018年的会议论文。

本论文从属于子领域Wireless Attacks(无线攻击)。

这篇文章发现了一个timing side channel,其广泛存在于所有基于IEEE 802.11或者WIFI技术的产品上。之前TCP的injection attack一般都是因为软件漏洞,从而可以通过更新软件的方式来让漏洞消失。

但是,这篇文章发现的问题是基于WIFI半双工这种底层机制的。

研究员利用这个side channel,成功在多个主流操作系统(macOS, Windows, and Linux)上实施了攻击。

Generic Threat Model

中间人攻击 Man-in-the-middle attack

中间人攻击主要指攻击者在通讯的两端创建独立连接,交换获得数据,可能会对数据进行拦截,篡改,伪造,致使两端的通讯者以为双方的连接是私密连接

Off-Path TCP Exploit

Off-Path TCP Exploit:路径外TCP漏洞。

什么样叫做off-path呢?简单来说,就是攻击者不在TCP连接的路径上

也就是说,攻击者不能直接监听客户端和服务器之间建立的虚拟信道

但是,由于TCP是建立在通信网络上的虚拟信道,所以路径外的攻击者是可以发送数据包进行干扰的。

众所周知,TCP是有连接的,并且在连接建立以后,这条连接路径在断开前都将保持。

举个例子:传统意义上的中间人攻击就属于处在通讯路径中的典型。

不同于中间人攻击。攻击者在线路以外,通过发送伪造数据包,来观测客户端的反应,从而推测(Inference)出某些信息。

一旦成功获取了足够信息(相当于劫持了TCP连接),你就可以控制双方的传输内容,从而插入虚假信息。

什么是侧信道?

路径外TCP漏洞常常是借助侧信道(Side channels)的方式完成的。

Side channels就是那些在一个攻击过程中,attacker可以观测或者获取的相关信息

Side channels已经成为了一种网络攻击的流行工具。这些漏洞,使得TCP连接变得不安全,TCP传递的信息可以被监听和篡改。

侧信道攻击Demo

比如,用户想要访问Facebook。

一个手机上正在监听系统的恶意程序,与一个off-path attacker进行合作。

这样off-path attacker就可以劫持连接,并且注入虚假数据。

这称为 TCP injection attacks。

侧信道攻击的本质

而这些可以被利用的Side channels,从根本原理上说,都是由于attacker和victim之间的资源共享机制导致的。

这种shared resuorces其实大量存在。攻击者通过观察这些共享资源,往往可以得到一些推断。


所有已经存在的off-path TCP exploit都起源于软件设计的问题。大多数这样的漏洞,都通过修改软件来修复:

  • 删掉一些本来在协议中存在的共享资源
  • 减少共享资源泄露信息的机会
    • 设计一种更严格的ACK号检查方法

在这些努力下,几乎所有以前的off-path TCP exploit都已经不再work了。

侧信道攻击的必要条件:

  • 存在共享变量
  • 共享变量可以被观测

攻击发展时间线

简单介绍历史上的攻击-防御对抗研究的发展脉络。

几种攻击方式

本文提出的无线攻击方法,需要在客户端上安装特定的JavaScript程序。

Global IPID counter

直到最近,Windows系统是唯一维护了一个全局的自增IPID的操作系统,IPID使用在所有的IP头中,覆盖了所有的连接。

这就创造了一个旁道攻击(side-channel attacks)的可能,攻击者只需要对某段时间内的IPID进行几次拦截获取,就可以轻易地统计出这段时间内数据包的发送总量。有了统计信息后,攻击者就有可能推测出某个伪造的数据包是否触发了response。

不过最新的Windows版本已经对不同IP的连接已经使用了独立的IPID计数。

Global challenge ACK rate limit

Linux为了实现了ACK流量的全局控制。引入了一个全局系统变量,控制每秒challenge ACK的最大产生量。

攻击者通过让ACK过载,来使得challenge ACK的产生数量可控,从而判断自己之前发送的伪造数据包是否匹配了被攻击的连接的四元组(源端口号,目的端口号,源IP,目的IP)。

最新的Linux中移除了这一软件性质的漏洞(全局变量),并引入了 per-socket rate limit

Packet counter

Packet counters:记录整合了所有连接的统计数据

对于side channel来说,这样的记录器就是一个很reliable的共享状态了,可以从中获取一些关键信息。

In the extreme case, for example, a Linux/Android TCP packet named DelayedACKLost is incremented only when it receives a packet with a sequence number smaller than the expected one. This allows an attacker to conduct a binary search on the expected sequence number.

这个side channel目前还存在(Linux and Android 8.0)。


验证Inference

验证顺序:

  • 验证client的端口号
  • 然后验证Seq号
  • 验证ACK号

作者在论文中展示了最新的一个TCP接收数据包的流程图

  • Connection (four-tuple) Identification
    • 检测一个流入的数据包是否属于某个特定已建立的TCP连接
      • 四元组:源端口号,目的端口号,源IP,目的IP
    • challenge ACK:当收到TCP连接的结束信号SYN时,目的端将再发送一个challenge ACK来回应源端,以确保真的结束(防止attacker做伪造断开连接的攻击)
  • Sequence number check
    • 检查,确保数据包的序号落在接收窗口内
    • 防止off-path RST攻击:类似地,只有当新的seq序号和next expected的seq序号匹配的时候,接收方才会中断连接;否则接收方也要发送一个challenge ACK
  • ACK number check
    • RFC中规定了ACK序号的有效值范围(占据ACK序号命名空间的一半),超出这个范围将被认为是无效的ACK
      • 因为占据了一半的命名空间,因此攻击者只需要猜两个ACK序号,就能够成功伪造出合法的ACK序号
    • 若ACK落在窗口外,丢包并发送相应的失败ACK
    • 若ACK在窗口内但没有payload,则进行静默丢包
    • 为了控制challenge ACK的拥塞程度,系统管理者通常会指定一段时间内challenge ACK的最大传输量

端口号Inference

如果猜对了端口号,client会发送回信。如果猜不对或者没有连接,cilent就不发送。

但是,client在信道上发送的东西,我们是看不到的。

所以要借助Side channel。

One Plausble idea 一个简单的idea

client的CPU在生成一个response的时候是需要一些CPU资源(CPU cycles,几十到几百微秒)。

假设cilent只有一个CPU。

那么如果attack发送一个query的话,它得到响应的时间(RTT)就会相应的延长。

这个idea的问题在于,这个RTT的差别实在太小了,无法做出可信的测量(not measurable)。

Wireless Timing Channel

但是,作者指出,在无线网络的环境下,这个Delay就是measurable的了

根源在于WIFI的半双工(half-duplex)设计。

因为不可同时进行双向通信,所以双方要进行某种形式的等待(如:CSMA协议),来实现对信道的共享/分配。

这就使得“shared resource”在上行和下行流量中产生了。

This effectively creates a timing channel that delays the local transmission if the opposite direction is transmitting at the same time.

WIFI中使用半双工设计的原因是因为相同频率同时发射会互相干扰。就算不同频率,想要滤波或者处理实现全双工,目前WIFI全双工研究的结果显示代价都很大。

Probing Strategy

发送spoofed packet。

  • 没有trgger ACK的情况
  • trgger了 ACK的情况

这两种情况下,attack发出的query所测得的RTT的差别就很大了。

发生碰撞(信道冲突)的重传时延是比较大的

这样,就可以推断出是否猜到了正确的端口号了!

当然,这样的RTT差别可能还不足够可信,我们可以放大延迟信号。attack发送多个伪造数据包(probing packet),从而引起更多的response,从而造成更多的碰撞,RTT变得更长了!

实验记录

首先是local的环境测试:

  • 可以看到,有ACK和没有ACK的RTT差异是很明显的,也就是measurable的。大概在2毫秒左右。

然后是远距离测试:(RTT约等于20ms)

  • 这个时候,RTT的差异大约在5毫秒左右。

猜测Seq

我们已经猜到了端口号。

用类似的方法,可以继续猜测seqence number是否合法。

不同OS下的表现

作者还研究了不同操作系统下整个infer过程是否一致。实验结果表明是一致的。

猜测ACK号

最后是ACK号的inference。

不同OS下ACK号的检查机制有很大的差异。有兴趣的可以去看看论文的原文。

我们最终的目标是实现TCP injection。我们并不需要知道准确的ACK号。

这里就变成brute force的方式来找一个合法的ACK号。

鸽巢原理~~

最后用时几秒钟,效率上也能接受。

整体的Evaluation

整个TCP injection的耗时。几分钟。还是可以实际使用的。

再来一个Demo

展示了在网页中嵌入伪造的用户登录项。并且保存到浏览器缓存中。

解决方案

  • 在WIFI协议中引入全双工
  • TCP协议的调整
    • 对于相同的probing packets只回复有限数量的response,使得 “放大RTT之差” 变得不可行
  • 在应用层使用更安全的HSTS协议
    • 使用HTTP协议的一端易受攻击

总结

  • 发现了WIFI Timing Side Channel
  • 分析了不同环境下TCP的实现机制
  • 基于本文中的side channel实验了TCP injection攻击
  • 提出了一些防御措施

https://github.com/seclab-ucr/tcp_exploit