Outpost24 TCP Denial of Service Vulnerability Interview Transcript
The following text is the complete transcript of an interview of Robert Lee and Jack Louis from Outpost24. Robert and Jack discuss their discovery of a flaw in TCP that results in a denial of service with Brenno de Winter of De Beveiligingsupdate. The article (in Dutch) can be found here, and the full MP3 audio is at this link (note that the beginning of the podcast is in Dutch. Forward about 5 minutes to get to the English portion, including the interview with Robert and Jack.
I heard from Robert E. Lee via email earlier today, and he has indicated that he’d like to make some corrections to the comments that are shown below. I’ll be speaking with him soon, and will update this page with his comments. I’m in the process of transcribing another podcast which will be posted soon, and will also have an article here on CurbRisk with some suggestions for what enterprises should (and should not) be doing in response to the news reports of these vulnerabilities. Be sure to subscribe to the RSS feed, or subscribe via email to stay up to date. Links to both are on the top right side of this page.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Interviewer: Robert Lee and Jack Louis, you’re both of Outpost24. And using basically, your Unicorn scanner you did some amazing discovery. First off, what is Unicorn and what are we talking about?
Outpost24: Okay, well Unicornscan was a, an attempt to make a userland TCP stack. We were originally using it to collect information from large networks that we were being paid to do penetration testing against. I’ll let Jack briefly explain how that works. I, I guess we were doing the tests and we just couldn’t get the port scanning done in time. And so we decided to move the TCP stack into the program, so we could make it distributed. And one of the problems you run into when you make a distributed stack is that the state of the stack has to be, I guess you could say it has to be contained in some sort of way, to where each machine doesn’t have to track all the TCP connections. Which is why we kinda had to take a strange approach by using the reverse SYN cookies or whatever you want so we could do the three-way handshake part without necessarily tracking the connection each step of the way. And so that’s basically why or how we started noticing some funny things while scanning various networks. One other thing, too, that was important was Unicornscan was a really fast port scanner too. Which, of course, it would lead you to sometimes accidentally hit, like, network windows where the connectivity was bad, and so you would experience packet loss. And we didn’t really have much code for determining if packet loss was happening. And, so we, in the beginning at least, we would hit periods where we would just experience packet loss.
Interviewer: Wait, so packet loss basically then you mean that the system runs into problems?
Outpost24: Yes, and so we were noticing that certain stacks, and I think we were mainly seeing it with routers, would randomly end up in strange states on the other side when there was packet loss. And I guess that’s basically how we discovered it. Because a lot of these stacks, we would hit certain states inside of their TCP where they basically would just never give up trying to talk back to us. It would retransmit certain packets over and over and over again until the device was actually rebooted. You know, we didn’t right away go into, I mean we thought it was strange, you know, so we took note of it. But we didn’t really look that much into it at first. Until, I think a little bit later on when we were just curious about what, what we were actually doing to get these routers to never give up on trying to retransmit to us. I guess, kind of as a joke the first couple things that I tried, we made a program called Sockstress, Which basically was very similar to Unicornscan, but instead of establishing or trying to do the right thing while establishing the TCP connection, it intentionally did some very evil things during the negotiation of the handshake. And that’s basically what we came up with our first version of Sockstress that had two attacks in it. And I guess we were both surprised about how effective it was at first. I don’t think either of us really had any idea that it would work so well. Looking back on it, Jack before he wrote the first attack, said "Wouldn’t it be funny if this worked?", just said it kind of jokingly and then he actually did it and it, yeah it was very effective. Yeah, it worked really well so. I guess…
Interviewer: Okay, now you need to explain what worked really well, because I understand what you do is something with TCP/IP handshake. And specifically the part that has been added because there is something called like a denial of service SYN flood attack.
Outpost24: Yeah, this is definitely not a SYN flood
Interviewer: No, no, no, no. But you, you are messing with the part, what I understood, that has been added because there is something like a SYN flood attack.
Outpost24: Yeah, let’s, let’s take it back a step then. So back in 1985, there was a research paper written by Morris that talked about how you could spoof a connection attempt from a trusted host. And, you know, most people remembered the paper for that, that side of it. But one of the interesting elements of the spoof detective he describes, is finding a working service on the host that you want to spoof, and SYN flooding it to make it so that when you do send the SYN packet spoofed from its IP address and the SYN-ACK comes back to it, it doesn’t reset the connection for you. So that was back in ‘85 that we knew about SYN-flooding which basically is the idea, or premise, that a system with a listening TCP service has only a finite amount of resources. Let’s say hypothetically, that the system can only accept 1000 concurrent connections from different clients that are out there. The way a SYN attack works, a SYN flooding attack, is the attacker simply sends enough SYN packets to take up all those slots, or all those resources on the server side to make it so that no legitimate connection attempt has a chance to, to actually complete the connection. So in 1996, a number of different programs and articles were written about the SYN-flood attacks, this had become very popular. At the tail end of ‘96, researcher Bernstein came up with the concept of SYN cookies. And what SYN cookies basically does is that it off-loads, it basically makes it so that instead of taking up all those resources at the time that the initial synchronous packet is received, it can take all the session details through the meta data for that session connection attempt and put that into a hash table and take a look at the entry at the hash table and use that as a sequence number for its response to the synchronization attempt. And that way, the attacker now has to acknowledge this special token, this sequence number, in a valid format in order to complete the 3-way handshake. And so this basically makes it so two things happen. Number one, the attacker now has to actually receive the response packet to his SYN and he also can no longer be doing this from a spoofed location because the response packets have to be at a network that’s accessible to him. So now we are caught up to 1996. What happened shortly after that, from our research as soon as 1999, maybe even sooner by other researchers who didn’t really publish their works, but some researchers figured out that you could, in a client program, implement your own idea of client site SYN cookies. Where basically you encode something that’s your initial sequence number so that when the server responds to you, you can quickly tell if it’s a response to something that you generated. Ok, so I’ll go let Jack take over again.
If you enjoyed this post, please consider leaving a comment or subscribing to our RSS feed to get future articles delivered to your feed reader. You can also click "Buzz Up" or "ShareThis" above to share this post via email or social networking sites.
Comments
[...] that was partially disclosed last week. I previously posted a transcript of an earlier podcast discussing the TCP Denial of Service vulnerability, and was asked to make a transcript of this more recent discussion [...]
[...] A full transcript is available from CurbRisk.com : Outpost24’s TCP - Denial Of Service vulnerability interview transcript [...]
[...] TCP Denial of Service vulnerability that was recently partially disclosed by Outpost24 has left many InfoSec managers wondering whether any action is required to protect their [...]
I think the fundamental problem with the interview was down to the interviewers miss-understanding of where the weakness was.
He seemed to be stuck on the syn packet dos attacks made public in the past…
====
Interviewer: No, no, no, no. But you, you are messing with the part, what I understood, that has been added because there is something like a SYN flood attack.
====
A syn verification / acknowledgment cycle THEN a no buffer response is where the problem lies.
Resources are allocated to the TCP process as no buffer is forced from the attacker…. This is where the major problems can come from!
I have written up a short post covering the flaws here:
http://www.abeontech.com/security/147/sockstress-tcp-ip-vulnerability.html