1. Sockstressby Gregory Hanis
Penetration testing is a field which has experienced rapid growth over the years, and is not going to slow
down any time soon. This subject is certainly not to be entered into lightly by either the organization
sponsoring the test, or the testers themselves. There are many legal issues that need to be dealt with
prior to even starting the test not to mention laying down a groundwork of rules for the test such as
which areas are exposed and what the procedure is comprised of. As a newcomer to penetration testing
you need to understand that vulnerabilities exist in all networks, operating systems, and applications.
New attacks and vulnerabilities appear constantly, and even some old and well known attacks seem to
slip through the defenses of modern networks.
Let’s discuss a vulnerability and attack which was introduced in 2008 by Robert E. Lee and Jack Louis,
called Sockstress. Sockstress has been chosen because it is an outstanding example of a vulnerability
exploitation which is well known and in most cases controlled by intrusion detection/prevention
systems. Even though there are many tools available to detect and thwart this threat it still poses a
danger such as in the astounding Spamhaus attack in March of 2013 (Bowne S. , 2013). Descriptions
used here of the attack are by no means comprehensive, but they will give the new penetration tester a
look at a small part of what goes into identifying and mitigating attacks in general.
Briefly, Sockstress is a denial of service attack which consumes resources of devices that accept TCP
connections. The attack itself uses a “user-land” TCP stack, or TCP stack within the application, rather
than the kernel’s TCP stack. Typically it will open an arbitrary number of connections to a server and
engage in the usual 3-way TCP handshake. Once the connection is established Sockstress targets specific
traits of TCP in order to tax resources on the server such as timers, buffer window sizes, and memory
used in the connection. Windows, Mac, Linux, and BSD are all similarly affected by the attack, with the
common vector being TCP (Gibson &Laporte, 2008).
With Sockstress we have a situation where implementation of the tool is difficult enough so that it is not
favored by most script-kiddies, and moreover it is easy enough to mitigate. Consequently not enough
people are paying attention or protecting themselves from it. Killing a server or denying services is
perhaps not as profitable as other exploits in the cyber-crime world, so for the most part parties with the
criminal capabilities have either not taken much interest or are preparing a large scale implementation
for a later date. If there were a widely distributed tool for carrying out these attacks and the proper
defenses had never been developed, perhaps there would be more cause for concern. Today’s script
kiddies however enjoy working in numbers and they have the ability to make mayhem with tools that
are already available.
The beauty of this attack is that it does not require tremendous resources on the part of the attacker- a
small herd of bots is able to tie up enough resources over time to bring down a server. As each
connection is made server resources are committed to that socket or connection. Each zombie computer
continues to establish connections and subversively chew up resources such as RAM. Rather than
flooding the server this attack allows resource degradation rather than connection volume to bring down
a server. In August of this year, Sam Bowne displayed a great example of Sockstress in action at the
BSides Las Vegas conference (Bowne, S. 2013).

2. Sockstressby Gregory Hanis
It is important to note that this attack can be performed by a single machine, or a small number of
machines. All the attacker needs to supply is different IP addresses in order to mask how many
endpoints are performing the attack. Using a set of zombie computers is a better method of attack
though, because the endpoints can come from different geographic locations. These connections appear
as though they are coming from valid clients to the server, making life difficult for the intrusion detection
systems being used. By no means does that mean there is no defense to the attack. Tools available to
block this attack include those that block IP addresses, or limit how many connections can be made from
a specific IP address.
Cisco suggests mitigation by “allowing only trusted sources to access TCP based services” (Cisco, 2009).
Whitelisting in this way is not feasible with publicly facing servers though. Red Hat recommends “limit
the number of new connections over a time period” (redhat, 2013). Set connection rules to check if
there are more than 10 TCP connections to a port over a given time, suggested at one minute. This gives
a connection rate limit rather than a concurrent connection limit. Red Hat also suggests that once it is
evident that you are under attack block the offensive IP(s). Mitigation will be based on a case by case
basis, but repetitive zero or low value windows set on connections will give a good indication that your
service is at risk (redhat, 2013).
One method of supporting detection of this type of attack is to keep track of connections which are
consistently giving TCP zero window, or low value window returns. The trouble is in false positives. Client
connections may be slow, or routers along the path of the transmission may have full buffers forcing a
real client to invoke TCP's flow control mechanisms, which may make them fit the profile of an attacker.
Connections which have the heuristic or behavioral traits of a Sockstress attack may have to be dropped
forcing the client to reconnect, degrading QoS. Repetitive reconnection attempts from an IP address with
zero or low value windows can be forced to wait for a time between connections, or perhaps even be
blacklisted to prevent further trouble from that IP.
Also, track and monitor system resource usage such as RAM on the server. As the Sockstress clients
connect and tell the server to hold the connection data, the server's RAM usage will gradually start to
ramp up based on how many connections are being made. As the RAM usage increases to a threshold
level, stale connections which are just dithering should be shed reducing resource load. This can still
have a negative impact on QoS. Connections dropped must be algorithmically compared against what is
deemed as a productive connection, hopefully preventing false positives in which too many real clients
lose the service.
After reading this brief description of an attack it should be evident that penetration testing is no
laughing matter. The Spamhaus attack mentioned above has been given light treatment here, but was
actually a remarkably effective attack that had a rippling effect through the Internet which even affected
the London Internet Exchange (LINX) (Dunn, 2013).
Also it is evident that there are many reasons to commit or solicit penetration tests. Having a
penetration test might have found the vulnerabilities at Spamhaus - if it had been discovered. Another
reason to acquire solid pen testing services is to ensure that organizations such as service providers
comply with safeguards imposed by regulatory compliance, contracts, and service level agreements.
These will require various types of insurance that the services provided are secure and interests are

3. Sockstressby Gregory Hanis
protected. Penetration testing provides proof of due diligence on the part of the organization or service
provider, lending more than a modicum of legal protection.
As a field of employment penetration testing is not going to see reductions for its need across all
industries; quite the opposite will surely be true. As new vulnerabilities continue to be found and crafty
thieves create new tools and attacks the need for network hardening is only going to increase and
become more valuable.
References
Bowne, S. (2013, August 5). BSidesLV 2013 cookie reusesambowne. Retrieved from youtube.com:
https://www.youtube.com/watch?v=AJs-_HhOku0
Bowne, S. (2013).Evil Dos attacks and strong defenses. Retrieved from samsclass.info:
http://samsclass.info/seminars/defcon21-cfp.htm
Cisco. (2009, September 9). Cisco response to outpost24 TCP state table manipulation denial of service
vulnerabilities. Retrieved from cisco.com: http://www.cisco.com/en/US/products/csr/cisco-sr20081017-tcp.html
Dunn, J. (2013, September 30). British teen accused of massive spamhausDDoS attack arrested months
ago. Retrieved from techworld.com: http://news.techworld.com/security/3471224/british-teenaccused-of-massive-spamhaus-ddos-attack-arrested-months-ago/
Gibson, S., &Laporte, L. (2008, October 2). Sockstress; security now! episode 164 transcript.Retrieved
from grc.com: https://www.grc.com/sn/sn-164.htm
redhat. (2013, August 05). Does CVE-2008-4609 affect Red Hat Enterprise Linux? Retrieved from
redhat.com: https://access.redhat.com/site/solutions/18729