Questions about this topic? Sign up to ask in the talk tab.

Difference between revisions of "TCP-RST Injection"

From NetSec
Jump to: navigation, search
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
 +
{{cleanup}}
 
==Introduction==
 
==Introduction==
  
 
This lecture is about TCP RST injection. TCP RST injection involves spoofing a TCP connection in place. TCP forms the backbone of many protocols, such as IRC, but recently its beginning to show its age. Connection speeds are much faster than they were in the 80's.
 
This lecture is about TCP RST injection. TCP RST injection involves spoofing a TCP connection in place. TCP forms the backbone of many protocols, such as IRC, but recently its beginning to show its age. Connection speeds are much faster than they were in the 80's.
  
So basically, you have two parties connected to each other, they do a TCP 'handshake', and assign a random sequence number between themselves (which has 2^32 possible combinations) as a precaution against spoofing. They also assign the TCP 'window' of the connection, or how far the sequence number embedded in a packet can be from the original sequence number. The larger the window, the more efficient the connection can be. Typical window sizes are from 15000 to 60000. The default is 65535. I've found ircds commonly use ~14000.
+
So basically, you have two parties connected to each other, they do a [[DDoS_Attacks#Three_way_handshake_and_Connect_State|TCP handshake]], and assign a random sequence number between themselves (which has 2^32 possible combinations) as a precaution against spoofing. They also assign the TCP 'window' of the connection, or how far the sequence number embedded in a packet can be from the original sequence number. The larger the window, the more efficient the connection can be. Typical window sizes are from 15000 to 60000. The default is 65535. I've found ircds commonly use ~14000.
  
The window can be exploited to find the sequence number of a connection, and successfully inject a RST packet. RST packets are special because they can be taken OUT OF ORDER in a TCP stream. Therefore, if you can acquire the sequence number in an active connection, you can inject a RST packet and split the two connected parties. This is actually common knowledge since Paul Watson's paper, 'slipping in the window' ( http://osvdb.org/ref/04/04030-SlippingInTheWindow_v1.0.doc ) was published and it was mentioned at this years blackhat convention.
+
The window can be exploited to find the sequence number of a connection, and successfully inject a RST packet. RST packets are special because they can be taken OUT OF ORDER in a TCP stream. Therefore, if you can acquire the sequence number in an active connection, you can inject a RST packet and split the two connected parties. This is actually common knowledge since Paul Watson's paper, 'slipping in the window' [http://osvdb.org/ref/04/04030-SlippingInTheWindow_v1.0.doc] was published and it was mentioned at this years blackhat convention.
  
Today however, we are going to focus on BLIND TCP RST injection. This means, you can disconnect two remote parties. Watson only considered the most ideal situation, which was a MITM (man in the middle) attack between two parties to keep them disconnection. Since 2003, the attack is changing. Today, we can blindly spoof a TCP connection and reset most any given connection.
+
Today however, we are going to focus on BLIND TCP RST injection. This means, you can disconnect two remote parties. Watson only considered the most ideal situation, which was a [[MITM_attack|MITM]] attack between two parties to keep them disconnection. Since 2003, the attack is changing. Today, we can blindly spoof a TCP connection and reset most any given connection.
  
 
==TCP RST Injection==
 
==TCP RST Injection==
Line 13: Line 14:
 
The first challenge we encounter is, we need to know what the connection is between. that is, the destination port and the source port. the destination port is whatever service the client is using. we'll use ircd (6667) for our example. The source port is randomized. There are a total of 65536 given ports. It would take a sort of long time to iterate through all 65535 ports which is why we don't.
 
The first challenge we encounter is, we need to know what the connection is between. that is, the destination port and the source port. the destination port is whatever service the client is using. we'll use ircd (6667) for our example. The source port is randomized. There are a total of 65536 given ports. It would take a sort of long time to iterate through all 65535 ports which is why we don't.
  
TCP can use ephemeral ports temporarily. The ephemeral range is somewhat controversial. Most linux kernels use 32768 to 61000, while windows mostly uses 1025 to 5000 (up to server 2k3). 49152 to 65535 is the official range defined by the IANA, but nobody follows this. Only recently IANA standards were applied to windows 2k3+ and freebsd.
+
TCP can use ephemeral ports temporarily. The ephemeral range is somewhat controversial. Most Linux kernels use 32768 to 61000, while windows mostly uses 1025 to 5000 (up to server 2k3). 49152 to 65535 is the official range defined by the IANA, but nobody follows this. Only recently IANA standards were applied to Windows 2003 or higher, and FreeBSD.
  
Now, our attack is between an ircd and a client. We can version the client to get the os he or she is running. If there is no version reply, it would be an easy social to get the information anyway. Let's say our client runs linux. This would be the harder of the two os's. Our port range suddenly shrunk from 65536 ports to 28232 ports. This makes a dramatic difference on the attack time.
+
Now, our attack is between an ircd and a client. We can version the client to get the os he or she is running. If there is no version reply, it would be an easy social to get the information anyway. Let's say our client runs Linux. This would be the harder of the two OSes. Our port range suddenly shrunk from 65536 ports to 28232 ports. This makes a dramatic difference on the attack time.
  
 
28232 is still a lot, but now we can take into account the TCP window. The equation to determine how long it will take to brute the SYN # of the connection between those two parties to disconnect them is found below:
 
28232 is still a lot, but now we can take into account the TCP window. The equation to determine how long it will take to brute the SYN # of the connection between those two parties to disconnect them is found below:
(((( 4,294,967,295 possible syn numbers / # of packets per second to brute it ) / TCP window size ) / 60 ) * # of ports)
+
 
 +
  (((( 4,294,967,295 possible syn numbers / # of packets/sec to brute it ) / TCP window size ) / 60 ) * # of ports)
  
 
There are 2^32 combinations of SYN numbers. Depending on our line, we can send x packets per second in an attempt to brute that SYN number. Now the TCP window is our window in which the SYN can fall between, that means we can 'skip' SYN numbers based on the TCP window, and by default the TCP window is 65535, so we could possibly skip up to 65535 syn numbers at one time to get in the window.
 
There are 2^32 combinations of SYN numbers. Depending on our line, we can send x packets per second in an attempt to brute that SYN number. Now the TCP window is our window in which the SYN can fall between, that means we can 'skip' SYN numbers based on the TCP window, and by default the TCP window is 65535, so we could possibly skip up to 65535 syn numbers at one time to get in the window.
Line 25: Line 27:
  
 
Example:
 
Example:
 +
 
The window size does not have to be exact, if a linux user connected to the IRCD, given a 5mbps line, we can substitute this into the equation:
 
The window size does not have to be exact, if a linux user connected to the IRCD, given a 5mbps line, we can substitute this into the equation:
(((( 4,294,967,295 / 5000000 ) / 14000 ) / 60 ) * 28232)
+
 
 +
  (((( 4,294,967,295 / 5000000 ) / 14000 ) / 60 ) * 28232)
  
 
Given our line, which is 5mbps or only 28.8 minutes to preform a 100% successful blind attack disconnecting both parties with a very small window size. With the default window size, this attack can be completed in milliseconds.
 
Given our line, which is 5mbps or only 28.8 minutes to preform a 100% successful blind attack disconnecting both parties with a very small window size. With the default window size, this attack can be completed in milliseconds.

Latest revision as of 03:41, 19 October 2011

Introduction

This lecture is about TCP RST injection. TCP RST injection involves spoofing a TCP connection in place. TCP forms the backbone of many protocols, such as IRC, but recently its beginning to show its age. Connection speeds are much faster than they were in the 80's.

So basically, you have two parties connected to each other, they do a TCP handshake, and assign a random sequence number between themselves (which has 2^32 possible combinations) as a precaution against spoofing. They also assign the TCP 'window' of the connection, or how far the sequence number embedded in a packet can be from the original sequence number. The larger the window, the more efficient the connection can be. Typical window sizes are from 15000 to 60000. The default is 65535. I've found ircds commonly use ~14000.

The window can be exploited to find the sequence number of a connection, and successfully inject a RST packet. RST packets are special because they can be taken OUT OF ORDER in a TCP stream. Therefore, if you can acquire the sequence number in an active connection, you can inject a RST packet and split the two connected parties. This is actually common knowledge since Paul Watson's paper, 'slipping in the window' [1] was published and it was mentioned at this years blackhat convention.

Today however, we are going to focus on BLIND TCP RST injection. This means, you can disconnect two remote parties. Watson only considered the most ideal situation, which was a MITM attack between two parties to keep them disconnection. Since 2003, the attack is changing. Today, we can blindly spoof a TCP connection and reset most any given connection.

TCP RST Injection

The first challenge we encounter is, we need to know what the connection is between. that is, the destination port and the source port. the destination port is whatever service the client is using. we'll use ircd (6667) for our example. The source port is randomized. There are a total of 65536 given ports. It would take a sort of long time to iterate through all 65535 ports which is why we don't.

TCP can use ephemeral ports temporarily. The ephemeral range is somewhat controversial. Most Linux kernels use 32768 to 61000, while windows mostly uses 1025 to 5000 (up to server 2k3). 49152 to 65535 is the official range defined by the IANA, but nobody follows this. Only recently IANA standards were applied to Windows 2003 or higher, and FreeBSD.

Now, our attack is between an ircd and a client. We can version the client to get the os he or she is running. If there is no version reply, it would be an easy social to get the information anyway. Let's say our client runs Linux. This would be the harder of the two OSes. Our port range suddenly shrunk from 65536 ports to 28232 ports. This makes a dramatic difference on the attack time.

28232 is still a lot, but now we can take into account the TCP window. The equation to determine how long it will take to brute the SYN # of the connection between those two parties to disconnect them is found below:

 (((( 4,294,967,295 possible syn numbers / # of packets/sec to brute it ) / TCP window size ) / 60 ) * # of ports)

There are 2^32 combinations of SYN numbers. Depending on our line, we can send x packets per second in an attempt to brute that SYN number. Now the TCP window is our window in which the SYN can fall between, that means we can 'skip' SYN numbers based on the TCP window, and by default the TCP window is 65535, so we could possibly skip up to 65535 syn numbers at one time to get in the window.

Instead of having to brute 4294967295 syn numbers, accounting for the window, you only need to brute 65537 combinations.

Example:

The window size does not have to be exact, if a linux user connected to the IRCD, given a 5mbps line, we can substitute this into the equation:

 (((( 4,294,967,295 / 5000000 ) / 14000 ) / 60 ) * 28232)

Given our line, which is 5mbps or only 28.8 minutes to preform a 100% successful blind attack disconnecting both parties with a very small window size. With the default window size, this attack can be completed in milliseconds.

Resources

Several C variants of the attack (you may have to modify them to preform blind TCP RST attacks): http://packetstormsecurity.org/search/?q=tcp+reset&s=files Bits per second to packets per second converter : http://www.ccievault.net/index.php/tools