TCP旁路劫持，糟糕的RFC5961

RFC5961 & CVE-2016-5696，哈哈，典型的拆了东墙补西墙，瘸子治成哑巴。

我一直坚信，信息安全的最高机密就是三缄其口，沉默是金。通俗点说就是不和陌生人说话，不和逼逼的人交谈。

但是TCP偏不，所以TCP不安全。

TCP是一个30多年前的古老的协议，如果不是为了兼容，早就该歇了，但是它却一直活着，使我不得开心颜。

30多年前的网络环境，那是伊始，默认就是一个可信的环境！现在完全不一样。

TCP连接劫持理论上是一件非常容易的事情，因为TCP的所有协议信息全部明文暴露，即便是旁路探测，一个32位的序列号还是容易猜出来的。

考虑到TCP是端到端协议，并不理解中间网络，因此TCP协议的收发端都容忍了乱序，在接收端表现为OFO队列，在发送端发送队列可以被SACK。因此TCP的接收端必须是无条件接收 一个范围而不是特定的一个序列号字节 的数据。

这便给了连接劫持者以可乘之机。因为只要劫持者猜中了一个范围，那么接收端就必须予以回应。

该范围由接收端主机的接收窗口决定，考虑到当前主机的内存越来越大，这个可以被猜中的范围也就越来越大，换句话说，TCP随着网络和主机能力的提高，越来越容易被劫持，越来越不安全。

TCP的接收端无法区分一个数据包来自真正的对端还是来自一个中间人的恶意攻击，这便很尴尬。如果该数据包是中间人的劫持数据包，且数据包包含数据，那么连接的数据将会被污染，如果该数据包有Reset标记，那么连接将会被Rest…

其实，只需要探测采集即可。劫持者持续建立新连接，然后采集时间和序列号信息，画图做函数，基本就能猜出被劫持侧的序列号生成规则了。

如何弥补？

好吧，RFC5961来了：
https://www.rfc-archive.org/getrfc?rfc=5961
可是问题解决了吗？远远没有！

RFC5961竟然违背了 三缄其口沉默是金 的原则啊，它竟然主动发送了一个所谓challenge ACK，试图弥补之前盲目就范的过失，然而却并非如此。

且不说画蛇添足的ACK Throttling被利用，单单这个challenge ACK就有问题。你试图阻止旁路劫持，然而如果不是旁路呢？challenge ACK不还是主动提供了自己的信息给了劫持者吗？然而接收端确实无法沉默是金，因为它真的没法区分来者。

好吧，姑且承认RFC5961确实让TCP旁路劫持更困难了，它的添足之笔甚是精妙，为了不至于这种challenge ACK太多，建议系统配置一个门限值，然后就被利用了。多么讽刺打脸的一件事啊。

CVE-2016-5696的细节参考这篇文章，写的很清楚了：
https://www.anquanke.com/post/id/84479

最近接触一些Quic方面的东西，Quic就把ACK这些全部都加密保护了，使得外部根本无法利用明文协议字段来进行劫持，这是好事吗？这是好事！然而人们偏偏不接受新事物。

人们会说，Quic加密了这些字段，那么中间设备将无法根据这些字段进行分析调优…我的天啊，你一个端到端协议，自己的CC算法做好就好了啊，让中间设备介入毛线啊！你会说，TCP不就是这样吗？我靠，那你是被TCP洗脑了吧，TCP那是做不到，Quic如何能做的更好，还用中间设备吗？！就好像前天我谈GUI，有人说专业人士都喜欢留空桌面，把所有东西都放在开始菜单里…搞笑，这是被微软洗脑了。

浙江温州皮鞋湿，下雨进水不会胖。

TCP旁路劫持，糟糕的RFC5961相关推荐

TCP会话劫持原理与测试
阅读本文之前建议了解 TCP 三次握手过程以及 TCP 的包头详细信息. 由于 TCP 协议并没有对 TCP 的传输包进行验证,所以在我们知道一个 TCP 连接中的 seq 和 ack 的信息后就可以 ...
TCP/IP攻击实验（ARP，ICMP，SYN，RST，TCP会话劫持）
一.实验背景由于TCP/IP协议是Internet的基础协议,从开始设计的时候并没有考虑到现在网络上如此多的威胁,由此导致了许多形形色色的攻击方法,一般如果是针对协议原理的攻击,尤其DDOS,我们将 ...
TCP会话劫持攻击实验
会话劫持攻击实验实验环境: kali(192.168.157.2)(攻击机) centos 7(192.168.157.3)(服务端) ubuntu(192.168.157.4)(客户端) 使用工具 ...
『网络协议攻防实验』TCP会话劫持攻击
前言靶机1:seedubuntu 12.01,IP:192.168.199.137 靶机2:WindowsXP SP2,IP:192.168.199.135 攻击机:Kali-2020.4,IP:1 ...
php会话劫持,TCP会话劫持原理与测试
阅读本文之前建议了解 TCP 三次握手过程以及 TCP 的包头详细信息. 由于 TCP 协议并没有对 TCP 的传输包进行验证,所以在我们知道一个 TCP 连接中的 seq 和 ack 的信息后就可以 ...
基于hunt1.5的TCP会话劫持
基于hunt的TCP会话劫持 TCP会话劫持攻击,是劫持通信双方已建立的TCP会话连接,假冒其中一方身份与另一方进行进一步通信.攻击者通过ARP欺骗.ICMP路由重定向攻击等方法实现中间人攻击,嗅 ...
【HUST】网络攻防实践｜TCP会话劫持+序列号攻击netcat对话
文章目录一.前言 1. 实验环境 2. 攻击对象 3. 攻击目的 4. 最终效果 docker的使用新建docker docker常用指令二.正式开始过程记录 1. ARP欺骗 2. 篡改数据 ...
协议分析之TCP旁路阻断
一.阻断未建立起来的连接我们知道TCP的建立要经过3次握手,假设客户端C向服务器S请求连接 1.C发送带有SEQ_C(随机)初始序列号的SYN报文给S 2.S回复带有SEQ_S(随机)初始序列号和确 ...
修改服务器劫包,APP游戏TCP包被劫持篡改的一些解决方案
根据中间人的测试方案可以直接看到漏洞在游戏客户端的显示效果,大大提高了漏洞发现的效率:但是与上一代方案相比,仍然有两个问题没有解决:协议访问时间长,因为协议包解析涉及到粘贴和解包等问题,比较复杂,不仅 ...

TCP旁路劫持，糟糕的RFC5961

TCP旁路劫持，糟糕的RFC5961相关推荐

最新文章

热门文章