CurbRisk.com

Manage Risk With an Effective InfoSec Organization

Outpost24 TCP Denial of Service Vulnerability Interview Transcript

Interviewer: So, that means that basically anyone that owns a computer or a cell phone could do this attack if they understand how.

Outpost24: I wouldn’t say cell phone because a cell phone network is not very good.

Interviewer: No, I mean like an iPhone or any…

Outpost24: Absolutely. Like I said, the whole design of the tool is to use the least amount of resources as possible

Interviewer: How many packets do I need, to start, until another system starts to notice something is wrong? How many packets?

Outpost24: If you just want to take like a web server offline? You can usually do it in seconds — it’s really easy to do.

Interviewer: And then you never recover?

Outpost24: There’s multiple attacks and there’s multiple operating systems and so if you mix and match these things, you can’t always guarantee that something will be permanently offline without knowing which side the other guy is.

Outpost24: To answer your first question, you can get to the point where the service is no longer responsive to new connection attempts with a very low packet per second in a very short time.

Outpost24: We’re talking like ten packets per second can shut down one service; that’s really easy to do.

Interviewer: So, in minutes you can take down an entire data center?

Outpost24: In theory, yeah… We’ve never done that obviously, we’ve done testing …

Interviewer: Thank you, thank you. [laughing]

Outpost24: Well, I mean the scale of our testing is, I mean thus far has really been one versus one, which try and scientifically figure out what impacts the system the most, so how practical it is? Think about all those bot networks out there, that kids use to DDoS things. Now, if those guys were to actually adopt some of these attacks, they may as well as have a DoS network that’s a hundred times bigger because these attacks are, I mean, probably a lot more than a hundred times more effective at DoS’ing people. So yeah, it certainly, certainly would be easy.

Interviewer: I feel kind of reluctant to ask this question, but are there any systems non-vulnerable?

Outpost24: We have not encountered anything that it is not vulnerable yet. Every system that we have tried our attacks against has been vulnerable.

Interviewer: That’s not good news.

Outpost24: No. To further complicate things, we’ve been in contact with the Computer Emergency Response Team out of Finland, who’ve been doing a multi-vendor coordination effort, with a number of vendors… I won’t name names right now, but… as of right now there is no workaround or fix available, either.

Interviewer: Again, stop. There is no workaround or fix?

Outpost24: Correct. Not that we know.

Interviewer: This is why we had to agree to be totally honest to the listener, this is why we had to agree that we wouldn’t share any technical, real technical details on how to do it — yet. But if there is no solution, why do you bring it to the open? Why are we talking about this?

Outpost24: Well, this discovery was initially made in 2005. And back then we had reservations about coming public with this, because there was also no information available on how to solve it. So, the hope is now that, now that we are coming forward and pointing out that there is an issue, we can raise awareness and get more people that are smarter than we are involved in looking at a solution. Just because we can’t think of a solution doesn’t mean there isn’t one. Just means that we haven’t thought of it yet. And we’re also seeing signs that with the option of IP version 6, that these sorts of problems, based on our implementation of the attack, is actually going to be made worse. If someone doesn’t stand up and wave their hand and go "we have an issue here, guys, these things that we’ve been putting online are pretty easy to knock over.” Just because we never talk about that publically, it certainly won’t get any better. I mean we adopt things, like IP version 6, the problem is 3 times worst — at least. And there’s so many new features going in and it just doesn’t seem like people are thinking about what are the impacts of adding all this new neat functionality. Attacks are becoming worse and worse. And so, if we don’t say anything, if we don’t like, raise our hand and try to tell vendors that they have an issue, you know, in five years, when we’re using more complicated stacks that have more code in them, and someone figures this out, then we’re going to be really screwed. So I mean, the solution, of course, is to not, just, you know, wipe it under the rug and just pretend that there is no problem. I mean, it certainly will only get worse from this point forward unless people start thinking about this kind of stuff.

Interviewer: Okay. And how did vendors respond?

Outpost24: [laughs] We’re still waiting for some more positive response. I think that they’re still trying to understand all the different implications for their environments. But, yeah, to be determined. We haven’t had satisfactory response as of yet.

Interviewer: Okay, and you gave me a couple of days of heads up, so I found for instance the FreeBSD SYN cookie brute forcing attack that was dated back in 2003. Isn’t that the same issue? I mean, hasn’t BSD solved this?

Outpost24: Not really, no. Like we were saying before, a lot of people have done client-side SYN cookies in the past, but that is not the attack. The attack is what happens after we complete that three-way handshake. How we complete the three-way handshake is interesting and notable, but that’s not the attack at all.

Interviewer: Okay. Robert, you were aware of my hesitation at first because bringing this out in the open only shows the direction of where to look might bring people to an idea how to recreate this attack, especially if they’ve got your software, which is open source.

Outpost24: You mean the Unicornscan portion?

Interviewer: Yes.

Outpost24: The attacks obviously aren’t open source.

Interviewer: No, no, no. But, you know, they could figure that out. We saw that with Dan Kaminsky happening, so you are taking on a risk.

Outpost24: Well, the thing is, we’re also are taking a risk that some really smart guy is going to tell us there’s some really smart work around for us that we didn’t know. I mean, of course it can go, there could be bad or good things that could come from it. But I think that the only possible outcome I think that by trying to talk to people and point out that there are problems with certain things, especially when we’re not giving out the details, and we’re not telling them, “Hey, do this and that system will fall over.” If we’re not doing that, I think the best thing that will happen is that people will just kind of start to poke around and think, and go “Okay, there are some actual ways to fix this.” And it’s foolish to think that just because we maybe don’t tell someone about how these attacks work, someone else will eventually find out anyway that these attacks do work. We don’t have to tell them. It is a matter of time before someone else finds out.

Outpost24: We certainly don’t have a monopoly on intelligence or bug-finding abilities.

Outpost24: So, it’s not one of those things. I mean, eventually someone would have found a problem in DNS, too. It’s just a matter of time. Maybe someone found it three years ago. We don’t really know. But a coordinated, responsible disclosure in trying to bring awareness that there are security implications that involve TCP I think are only going to be beneficial for everyone on the Internet. I certainly don’t want the Internet to fall over and I certainly want people to take TCP and availability more seriously than they do now. I think what we’re doing is the best thing we can do.

Interviewer: Having said that, then basically still we can draw the inference at this point that TCP as we know it is broken beyond repair, as far as we know.

Outpost24: Certainly the implementations that we’ve played with.

Interviewer: And that’s basically Linux, BSD, Windows, probably all the routers that are out there?

Outpost24: Yeah.

Interviewer: Is there a way to mitigate the risk, for instance by installing a firewall or by using an intrusion prevention system? Or would it make it worse?

Outpost24: What’s interesting about that is especially in the case where this inline device is a final point for lots of systems behind it. Its stack is now having to do the work of all the machines that it’s in front of, and so it will feel the effects of this attack that much faster. So if it’s in front of thirty two systems, I mean it’s almost thirty two times more effective against a firewall.

Interviewer: And why do we say “thirty-two” times more effective? Why this number?

Pages: 1 2 3 4

   

 

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.

Copyright 2008. CurbRisk.com. All rights reserved

• Home
• About
• Contact