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).

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

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-sr-

20081017-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-teen-

accused-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