DEMO: TCP Reset Attack

A TCP reset attack is going to disconnect two devices that are speaking with each other. This machine is speaking to a server, and then we, as an adversary, are going to send a reset attack, and therefore communication is going to drop between these two devices.

A refresher on TCP

Before we jump into how we carry out the attack, let's do a little refresher on TCP and how TCP sets up communication. TCP is in layer 4, the transport layer. In this layer 4, quite typically it's either TCP or UDP traffic, at least in the standard protocols in the TCP/IP stack. We call this a segment, and the reason we call it a segment is because we're taking data and breaking it into smaller pieces, which will become our packet, and then we're putting a header at the front end with some information about how to reassemble it on the other side. So there are sequence numbers on how to reassemble it.

Here's that TCP header. We're not going to get into detail about it, but we are going to talk about a few parts that are going to be critical to what we're going to do. Essentially, this TCP header has a source port and a destination port. It has sequence numbers and acknowledgement numbers, and it has some flags. As it's sending over, it knows what port it's addressing, the destination port, and it's got the sequence and acknowledgement numbers. Those sequence and acknowledgement numbers help make sure that no traffic is getting dropped along the way. A computer is going to make a request for some sort of information, and then this server is going to reply back with fulfilling that request. Maybe this is downloading some sort of web page, and then the computer is going to acknowledge, and then there's going to be some more data that comes back. So it's going to do it in sets of information sent over from the server to the computer, and then the computer does some sort of acknowledgement just to make sure that they're both on the same page and that no data has been lost.

Setup and teardown

Before all of that communication happens, there is some sort of connection that gets set up. The computer is going to start by making a TCP connection, and that's what the first packet sent over to the server is. The server is going to acknowledge that with a SYN-ACK, and then there's going to be one last acknowledgement back. This three-way handshake sets up a connection between these two devices. Then the bulk of the communication happens back and forth. When the communication is done, we're going to send a finish, there's going to be a finish acknowledgement, and then an acknowledgement. So there's a setup for this communication and then a teardown.

In that communication back and forth, there are something called flags. What we were seeing there are the SYNs, the SYN-ACK, and the ACK. Those are flags that are being turned on in the header. These are all zeros unless we turn them on. So when we want to synchronize or start a communication, we turn the SYN on, and that's a "hey, can we speak?" Then the other machine will send back with a SYN acknowledgement, so the acknowledgement will be turned on, and then the machine establishing this communication is going to turn off the SYN. So we have the SYN turned off; it's just the acknowledgement flag that's turned on. That's going to start that communication. Same thing when we're finishing the communication: we can flag that with a one in the flag for the finish.

Why a reset exists

There are times when this connection doesn't happen cleanly, and that's one of the reasons for the TCP reset: maybe there's some sort of connection issue between two devices and one of them needs to send a reset to reset this communication. Let's come up with a scenario where maybe this server is having an issue. Initially this machine sets up a TCP connection, so they have a connection, and then it makes its request and says, hey, can you give me this web page, and the server starts fulfilling that. It starts sending data back over, and this computer sends an acknowledgement over, but then doesn't hear a reply back because there are issues on this server. This client machine doesn't know that the connection is lost, doesn't know that the server is having any issues, so it's going to still try to reach out and connect with the server. The purpose for the reset condition is for this server to tell this computer, hey, I know you're trying to communicate to me, but I'm sorry, I've lost the connection, we're going to have to reestablish that, we're going to have to reset it.

The attack

Here's an opportunity, though, to carry out a denial of service attack. This is the communication that's supposed to happen between these two devices, but a machine here, an adversary, wants to disconnect this communication from happening, causing problems. Whatever the case may be, we want to cause an issue between these two devices, cause a denial of service attack. So what we're going to do is spoof this server and send a message over to the client and say, hey, I need to reset things, I need to disconnect. Now this connection gets lost and it interrupts this connection. Maybe it's a huge download that was happening, and now this machine has to restart that whole download; or maybe it's really time-sensitive that these two devices stay up and running, and this disconnect crashes the whole system. There could be many repercussions from this TCP reset attack.

How the TCP reset happens: it just turns on this reset flag. By turning that on, it just needs to have this one-way communication. It doesn't need to tear down the connection; it just needs to send this one packet, and this one packet is going to terminate the communication. Just a reminder to practice ethical hacking: make sure you only do this on your own network, or a network that you've gotten permission to carry out this type of attack on.

Carrying it out in the demo

I'm on a demo laptop to show you how to do this TCP reset. The first thing I'm going to do is show you the IP address of this laptop. I'm going to type in cmd to bring up the command prompt, and type in ipconfig. This demo laptop has an IP address of 10.110.194. We're going to be connecting via SSH into a switch. On the left-hand side I've got PuTTY up, and we're going to use PuTTY to SSH into the switch. On the right-hand side I've got Wireshark, so we can see the communication that happens between this demo machine and the switch, and see that TCP traffic. I already have the filter turned on, so we're filtering from this laptop, which is .194, to that switch, which is .11 on the same network.

Let's make the connection and see what happens. I'm going to restart the session, and I'll have to type in a password. I'm going to grab the password and paste it in, and you can see the communication happening on the left. We're connected now, SSHed into this switch. The communication that starts out is the three-way handshake. TCP sets it up: it says, hey, I'd like to talk, going from the source, this laptop, to the destination, the switch, and the switch says, okay, that's good to go, and then the computer says, great, we're talking. Then we get into the SSH communication. Every once in a while we see that this laptop sends a message and says, we're good to go; those are the acknowledgements coming back. The last one is the desktop sends an acknowledgement to the switch and says, yep, we're still talking, we're still good to go.

This last transmission is going to be critical in forming our attack. The information that's critical is that we have to mimic what's going to come from the switch to the PC. We're going to say, hey, I'm the switch and I'm asking to disconnect. What we need to mimic is, first of all, the IP address. We're going to spoof the 10.110.11 and send it to the destination IP address of 10.110.194. It's going to be a TCP disconnect. We'll also have to grab the ports. So 4188 is that ephemeral port that the machine is using for this connection, and it's connecting to this switch, which is on port 22. Then we also see the sequence number, the sequence of what's being sent from the laptop to the switch. And then we have an acknowledgement number. We'll need those two pieces of information. That's how we're going to mimic that we're this other machine, by duplicating that data.

Sending the reset from Kali

I'm on my Kali Linux box. This is what is going to be the adversary that's going to send this reset command, this reset flag. What we're going to do is start with our sudo command, and then we're using hping3 for this. The destination is the laptop, so the laptop IP address, as we looked it up, was 10.110.194. Then we're going to use the -a, because we're spoofing something; -a allows us to spoof another machine. We're going to spoof the switch, so 10.110.1 is the switch IP address, so we're sending a packet on behalf of this switch.

Next, we need the destination port. That's -p for the destination port, and the destination port is the port of the computer, which is 4188. Then the source port, that's -s, and the source port is 22, because we're going from the switch. Then we're going to type in -R. -R is the reset flag, so that turns that little reset flag from a zero to a one; we want that turned on. We also are going to turn on the acknowledgement flag. Then we do a -m, and this is for the sequence number, so we're going to specify the sequence number, and the sequence number is going to be what's coming from the switch to the computer. That would be this acknowledgement number, because the acknowledgement number is what this machine is expecting to be the next sequence number. So the acknowledgement number is going to be the sequence number of the switch. That's the one we're going to use, which is 607697020, so let me plug that in. Then next we're going to do a -l, and this is specifying the acknowledgement number, what it expects the next sequence number from the laptop to be. We can see here this is the next sequence number; Wireshark gives us this information. So 65791134. I'm going to plug that into this Kali Linux box.

Next we're going to specify how many of these we want to send, and in this case we just want to send one. So -c means count, and we're going to send just one; it only takes one packet to carry out this type of attack. Now let's go ahead and hit enter and see what happens. It does want a password here. We can see back on Wireshark that something has happened. That came in with the reset flag turned on. It came from the switch, because we spoofed the switch, to this machine, and it's TCP with the reset flag turned on. We click on PuTTY, and sure enough, the network error: software caused connection to abort. It has now been disconnected. PuTTY is no longer connected. In fact, I can hit okay, and we can see that this window is inactive.

Summary of the attack

To carry out that attack, all we did was mimic the IP addresses of those machines, the source ports, the sequence number, and the acknowledgement number; we turned on the acknowledgement flag; and we turned on the reset flag. That was enough to disconnect the connection between these two devices. It wasn't so big of a deal when we were just connecting SSH into a switch. But let's say this is a server talking to a server, or some other critical connection, or maybe you constantly send these to irritate the end user or cause some sort of disruption. This could become an attack that could be very significant. When two devices are communicating, they set up a TCP connection, and all we need to do is send a TCP reset to make those connections disappear, to make the connection drop.