TecHub!

Security researchers Jack C. Louis and Robert E. Lee of Outpost 24 stumbled onto a relatively simple way to implement a Denial of Service (DoS) attack that does not require massive syn floods. The researchers aren’t releasing many details about the attack except for those provided in a very interesting interview with Brenno de Winter. Slashdot has an article “New Denial-of-Service Attack is a Killer“, with links to the mp3 interview. The interview includes several minutes of Dutch in the beginning and the file is quite large. For a slimmer version (converted from stereo and minus the Dutch) of the mp3, and several links that refer to Sockstress please check out the Gibson Research Corporation link, near the bottom of the page.

Controversy as to exact DoS process

There’s precious little to go on as to how the attack works. Fyodor (creator of Nmap and a hero of mine) was willing to offer his opinion of what the DoS process involved:

“The basic idea is to first firewall your source address(es) using a command such as iptables (on Linux) to prevent your own OS from interfering with your attack. Next you create hundreds or thousands of connections to the TCP port you are targeting (such as port 80 of a web server) as follows:

1. Attacker sends a TCP SYN packet to the target port from his own IP address (or one he controls) to request a connection.
2. The target port is open, so it will respond with a SYN/ACK packet-the 2nd step of the TCP 3-way handshake. Remember that Attacker sent the SYN as a raw packet from userland rather than using his operating system’s connect() API to establish the connections. So when Attacker’s operating system’s TCP stack sees the unexpected SYN/ACK come back, it would normally destroy the nascent connection by sending a reset (RST) packet. This is why the special firewall rule was mentioned-to prevent such interference by Attacker’s OS. Instead Attacker’s DoS client handles all these packets by sniffing them from userland (generally using libpcap) and building/sending the raw reply packets.
3. Using the initial sequence number and other information from the SYN/ACK, Attacker sends an acknowledgment packet (the final step of the 3-way handshake) to complete the connection.”

Robert Lee’s reply

Robert Lee was quick to point out on his Blog site that Fyodor isn’t exactly correct:

“In regards to Fyodor’s article: There are some really valid points made; While his article does describe some of how sockstress works and why it is efficient, it does not describe our attacks.

Jack (Robert’s partner) would like to stress that turning off server side SYN-Cookie protection will not help and will only make you open to syn flood attacks again (as stated in Fyodor’s article).

Also, scenarios that lead to systems being resource starved to the point of requiring a reboot is very attack and target specific. It is not as universal as causing a specific service to become unavailable. We have made this clear in all public communications, but it is worth saying again.”

Fyodor has some sage advice

When someone asked Fyodor if he knew whether his bug was the same one found by Louis and Lee, he answered:

“I don’t, since they have refused to release full details. But this sounds like the same fundamental bug. Robert and Jack are smart fellows, so, again, I’m sure that they’ve found ways to extend and improve the attack in certain situations.”

Fyodor further explains:

“My main issue is not with the research, per se, but with trying to hype the weakness in press interviews and the like before they are willing to share details about the claimed weakness. I don’t believe that sharing the details would cause any problems on the Internet, as there are already many simple and effective denial of service attacks against TCP services (including those listed on this page). Many of the same techniques used to defend against all the other TCP DoS attacks will work against these newer ones.”

Possible solutions

Since many of the details are still unknown, experts are advising to treat this as a typical DoS attack and block the responsible IP address. Sockstress apparently isn’t capable of IP spoofing, so blocking the IP address should work. Experts also mention that IDS/IPS software (like IPtables or Snort) should be able to detect the attack vector and prevent malicious TCP/IP connections.

Final thoughts

Between Kaminsky’s bug, the BGP vulnerability, and now DoS attacks aimed at TCP/IP stack flaws, it sure has been interesting lately. Adding to the excitement is the controversy about how Louis and Lee released their findings (prematurely according to some). In their defense, it’s my understanding that Louis and Lee have tried since 2005 and are presently working with the appropriate TCP/IP developers to find a solution.

Once again, it seems like there’s not much we can do, hopefully this will be another example of just knowing about the vulnerability will be helpful. Still we have to wait a few weeks before that can happen as Louis and Lee aren’t talking until T2′08, an international security conference in Helsinki Finland. So until then.
——————————————————————————————————————-

Michael Kassner has been involved with communications for 40 plus years, starting with amateur radio (K0PBX) and now as a network field engineer for Orange Business Services and consultant with MKassner Net. Current certifications include Cisco ESTQ Field Engineer, CWNA, and CWSP.