262 lines
11 KiB
Plaintext
262 lines
11 KiB
Plaintext
=-=-=-=-=-=
|
|
|
|
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.
|