The PoC for SockStress, written in C, has NEVER worked for me (that’s not to say it doesn’t work…that’s just to say I suck at C coding). After researching and understanding how this attack works, I decided to write my own in Python.

Script can be found at:

Python SockStress – Github Repo

This attack establishes a bunch of TCP connections with a remote service, and then sends the final ACK packet (from the 3-way handshake) with a zero window value. Because of this value, anything that was going to be sent upon connection, is instead held in a buffer in the memory of the target server. As more connections are established on the server, the memory resources consistently run down until there is nothing left.

To use, find a target with a TCP service that returns data immediately upon connection. Banner grabbing tools can find this quickly.

And prior to running the script, we will look at the baseline for our target’s memory. For this demonstration, I’m using Metasploitable as an attack target.

Then run the script with the following syntax:

./sock_stress.py [ip-address] [target-port] [# of threads]

The onslaught begins.  You can monitor the target to see the impact. First, netstat proves that tons of connections are being established quickly. Each of these connections were established with a final ACK packet that has a null window value, thus resulting in all data that would otherwise be sent upon connection, being retained in memory.

Doesn’t take long (about a minute) before the free memory is depleted to practically NOTHING.

Then (about a minute later), the buffers and cache drop to nil…

Impact to the Server???

This attack, while running, will have various impacts on the server.  It will attempt to save itself by killing the targeted process.  This will result in an extremely unresponsive service.  In this case, the server will kill the vsFTPd process.  In addition to this service being unresponsive, most other services will be similarly unresponsive due to the low level of available memory on the system (my SSH session was practically useless). The below image was from the actual VM itself (rather than the now completely dysfunctional SSH session).