New type of DDoS attack: TCP bug found in Windows
Dear habour-readers, before going to the point I want to immediately say that the author is not any hacker or malicious programmer exploring with every candle every dark corner of a driver or something else software, so if you already know about this vulnerability, Do not judge strictly, but better advise the patch.
So, in the process of debugging the protocol stack for MANET networks, where a modified TCP connection of a radio network to a computer through an Ethernet gateway was tested, it was accidentally revealed that by incorrectly closing the connection by the client on the server side, socket resources could be held indefinitely!
It all started with this:
')
The screen shot shows a TCP connection between a 192.168.0.108 client (Ethernet gateway) and a 192.168.0.187 server (Windows Vista OS).
As you can see, if you incorrectly specify the sequence number in the FIN ACK client, the Windows server did not close the socket and did not release the resources. Attempting to connect again from the same client port (source port 40400) to the server port (destination port 31000) was unsuccessful. The server persistently demanded an ACK in response to a new SYN from the client.
At first, I decided that this was just some kind of bug on the side of the MANET stack (besides, of course, the wrong seqno in FIN ACK), but after analyzing the flow by sequence / acknowledgment numbers and repeating the same experiment for other ports, it turned out that yes, Windows ...
An example of another server port (30000):
Then, rebooting the computer and repeated it again. This time the connection was closed by the client, and the server listened to port 32000.
The result is the same.
Then the netstat command looked at the state of the sockets and was horrified ...
The server keeps open sockets that are not in nature for many hours !!!
And most likely, only forced killing of processes or rebooting will save the situation, since obviously in the FIN_WAIT_2 state, Windows has no timer for the socket and it does not go to the TIME_WAIT state to clear resources.
1. Please urge that this vulnerability be known.
If this is a newly discovered bug, then it threatens many network products on Windows OS.
2. It would be interesting to investigate this problem on other servers and OS, primarily Linux.
3. Learn the network protocols!
PS
a day has passed since the discovery of the problem - the resources have been allocated so far ...
So, in the process of debugging the protocol stack for MANET networks, where a modified TCP connection of a radio network to a computer through an Ethernet gateway was tested, it was accidentally revealed that by incorrectly closing the connection by the client on the server side, socket resources could be held indefinitely!
It all started with this:
')
The screen shot shows a TCP connection between a 192.168.0.108 client (Ethernet gateway) and a 192.168.0.187 server (Windows Vista OS).
As you can see, if you incorrectly specify the sequence number in the FIN ACK client, the Windows server did not close the socket and did not release the resources. Attempting to connect again from the same client port (source port 40400) to the server port (destination port 31000) was unsuccessful. The server persistently demanded an ACK in response to a new SYN from the client.
At first, I decided that this was just some kind of bug on the side of the MANET stack (besides, of course, the wrong seqno in FIN ACK), but after analyzing the flow by sequence / acknowledgment numbers and repeating the same experiment for other ports, it turned out that yes, Windows ...
An example of another server port (30000):
Then, rebooting the computer and repeated it again. This time the connection was closed by the client, and the server listened to port 32000.
The result is the same.
Then the netstat command looked at the state of the sockets and was horrified ...
The server keeps open sockets that are not in nature for many hours !!!
And most likely, only forced killing of processes or rebooting will save the situation, since obviously in the FIN_WAIT_2 state, Windows has no timer for the socket and it does not go to the TIME_WAIT state to clear resources.
Summary
1. Please urge that this vulnerability be known.
If this is a newly discovered bug, then it threatens many network products on Windows OS.
2. It would be interesting to investigate this problem on other servers and OS, primarily Linux.
3. Learn the network protocols!
PS
a day has passed since the discovery of the problem - the resources have been allocated so far ...
Source: https://habr.com/ru/post/198164/
All Articles