=-=-=-=-=-=
Sockstress is a user-land TCP socket stress framework that can
complete arbitrary numbers of open sockets without incurring the
typical overhead of tracking state. Once the socket is established,
it is capable of sending TCP attacks that target specific types of
kernel and system resources such as Counters, Timers, and Memory
Pools. Obviously, some of the attacks described here are considered
"well known". However, the full effects of these attacks is less
known. Further, there are more attacks yet to be
discovered/documented. As researchers document ways of depleting
specific resources, attack modules could be added into the sockstress
framework.
The sockstress attack tool consists of two main parts:
1) Fantaip: Fantaip is a "Phantom IP" program that performs ARP for
IP addresses. Fantaip is provided by the unicornscan package.
To use fantaip, type 'fantaip -i interface CIDR',
Ex., 'fantaip -i eth0 192.168.0.128/25'.
This ARP/Layer 2 function could optionally be provided by other means
depending on the requirements of the local network topology. Since
sockstress completes TCP sockets in user-land, it is not advisable
to use sockstress with an IP address configured for use by the kernel,
as the kernel would then RST the sockets. Fantaip is not strictly
required as the use of a firewall to drop incoming packets with rst
flag can be used to achieve the same goal and prevent the kernel from
interfering with the attack vector. However, you may end up DoSing
yourself using the local firewall method.
2) Sockstress: In its most basic use, sockstress simply opens TCP
sockets and sends a specified TCP stress test. It can optionally send
an application specific TCP payload (i.e. 'GET / HTTP/1.0' request).
By default, post attack it ignores subsequent communications on the
established socket. It can optionally ACK probes for active sockets.
The attacks take advantage of the exposed resources the target makes
available post handshake.
The client side cookies, heavily discussed in blogs, news and
discussion lists, is an implementation detail of sockstress, and not
strictly necessary for carrying out these attacks.
=-=-=-=-=-=
The attack scenarios
Every attack in the sockstress framework has some impact on the
system/service it is attacking. However, some attacks are more
effective than others against a specific system/service combination.
=-=-=-=-=-=
Connection flood stress
Sockstress does not have a special attack module for performing a
simple connection flood attack, but any of the attack modules can be
used as such if the -c-1 (max connections unlimited) and -m-1
(max syn unlimited) options are used. This would approximate the
naptha attack by performing a connection flood, exhausting all
available TCB's as described in the CPNI document in section 3.1.1
Example commands:
fantaip -i eth0 192.168.1.128/25 -vvv
sockstress -A -c-1 -d 192.168.1.100 -m-1 -Mz -p22,80 -r300 \
-s192.168.1.128/25 -vv
=-=-=-=-=-=
Zero window connection stress
Create a connection to a listening socket and upon 3 way handshake
(inside last ack) send 0 window.
syn -> (4k window)
<- syn+ack (32k window)
ack -> (0 window)
Now the server will have to "probe" the client until the zero window
opens up. This is the most simple of the attack types to understand.
The result is similar to a connection flood, except that the sockets
remain open potentially indefinitely (when -A/ACK is enabled). This
is described in the CPNI document in section 2.2. A variation here
would be to PSH a client payload (i.e. 'GET / HTTP/1.0') prior to
setting the window to 0. This variation would be similar to what is
described in the CPNI document section 5.1.1. A further variation
would be to occasionally advertise a TCP window larger than 0, then
go back to 0-window.
Good against:
services that have long timeouts Example commands:
fantaip -i eth0 192.168.1.128/25 -vvv
sockstress -A -c-1 -d 192.168.1.100 -m-1 -Mz -p22,80 -r300 \
-s192.168.1.128/25 -vv
=-=-=-=-=-=
Small window stress
Create a connection to a listening socket and upon 3 way handshake
(inside last ack) set window size of 4 bytes, then create an ack/psh
packet with a tcp payload (into a window that is hopefully large
enough to accept it) with a window still set to 4 bytes. This will
potentially cause kernel memory to be consumed as it takes the
response and splits it into tiny 4 byte chunks. This is unlike a
connection flood in that memory is now consumed for every request
made. This has reliably put Linux/Apache and Linux/sendmail systems
into defunct states. It is also effective against other systems.
We expect this has similar effects to what is described in the CPNI
document in the second to last paragraph of page 17.
Look at the payload.c file in the sockstress source. Look for the
hport switch statement. In that section you can specify payloads to
be sent to specific ports. It is most effective to send a payload
that will generate as large of a response as possible
(i.e. 'GET /largefile.zip').
Good against:
services that contain initial connection banners services that accept
an initial request and send a large response (for example a GET
request against a large web page, or file download) Example commands:
fantaip -i eth0 192.168.1.128/25 -vvv
sockstress -A -c-1 -d 192.168.1.100 -m-1 -Mw -p22,80 -r300 \
-s192.168.1.128/25 -vv
=-=-=-=-=-=
Segment hole stress
Create a connection to a listening socket and upon 3 way handshake
(inside last ack) send 4 bytes to the beginning of a window, as
advertised by the remote system. Then send 4 bytes to end of window.
Then 0-window the connection. Depending on the stack, this could cause
the remote system to allocate multiple pages of kernel memory per
connection. This is unlike a connection flood in that memory is now
consumed for every connection made. This attack was originally created
to target Linux. It is also quite effective against windows. This is
the attack we used in our sec-t and T2 demos. We expect this has
similar effects to what is described in the CPNI document in section
5.2.2 5th paragraph and section 5.3.
Good against:
Stacks that allocate multiple pages of kernel memory in response to
this stimulus Example commands:
fantaip -i eth0 192.168.1.128/25 -vvv
sockstress -A -c-1 -d 192.168.1.100 -m-1 -Ms -p22,80 -r300 \
-s192.168.1.128/25 -vv
=-=-=-=-=-=
Req fin pause stress
Create a connection to a listening socket. PSH an application payload
(i.e. 'GET / HTTP/1.0'). FIN the connection and 0-window it. This
attack will have very different results depending on the
stack/application you are targeting. Using this against a Cisco 1700
(IOS) web server, we observed sockets left in FIN_WAIT_1 indefinitely.
After enough of such sockets, the router could no longer communicate
TCP correctly.
Look at the payload.c file in the sockstress source. Look for the
hport switch statement. In that section you can specify payloads to be
sent to specific ports. It is important that you send a payload that
will look like a normal client to the application you are interacting
with. Against our cisco 1700, while using this attack it was important
to attack at a very slow rate.
Example commands:
fantaip -i eth0 192.168.1.128/25 -vvv
sockstress -A -c-1 -d 192.168.1.100 -m-1 -MS -p80 -r10 \
-s192.168.1.128/25 -vv
=-=-=-=-=-=
Activate reno pressure stress
Create a connection to a listening socket. PSH an application payload
(i.e. 'GET / HTTP/1.0'). Triple duplicate ACK.
Look at the payload.c file in the sockstress source. Look for the
hport switch statement. In that section you can specify payloads to
be sent to specific ports. It is important that you send a payload
that will look like a normal client to the application you are
interacting with.
Good against:
Stacks that support this method of activating reno or similar
scheduler functionality Example commands:
fantaip -i eth0 192.168.1.128/25 -vvv
sockstress -A -c-1 -d 192.168.1.100 -m-1 -MR -p22,80 -r300 \
-s192.168.1.128/25 -vv
=-=-=-=-=-=
Other Ideas
fin_wait_2 stress
Create a connection to a listening socket.
PSH an application payload that will likely cause the
application on the other side to close the socket (Target
sends a FIN). ACK the FIN. Good against: Stacks that don't
have a FIN_WAIT_2 timeout. large congestion window stress
shrink path mtu stress
md5 stress
Effects of the attacks
If the attacks are successful in initiating perpetually stalled
connections, the connection table of the server can quickly be filled,
effectively creating a denial of service condition for a specific
service. In many cases we have also seen the attacks consume
significant amounts of event queues and system memory, which
intensifies the effects of the attacks. The result of which has been
systems that no longer have event timers for TCP communication, frozen
systems, and system reboots.
The attacks do not require significant bandwidth.
While it is trivial to get a single service to become unavailable in
a matter of seconds, to make an entire system become defunct can take
many minutes, and in some cases hours. As a general rule, the more
services a system has, the faster it will succumb to the devastating
(broken TCP, system lock, reboot, etc.) effects of the attacks.
Alternatively, attack amplification can be achieved by attacking from
a larger number of IP addresses. We typically attack from a /29
through a /25 in our labs. Attacking from a /32 is typically less
effective at causing the system wide faults.
Exploitation caveats
The attack requires a successful TCP 3 way handshake to effectively
fill the victims connection tables. This limits the attack's
effectiveness as an attacker cannot spoof the client IP address to
avoid traceability.
A sockstress style exploit also needs access to raw sockets on the
attacking machine because the packets must be handled in userspace
rather than with the OS's connect() API. Raw sockets are disabled
on Windows XP SP2 and above, but device drivers are readily available
to put this facility back into Windows. The exploit is able to be
executed as-is on other platforms with raw sockets such as *nix and
requires root (superuser) privileges.
=-=-=-=-=-=
Mitigation
Since an attacker must be able to establish TCP sockets to affect the
target, white-listing access to TCP services on critical systems and
routers is the currently most effective means for mitigation.
Using IPsec is also an effective mitigation.
According to the Cisco Response the current mitigation advice is to
only allow trusted sources to access TCP-based services.
This mitigation is particularly important for critical infrastructure
devices. Red Hat has stated that "Due to upstream's decision not to
release updates, Red Hat do not plan to release updates to resolve
these issues; however, the effects of these attacks can be reduced."
On Linux using iptables with connection tracking and rate limiting
can limit the impact of exploitation significantly.
|
