完了！TCP出了大事！

前情回顾：《非中间人就不能劫持TCP了吗？》

不速之客

夜黑风高，乌云蔽月。

两位不速之客，身着黑衣，一高一矮，潜入Linux帝国。

这一潜就是一个多月，直到他们收到了一条消息······

高个：“上峰终于给我们派任务了”

矮个：“什么任务？我都闲的发慌了”

高个：“上峰让我们配合他们完成TCP连接的劫持”

矮个：“TCP劫持？我们就是个普通程序，并没有内核权限，怎么去修改网络连接啊，这不是强人所难嘛”

高个：“是啊，我也很奇怪。信上只约定了让我们到时候告诉他们一个计数器的值就行，其他我们不用管”

矮个：“计数器，什么计数器？”

高个：“DelayedACKLost，信上说执行cat /proc/net/netstat就能看到”

矮个：“不需要特殊权限吗？”

高个：“我也不知道，要不咱先试一下？”

两人收起信件，环顾一圈，见四下无人，便偷偷执行了这一条命令：

“这都是些什么啊？怎么这么多？”，矮个子问到。

“看样子，像是记录了Linux帝国网络协议栈的很多统计信息”，高个子一边说一边仔细的查看着。

“这些信息居然是公开的，谁都可以看？”

“也只能看，又改不了。怕啥？快找吧，找到DelayedACKLost再说”

两人瞪大了眼睛，总算在一片密密麻麻的输出中，找到了他们要的计数器。

可这一个小小的计数器怎么就能助上峰完成TCP的劫持，二人却是百思不得其解。

秘密任务

第二天晚上。

“快醒醒，上峰又来消息了”，在高个子的一阵摇晃中，矮个睁开了困顿的双眼。

“又是什么消息啊？”

“让我们立即汇报DelayedACKLost的值”

两人赶紧起身，再次执行了那条命令，拿到了计数器的值，报了上去。

刚发完消息还没缓过神，上峰的指示又来了：DelayedACKLost有无增加？

两人互相看了一眼，不解其意，不过还是再次查看了计数器，确认没有增加，再次把结果报了上去。

就这样，来来回回几十次，上峰一直询问这个计数器有无增加，可把哥俩忙坏了。

终于，上峰不再来消息，两人有了喘息的时间。

古怪的TCP连接

而此刻，Linux帝国网络部协议栈大厦还是灯火通明。

“今晚是怎么回事，网络怎么这么差，我都收到了好多错误包了”，新来的Robert叹了口气。

“不至于吧，是不是因为刚来还不太熟练？”，一旁的Cerf随口问到。

“不是啊，有一条连接，我收到的包序列号不是太小，就是太大，搞了好多次才正确的，我还没见过这种情况呢！”，Robert继续说到。

一听这话，Cerf赶紧放下了手里的工作，来到Robert工位旁边，“这么邪乎？你说这情况我来这里这么久也没见过，让我看看”

Cerf仔细查看了过去一段时间的通信，这条连接上，不断有数据包发送过来，但因为TCP序列号一直不对，所以一直给丢掉了。

“有点奇怪，这家伙怎么感觉像是在猜序列号啊？而且奇怪的是最终居然让他给猜出来了！这条连接一定有古怪，多半是被人劫持了。劫持方因为不知道序列号，所以一直在尝试猜测序列号”，Cerf说到。

Robert也看了一看，“你这么一说，确实是，而且你看，他不是瞎猜，好像是用二分法在猜！序列号是个32位的整数，二分法猜测，只需要32次就能猜出来”

“二分法？要用二分法的前提他得知道他是猜大了还是猜小了，得不到这个反馈，他就只能瞎猜了。他是如何得知猜大还是猜小的呢？”

两人思来想去，也想不通对方是如何用二分法猜出了最终的序列号，随后将此事报给了网络部传输层主管，主管又将这事报给了帝国安全部长。

揪出潜伏者

部长得知这个消息后，高度重视，要求全面排查网络部TCP小组相关的代码。

大家寻着TCP数据包处理的流程，在序列号检查处的位置发现了问题。

如果序列号检查不通过，就会进入tcp_send_dupack，大家都把注意力放到了这里：

“这里这个before判断是什么意思？”，主管问到。

Cerf上前回答说：“这是在判断收到的数据包的序列号是不是比期望的序列号小，如果小的话，说明网络有重传，就要关闭延迟回复ACK的机制，需要立即回复ACK”

“延迟回复ACK？”

“哦，主管，这是我们TCP小组的一个优化，TCP传输需要确认，但是如果每一次交互数据都发送ACK就太浪费了，所以我们做了一个优化，等到多次或者有数据发送的时候，一并把回复的ACK带上，就不用了每次发送ACK报文，我们把这个叫Delayed ACK，也就是延迟确认。”，Cerf继续解释到。

“那下面这个tcp_enter_quickack_mode是不是就是关闭这个机制，进入快速ACK回复模式？”，主管问到。

“没错没错！”

这时，安全部长指着一行问到，“这里看着有些古怪，是在干嘛？”

“这个我知道，Cerf昨天教过我，这个是在进行统计。把这一次延迟ACK的丢失计入对应的全局计数器中”，Robert说到。

经验老道的安全部长此刻意识到了问题，“如此看来，收到的序列号比期望小的时候，这个计数器才会增加，如果大了就不会增加。各位试想一下，如果那个猜测的家伙能看到这个计数器有无增长，不就能知道是猜大了还是猜小了？”

Robert摇了摇头说到：“不会吧，这计数器在我们这里，网络上其他人怎么可能知道。再说了，这个计数器大家都在用，用这个判断，误差太大啦！”

主管也摇了摇头，“不对，虽说是大家都在用，不过这里这个计数器很特别，发生的概率很小，一般不会走到这里来，网络哪那么容易出问题嘛”

安全部长说到：“根据目前掌握的信息，之前就有其他部门反映帝国有奸细混了进来，不过他们一直藏在暗处，至今还没有揪出来。如若他们和外界勾结，作为眼线，观察这个计数器的变化，外面就能知道他的猜测是大是小。对，一定是这样！”

随后，安全部长来到了文件系统部门，调用了/proc/net/netstat的访问记录，根据记录很快定位到了隐藏在Linux帝国的两个细作，下令将他们逮捕。

高矮两位奸细如实交代了一切······

未完待续······

彩蛋

“老大，我们派出的潜伏者失去联系了”

“无妨，没有那两个笨蛋，我也能劫持TCP”

预知后事如何，请关注后续精彩······

本文的攻击手法改编自看雪2018峰会，网络安全大牛钱志云分享的主题《TCP的厄运，网络协议侧信道分析及利用》

看雪论坛原文链接：https://bbs.pediy.com/thread-245982.htm

往期TOP5文章

CPU明明8个核，网卡为啥拼命折腾一号核？