by Rik Farrow <rik@spirit.com>
In a recent column, I mentioned that some security experts were getting bored at the lack of innovation of exploits. But a new class of exploits has surfaced recently, and is enough to really frighten me. The new exploits also help to explain why anyone would scan and break-into thousands of systems, a seemingly inexplicable behaviour, but not in light of the use of these systems in coordinated attacks.
Network-based denial of service attacks became popular after the SYN floods that took Web servers down in 1996. Winnuke, teardrop, Land, bonk, snork, smurf are but a few of the denial of service attacks that crash systems or clog networks. While these attacks are unpleasant enough, a new dimension has been added in that these attacks can now be launched, simultaneously, from hundreds of remote controlled attack-servers.
Known as distributed denial of service attacks, three tools can be found at download sites: trinoo, Tribe FloodNet (TFN) and tfn2k At the time this article was written, a blending of tfn and trinoo named stacheldraht, appeared with the worst features of both.
In an ordinary network-based denial of service attack, the attacker uses a tool to send packets to the target. These packets are designed to crash or disable the target system, forcing a reboot. Quite often, the source address of these packets is spoofed, making it difficult to locate the real source of the attack. The source address can easily be spoofed, because no reply packets are required from the victim.
In the distributed denial of service attack, there might still be a single attacker. But the effect of the attack has been greatly multiplied by the use of attack servers known as "agents". Called daemons in trinoo (and named ns by default) and servers (named tfn) in TFN, these are the remote controlled agents, and act at the behest of the attacker. To get an idea of the scope of this attack, over one thousand systems were used at different times in a concerted attack on a single server, not only disabling that server but denying access to an entire university network with the equivalent of two T3 connections to the Internet.
The attacker does have some work to do before he or she can launch such an attacker--gain root or Administrator access to as many systems as possible. In the examples seen so far, Solaris and Linux systems have been used as agents. To gain access, scanning tools, like sscan, are used to probe for systems with specific vulnerabilities. With a list of these systems ready, a script is used to break into each of these systems and install the server software.
Dave Dittrich, of the University of Washington, mentions in his description of trinoo, that the remote copy command (rcp) is often used during installation. The installation server will be another compromised system, and the sudden increase in rcp activity can be an indicator that a system has not only been compromised, but is now being used to break-into many more systems.
One trick being used to restart the trinoo daemons is to add
a new entry to the cron file that restarts the daemon every
minute. As the trinoo agent must listen to a specific control
port, 27444/UDP in the default configuration, only one daemon
runs at a time, and each other will exit with an error message
of "bind". In Dittrich's paper, the daemon is named rpc.listen,
and is started with the cron entry:
* * * * * /usr/sbin/rpc.listen > cron
Working as root, you can display root's crontab listing with "crontab -l", and check for an entry like this one.
Once the attack server has been installed and started, it is ready to use. From the attacker's vantage point, the more the merrier.
These denial of service tools take different approaches to remote control. In both cases, the attacker uses a client to send commands that control the agents. The trinoo master, called a handler, listens at port 27665/TCP for connections, and only completes connections after the appropriate password has been provided: betaalmostdone in the default version. Once the attacker has authenticated to the master, he or she can send commands to all agents to launch UDP floods at one or more target systems for periods lasting from one to one or two thousand seconds. The source address of trinoo packets is not spoofed, making finding the daemons easy--except that there will be so many of them.
Trinoo supports other commands as well that can change the size of packets sent, stop an attack, check the status of a daemon, and change the length of the attack. The daemons send responses back to the handler using port 31335/UDP. The daemons also contain a list of the IP addresses of all handlers, and can be commanded to send a HELLO back to all handlers, something that can be done to flush out the handlers (see Dittrich's paper in the Resources).
The original version of TFN did not even use passwords. But it did use a more covert channel than trinoo. Like LOKI, TFN uses ICMP echo replies (the same type of packet used in a PING reply) to communicate between the client and the agents. Different code values designated different commands, for example, 345, start a SYN flood.
TFN supports several different denial of service attacks: SYN floods, UDP floods, ICMP floods, and smurfing. As the TFN server runs as root, the source address may be spoofed, and most likely will be, making attacks harder to trace.
TFN2K appeared in December of 1999, and included strong encryption (CAST-256 algorithm) for the control packets. The method of sending control messages also changed, so that the source address could be spoofed, and different types of packets could be sent. The TFN2K server sniffs the network interface, and checks for data from a client network address that it can decrypt into valid commands. This makes detecting and tracking back the handler (control program) more difficult. No responses are sent back to the handler--the handler must assume that the TFN agent is responding.
TFN2K can run on both UNIX and NT systems. One command supports listening to a TCP port, and running a UNIX shell or cmd.exe as root or Administrator, so the attacker can verify the client is running, as well as updating the client software or executing other commands on the "owned" system. Another command permits the execution of any one line command as root or Administrator. These backdoors alone make TFN2K interesting to an attacker.
Another tool, named stacheldraht (barbed wire in German), combines features of TFN and trinoo. Like TFN, stacheldraht can spoof source addresses. stacheldraht can test to see if RFC2267 filtering is in place by attempting to send a packet with the source address of 3.3.3.3. If this is blocked, source addresses will still be spoofed, but only on the lowest eight bits of the address.
Stacheldraht has a update feature that makes it possible to automatically replace the agents with new versions and start them. Stacheldraht uses encrypted TCP packets (somewhat like trinoo) to communicate between clients (the hacker's interface) and handlers, and encrypted TCP or ICMP packets to talk to agents. The default ports for the client and agents are 16660 and 65000 respectively.
The primary source and targets of distributed denial of service attacks so far have been non-commercial entities. The majority of businesses have firewalls, and that helps to prevent them being selected as sites for distribution of the agents or hosts for agents themselves. Keep in mind that a poorly configured firewall is no better than no firewall at all, so just having a firewall may be no protection.
But once the attack has been launched, it is hard to stop. Packets arriving at your firewall may be blocked there, but they may easily have already overwhelmed the incoming side of your Internet connection. If the source addresses of these denial of service packets has not been spoofed, you can try finding then contacting the responsible parties for what may be hundreds of computers around the world and asking them to stop the agents. If the addresses are spoofed, unless the addresses chosen were RFC 1918 addresses (10/8, 172.16-31/16, and 192.168/24), you will have no way of knowing the addresses do not reflect the true source of the attack until you track some of the alleged sources down.
Please imagine for a minute what it would be like to be an e-commerce site and a victim of hundreds of simultaneous attackers. Are you ready to try to contact hundreds of people, around the world (anyone at your office speak Russian or Tagalog?), even as the attackers switch to another set of agents? Network-based denial of service attacks are the most unstoppable, and the sheer volume of sources to this attack make attempts to stop it mind boggling.
There are things that you can do to help prevent these attacks from occurring in the first place. First and formost, these attacks rely on finding thousands of vulnerable, Internet-connected systems and systematically compromising them using known vulnerabilities. If these systems had been patched (and the patches have existed), the compromise would have been prevented in the first place. John Ladwig, Security Architect, Networking and Telecommunications Services, University of Minnesota made this comment about the attack on an IRC server at the University in August: "it frightened me that someone would "throw away" approximately 2000 compromised hosts, primarily very well-connected [and] fairly powerful ones, presumably to sieze IRC channels." What this implies is that the attackers either have, or presume to have, an "infinite" supply of vulnerable systems, ready to launch future attacks.
If you discover a system that has been compromised, don't simply format the hard drive and re-install. The attacker often leaves traces behind that can lead to other compromised systems. David Brumley, Stanford Computer Security, wrote that "Often we'll find a list of hundreds of compromsed hosts (usually because an intruder is rcp'ing over a rootkit and the rcp's are logged in SYSLOG) on another site that the administrator was ready to just delete!" This is a treasure trove for security people. Don't destroy evidence.
Both tools require lists of agents, and the trinoo agents themselves include an encrypted list of masters. Finding a handler system with a list of agents makes the task of uncovering the agents much simpler--like finding a list of sites where terrorists have placed bombs. Even if you have the inhouse capability to handle an incident of this type, contact your national CERT and send them the files, along with the circumstances under which you discovered the files.
Finally, you can prevent your own networks from being the source of packets with spoofed source addresses. RFC 2267 describes techniques for "ingress filtering", filtering packets at the edge of networks so that only packets with legal source addresses may pass through the routers. Stopping all packets will not prevent these attacks, but will make cleaning up after them MUCH simpler.
Dave Dittrich's analysis of three different distributed denial
of service attacks:
http://staff.washington.edu/dittrich/misc/trinoo.analysis,
tfn.analysis, and stacheldraht.analysis
stacheldraht
CERT advisory 99-17, distributed denial of service tools,
http://www.cert.org/advisories/CA-99-17-denial-of-service-tools.html.
Report from the CERT workshop on these tools in November of 1999: http://www.cert.org/reports/dsit_workshop.pdf
Incident notes relating to denial of service attacks, IN-99-07: http://www.cert.org/incident_notes/IN-99-07.html and techniques used to break-in described in CERT Incident Note http://www.cert.org/incident_notes/IN-99-04.html
Web page with links to tools as well as information about prevent various denial of service attacks: http://www.technotronic.com/denial.html
RFC 2267, Defeating Denial of Service Attacks which employ IP Source Address Spoofing, http://www.landfield.com/rfcs/rfc2267.html.
Figure 1: Here is a rough diagram showing how one or more 'clients', the hacker tool or telnet controling the handlers, which control many agents, which in turn actually send the packets used in DDoS:
+--------+ +--------+
| client | | client |
+--------+ +--------+
| |
. . . --+------+---------------+------+----------------+-- . . .
| | |
| | |
+-----------+ +-----------+ +-----------+
| handler | | handler | | handler |
+-----------+ +-----------+ +-----------+
| | |
| | |
. . . ---+------+-----+------------+---+--------+------------+-+-- . . .
| | | | |
| | | | |
+-------+ +-------+ +-------+ +-------+ +-------+
| agent | | agent | | agent | | agent | | agent |
+-------+ +-------+ +-------+ +-------+ +-------+