-----BEGIN PGP SIGNED MESSAGE----- "Tribe Flood Network 3000": A theoretical review of what exactly Distributed DOS tools are, how they can be used, what more dangerous features can be implemented in the future, and starting points on establishing Network Intrusion Detection Rules for DDOS. Many technically uninformed people consider DDOS as a weapon, that should not be publicly evolved and distributed. This is the only further thing I'll be releasing to explain DDOS tools, comprehensible for EVERYONE, and future features that may be implemented in DDOS: a brief theoretical description. BTW: People with technical knowledge may skip over the most stuff in I. and II. I. What is distributed DOS, what can it be used for, how does it operate? II. What are DDOS features, what are future DDOS features, how is DDOS evolving? III. DDOS, an exploit or not? Should it be published? What is the main problem? IV. How can DDOS traffic be detected by Network Intrusion Detection (NIDS)? I. What is distributed DOS? Distributed DOS, like any distributed concept, will make it easy to coordinate a procedure that is launched from many computers. In this case it is Denial Of Service in form of packet flooding, to overload network links. DDOS IS NOT A HACKING TOOL CATEGORY. Distributed DOS tools are PENETRATION tools. They do not exploit security vulnerabilities, but they can demonstrate what amount of traffic a host can or cannot handle. Distributed DOS has been used a long time by professional security consultants for penetration testing. Before there were DDOS attack tools, there have been commercial, non-open-source programs out that could launch distributed packet floods. Those were used in the information security consulting business, to perform a security service called "Capacity Management". The purpose of Capacity Management is to determine how much traffic a network can handle, to see if the targets bandwidth has to be improved, or if it can handle enough traffic while providing service reliably. What can it be used for? It can overload, or flood if you want, network links. It sends meaningless packets, the overall amount of data being more that the network can process. The impact is that the targets can not be reached over a network. That is all. How does it operate? The basic concept is that you install a huge amount of DOS servers on different hosts. They will await commands from a central client. A central client can then message all the servers, and instruct them to send as many traffic as they can to one target. The tool distributes the work of flooding a target amongst all available DOS servers, therefore it is called a distributed concept. Before these tools were available, an attacker (or penetration tester) would have to telnet into all the hosts that he wanted to use, log in as a user, and manually launch a command to flood a target on each of the hosts that should flood, for example using the UNIX standard tool ping: 'ping -f target' II. What are DDOS features? The actual attack tools don't do simple flooding, but variations of it which involves using actual weaknesses in a protocol to a) make an attack more powerful b) make an attack harder to track back. First, current DDOS tools spoof source addresses. They are sending raw IP packets, and due to the nature of the internet protocol the source addresses can be fake ones, and single (not connection oriented) packets will still reach their destination. This is basically what makes backtracking of the attacks so hard. DDOS is also exploiting protocol weaknesses, it for example can open up half-open TCP connections by SYN flooding. This is a very old and well known protocol vulnerability, and feasible countermeasures are present. To make attacks more powerful, DDOS can generally use any protocol vulnerability that can be exploited by sending single, not connection oriented packet traffic to a host. What are future DDOS features? Things that can still be implemented, but have not in publicized tools, are protocol vulnerabilities as mentioned above. One of those is the "stream" attack (discovered by Tim Yardley, stream.c and spank.c demonstrate the vulnerability and are public). Stream attack sends TCP packets with either ACK or both SYN and ACK flags set. Because they are not part of a connection, they will "confuse" a target machine and take some time to be processed by the operating system. If this attack is used in a distributed way, the attacker can overload machines with less hosts. From what I've heard, distributed stream attack IS already implemented in private DDOS tools. It is very trivial to implement this feature. Possibility 2 that is not implemented yet are multicast addresses. Multicast addresses are routed (forwarded) specially by routers, they can multiply one packet into several ones. The concept would be to send out packets with a multicast (224.x.x.x) source. A target could send an error message back to multicast destinations, and multiply the bandwidth. This concept has also been mentioned by Tim Yardley. Another concept could be to purposefully send special strings in the flood traffic, strings that Intrusion Detection Systems (IDS) could falsely interpret as break-in attempts, the impact would be false alarms and affected IDS could get overloaded or crash. How is DDOS evolving? As I mentioned, the first tools that did distributed denial of service were commercial penetration tools. The origin of using general DOS is certainly IRC (Internet Relay Chat), where kiddies can take over control of channels if they temporarily take out computer systems with DOS. The first packet flooding DOS that involved multiple servers flooding was "smurf". Smurfing relied on mis-configured networks replying back to a broadcast address, sending one packet would result in hundreds bouncing back. Then, most of those networks were fixed, and attackers compromised a lot of hosts, preferrably hosts with high bandwidth, and started flooding manually from them. Because this took a lot of time, attackers wrote servers which they installed on the hosts they had compromised. They no longer needed to log in, but only message those servers. The DDOS attack tools I know of are, in chronological release order: fapi (private, by ?), blitznet (public, by phreeon), trinoo (private, by phifli), TFN (public, by me), stacheldraht (private, by randomizer), shaft (private, by ?), TFN2K (public, by me), Trank (TRinoo + spANK.c?, private). The recent development has also continued in other ways, since people were monitoring traffic for very DDOS-program-specific traffic (like known character strings, known passwords, default ports), there have been many small variations made to the code of the above tools, by attackers, to prevent being detected. III. DDOS, an exploit or not? No. DDOS itself is not an exploit. It just makes an existing concept more easy. Take the distributed.net RC5 challenge and distributed password crackers. They are not exploits. But they are exposing a weakness, that many passwords can be brute forced faster than people think. DDOS shows that many networks are not as strong as they seem to be and can be overloaded faster than people used to think. Additionally, there are actual exploits implemented in DDOS exploits, that exploit security holes in network protocols currently used on the Internet. These security holes must not necessarily be exploited to make DDOS possible, but they do make the impact of DDOS attacks more powerful. Such exploits are the possibility of arbitrarily spoofing IP addresses, SYN flooding, IP stack attacks with bad fragmentation, header offsets and other "magic packets", the stream vulnerability, and missing authentication and security of traffic known as connection-less or stateless. Should it be published? That is for you to decide. It is your personal opinion. But people will continue to publish vulnerabilities. Hundreds of talented security analysts are professionally researching vulnerabilities in software, and posting exploit programs, which can often be used to instantly compromise a system running the vulnerable software at root level. The past has shown, that since security vulnerabilities were a problem on the internet, people have been ignoring advisories containing only the information THAT something was vulnerable to an attack, disregarding them as being "completely theoretic". Only when people wrote up and posted ready-to-(ab)use vulnerability exploits, the severity of vulnerabilities became clear, and people would make an effort to counter those vulnerabilities. What is the main problem? The main problem, that made attacks against sites as big as yahoo.com possible, is the bad overall security on the internet. With ONLY a DDOS tool in his hands, Joe Attacker cannot do anything. But security vulnerabilities are omni-present on the majority of hosts on the net. An awful lot of these hosts are not caring about their security, as a result they are running software that is KNOWN to be vulnerable, and against which public exploit programs exist. An attacker has only to run one of the public exploit programs and he is granted full access to such hosts. And various people have been able to compromise THOUSANDS of hosts with well-known, old vulnerabilities. Even high speed university networks, which originally built the foundation of internet architecture have proven to be insecure. With full control over thousands of hosts, it is easy to concentrate all of these hosts resources, and to be able to attack almost anything on the internet. IV. How can DDOS traffic be detected by Network Intrusion Detection (NIDS)? The mistake everyone has been making is to search for default strings of special DDOS tools, for default values, ports, passwords, etc. To establish Network Intrusion Detection capability in order to spot these tools, that operate via connectionless raw packets, people will have to start looking for general signs of DDOS traffic, signs that are obvious and traffic that is extensively anomalous and suspicious. There are two kinds of DDOS-generated traffic, control traffic (between DDOS client and servers) and flood traffic (between DDOS servers and DDOS victim). Credits to rain forest puppy, Dave Dittrich, and Axent Security Team for providing some initial hints I needed to write this up. Anomaly 0: This is not real "DDOS" traffic, but it can be a viable method of determining the origin of DDOS attacks. As observed by RFP, an attacker will have to resolve his victim's hostname before a DDOS attack. BIND name servers are capable of recording these requests. You can either send them a WINCH signal with 'kill', or you can specify query logging in the BIND configuration. A single PTR type query before an attack indicates the request was made from the attackers host, a great load of PTR type query for a DDOS victim before an attack indicates that the flood servers have been fed a host name and each server was resolving the hostname for itself. Anomaly 1: Amount of bandwidth exceeds a maximum threshold that is expected normal traffic for a site could cause. Alternatively, the threshold can be measures in the amount of different source addresses in the traffic. These are clear signs of flood traffic and ACL rules can be implemented on the backbone routers that detect these signs and filter traffic. Anomaly 2: Oversized ICMP and UDP packets. Stateful UDP sessions are normally using small UDP packets, having a payload of not more than 10 bytes. Normal ICMP messages don't exceed 64 to 128 bytes. Packets that are reasonably bigger are suspicious of containing control traffic, mostly the encrypted target(s) and other options for the DDOS server. Once (non-decoy) control traffic is spotted, one of the DDOS servers' location is revealed, as the destination IP address is not spoofed in control traffic. Anomaly 3: TCP packets (and UDP packets) that are not part of a connection. The stealthiest DDOS tools use random protocols, including connection-oriented protocols, to send data over non-connection-oriented channels. Using stateful firewalls or link-state routing can discover these packets. Additionally, packets that indicate connection requests with destination ports above 1024, with which no known service is registered and running, are highly suspicious. Anomaly 4: Packet payload contains ONLY alphanumeric character (e.g. no spaces, punctuation, control characters). This can be a sign that the packet payload is BASE64-encoded, and therefore contains only base64 characters. TFN2K is sending such packets in its control traffic. A TFN2K (and TFN2K derivatives) specific pattern is a string of repeating A's (AAAA...) in the payload, since the buffer size is padded by the encryption routine. If the BASE64 encoding is not used, and the payload contains binary encrypted traffic, the A's will be trailing binary \0's. Anomaly 5: Packet payload contains ONLY binary, high-bit characters. While this can be a binary file transfer (traffic transmitted over ports 20, 21, 80, etc. must be excluded if this rule is applied), especially if contained in packets that are not part of valid stateful traffic, it is suspicious of being non-base64 encoded, but encrypted control traffic that is being transmitted in the packet payload. - Mixter -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1 iQEVAwUBOKdHVrdkBvUb0vPhAQGy2wf/XQ8d2VXKESzjyFzIqfRPd9S1RKXQZzGo 6yWnUADt3CuZRDmgJb9UYHJ/1Wf/J1V0PWik7GIJLD5zOXgUbgfdhYSOqJsPe14B K3HaqraRFyMHXjb8A4TBC0RTEX3kepWFrMNePOge9rLPD8rwfhWdIrnJuyHmmNiS rqVztFrPwfQl8FId5jjDjzXWlb5UuHgEpm1fNhrnjMh5XwFvVHN4MlJuuuk3ps9f BVpBFJbSqmdb5GHTXCrw4tHHUHtpE7Iu586A6ODCERT1oM7i2SEroZ2x2xO2ssOx cnyW3xFYcCNrJeJEzI9z+/VziYb1VqDl52MR7O1MSn/3SrAlVMvk2Q== =GKzb -----END PGP SIGNATURE-----