Welcome to Volume 2, Issue 6 of The Internet Security Conference Newsletter, Insight. Insight provides commentaries and educational columns, authored by some of the best minds in the security community.
The editorial calendar at this time includes:
For previous Insights issues, click here.
TISC is about sharing clue. So is the newsletter. We promise to provide some- thing useful each issue. If we don't, flame me.
In this issue, Rik Farrow, noted Internet Security expert and my colleague on the WatchGuard LiveSecurity Advisory Council, discusses Distributed Denial of Service Attacks. This article was originally broadcast to WatchGuard LiveSecurity subscribers shortly after the attacks made the news. Rik's insights complement Kurt Seifried's column published in Volume 2, Issue 3. Thanks to WatchGuard for permission to redistribute this article.
As our feature column Todd Glassey of Certified Time lays out requirements for a uniform, strong evidentiary model for digital transactions, and the need for a secured time source.
Enjoy, and be safe,
Denial of service attacks do not involve breaking into a system, but rather are aimed at making that system or network unusable. Denial of service attacks can be local or network-based, and have always been difficult to defend against. The recent spate of denial of service attacks that blocked network access to prominent e-commerce sites (such as Amazon, CNN, E*Trade, Yahoo, eBay and others) involved hundreds of attacking systems.
A firewall can't prevent or neutralize all of these attacks: Some of these attacks are outside the firewall and they are all difficult to distinguish from normal traffic. A firewall can, however, prevent you from becoming an attack source. It can also prevent the invasion from harming your protected network.
Denial of service (DoS) attacks are not new. A denial of service attack involves software that deliberately (rather than accidentally) crashes a system, or makes a system or network unusable. An example of a denial of service attack is WinNuke, a program that can crash un-patched Windows 95 systems that are connected to networks. In April of 1999, WinNuke was used to crash 6000 Windows systems during a single attack.
During the week of February 7, 2000, people became aware of distributed denial of service (DDoS) attacks after many prominent e-commerce sites were targeted. The effects of these attacks were to make sites such as yahoo.com or eBay.com inaccessible to normal business for the duration of the attack. The attack does not involve breaking into any of the targeted servers; rather, it floods them with nonsense requests and errors from Internet. It is the flood, the immense volume of data, that chokes the network and servers. Stopping this flood of data is not easy.
Distributed denial of service attacks can be considered to be cyber vandalism, as nothing is stolen except network bandwidth. But these attacks are significant, as they rest upon weaknesses in the design of the Internet and TCP/IP, the set of rules (protocols) for exchanging data over the Internet. Also, attackers using distributed denial of service must break into hundreds of systems in preparation for launching their attacks. As a result, the number of victims in these attacks goes far beyond the well-known targets.
Distributed denial of service attacks are particularly disturbing for both law enforcement and security experts, as these devastating attacks can be very difficult to trace back to their sources. Hundreds of computers can be involved in a single attack; several of the attack tools hide the source of the attack, and disguise themselves on the computers where they are installed.
If you are the target of a distributed denial of service attack, there is little you can do. You can work with your ISP to attempt to block the packets used in the attack. If the attack is coming from a specific network, your ISP could be asked to block traffic from that network for the duration of the attack. But most of the attack tools include built-in timers that stop the attack after a period that ranges from minutes to hours; so the attack might stop even before you can block it.
It is also possible that you may be one of the sources of a distributed denial of service attack. You can avoid being an unwitting accomplice by using a carefully configured firewall, disabling unnecessary network services on public servers, and installing security patches on your servers and other systems. You can use commercial software products, such as SAFEsuite from ISS, to detect floods on your networks, or to scan your networks for the presence of the attack tools. You can also use free software that scans for these tools.
"Denial of Service" is a generic term for a type of attack, which can take many forms. The Melissa virus, for example, became a denial of service attack because it clogged networks and servers with the e-mail it generated. Viruses can become denial of service attacks when the payload they carry re-formats your hard drive or deletes essential files.
Denial of service tools are not hard to find. The hacker community has a long tradition of sharing tools, and there are many Web sites that archive these tools. The Technotronic Web site maintains a particularly extensive list of hacking software, and the Resources section includes links to Web pages listing various denial of service attacks.
Network-based denial of service attacks do not require that you execute the attack on your own system. All that is required is that your system be attached to a network. During 1997, a network-based denial of service attack designed to block access to Web servers became popular. This particular attack, known as a SYN flood, is one component of distributed denial of service attacks today.
The SYN flood takes its name from packets of data used to set up Internet connections, such as those used by Web and other servers. The TCP/IP protocols define an exchange of three packets to set up a connection, and the first of these three packets is marked SYN, for synchronize. In normal use, the server sends an acknowledgement to the client that is requesting the connection, and the client then responds with its own acknowledgement. When these three packets have been exchanged, both the client and the server have an established connection.
In a SYN flood attack, the attack tool sends a flood of traffic over the Internet consisting only of the first of the three setup packets. Not only does the tool send this flood, but the tool also lies about the source of the packets. When you use TCP/IP, the packets sent by your system always include the return address, called the source address, so that answers can be returned to your system. But in the SYN flood (as well as other denial of service tools), the source address is spoofed, that is, replaced with an address other than the real source. Denial of service tools can do this because these attacks do not rely on getting a response back. In fact, the SYN flood only works properly if the source address is spoofed.
During a SYN flood attack, the target server attempts to complete the connection by sending acknowledgements to the spoofed source address. Often, there is no system associated with the spoofed source address at all, so there will either be no response, or an error response (an ICMP packet, which will be described later) will be generated. The TCP/IP stack is designed to wait for a valid acknowledgement but will never receive one during this attack. Meanwhile, the TCP/IP stack has to keep track of all the invalid connection attempts, and will begin ignoring valid requests.
In 1997, the SYN flood worked very well, especially as the UNIX and NT servers of that time had connection queues less than ten deep. An attacker using a modem would have no problem filling a connection queue by sending several packets per second. Because the attacker's tool spoofed the source address, tracking the attack source was very difficult, requiring ISPs to use low level packet analysis tools known as sniffers to identify and track the offending packets on their networks.
Server vendors responded to this attack by making the server's connection queue longer, and by shortening the timeout (so that the queue could empty faster if it was full of invalid requests). Intrusion detection vendors added features to their products to detect SYN floods, and to send packets to clear the server's queue of the spoofed packets. Firewall vendors added features to detect the floods as well, so the firewall could dynamically block packets that came from a consistent spoofed source address.
The Internet Engineering Task Force (IETF) responded to SYN Floods by publishing a paper, known as an RFC. RFC 2267 suggests that all networks prevent packets with spoofed source addresses from either entering (for ISPs) or leaving their networks. Firewalls, such as WatchGuard's Firebox, do this by default. If all networks prevented packets with spoofed source addresses from ever entering the Internet, many denial of service attacks would not work, and others would be easier to track back to their sources.
While the SYN flood can work with a relative trickle of packets, there are other denial of service attacks that involve a torrent of packets. These attacks rely on overwhelming either the target system or the network leading to that system. In comparison with more recent generation DoS attacks, a SYN "flood" seems more like heavy rainfall than flood.
There are two types of packets best suited to flooding, ICMP and UDP. ICMP packets contain error messages, and are used by TCP/IP stacks to signal each other. ICMP stands for Internet Control Message Protocol, and is an important part of the correct functioning of the Internet. While you can block all ICMP packets with a firewall, your network performance will suffer. An example of this is if your browser hangs when you attempt to reach a Web site. Eventually, you will see a message that the server is not responding, try again later. You will see this message sooner if ICMP packets are permitted to reach your system. ICMP packets are also used with PING, the tool used to determine if a remote system is reachable. PING sends out an ICMP packet called an ECHO REQUEST to the remote system, and will receive an ICMP ECHO REPLY packet if the remote system is up, and reachable.
Yet there is a downside to ICMP, as it can also be used as part of a well-conceived network attack. For this reason, many firewalls block incoming ICMP ECHO REQUESTs. These packets can be used for scanning networks. Non-standard ICMP ECHO REQUEST packets were also used in the Ping of Death denial of service attack that crashed Windows, NT, and some UNIX systems. Patches against this attack have been available for several years.
PING can be used for flooding by starting up multiple copies of the program on a well-connected server and using a command option to pad each packet with many kilobytes of extra data. By sending enough data, the attacker hopes to overwhelm the network connection of the target, so that no useful traffic can get through.
More recent tools of this type magnify such attacks. Denial of service tools known as Smurf and Axcast use a trick to multiply the effect of their attack. In the Smurf attack, instead of sending the flood directly to the victim, an intermediate network of systems is abused first. ICMP ECHO REQUEST packets are sent to the broadcast address of a network, and every system on that network sends an ECHO RESPONSE to the victim. The attacker includes the victim's address as the (spoofed) source address of the attack. Every packet the attacker sends results in a packet from every system on the intermediate network directed at the victim. In technical terms, this attack relies on the use of directed broadcasts, something which your firewall or router can easily block.
UDP packets are also useful for flooding. Web servers, email, FTP, and telnet all use TCP packets because of the connection establishment (described earlier), and reliability features of TCP. Some services do not need to set up a connection, and use UDP instead. UDP services, like DNS or RalAudio, send out a request and get one or more packets in response. Ignoring connection establishment and the reliability of features of TCP, UDP services are optimized for speed.
Tools have existed for many years for generating floods of UDP packets. Sun Microsystems included such a tool (sprayd) with their operating systems during the eighties, as these tools could be used to generate traffic for testing networks. Hacker's tools like "pepsi" can send a flood of UDP packets to any application, while "coke" sends UDP packets only to a WINS server.
Both ICMP and UDP packets are used in distributed denial of service attacks. The source addresses of the UDP packets are not always spoofed, making these floods easier to trace to their source.
You should be aware that in source address spoofing, if an attacker is spoofing one of your source addresses, you will often receive packets from the victim's site. The source addresses of these error packets will not be spoofed. Many of these attacks elicit either ICMP packets (attempting to communicate "errors" generated by the attack) or TCP packets marked with RESET. Sometimes you will get so many of these packets that it will appear that you are under attack. And, in a way, you will be under attack, but only as an incidental victim. If you continue to receive these packets, consider contacting the source, as they might not be aware of the attack.
There are four known versions of distributed denial of service attack tools: Trinoo (or trin00), TFN, TFN2K, and Stacheldraht. The source code to these tools is easy to find on the Internet (see Resources), and you can download and examine any or all of these tools. Hackers, of course, also have access to this same source code, and can use it to create hybrids or modified versions of these tools.
The distributed denial of service attack tools share some characteristics, and it makes sense to understand how these tools work. The terminology used here is the same as suggested during the CERT workshop on distributed denial of service attacks. Note that some vendors use names taken from the tools themselves, which is definitely confusing. For their part, Hackers are not well known for their ability to produce coherent or consistent documentation.
In general, the tools work like this: The attacker uses either telnet or a special client to connect to a master server. The attacker then sends commands to the master, which relays the commands to daemons, or zombies. These systems are compromised ahead of time and have the daemon software loaded and running before the attack begins. Depending on the command, the daemons may then flood a particular target. The number of daemons controlled by a master depends on the configuration. Other master commands control which IP addresses are targeted, the size of flood packets, types of packets sent, duration of attack, and sometimes, the ability to execute commands.
One of the most important aspects of these attacks is that a single attacker can, through the master, control hundreds of daemons. Each daemon can then send a flood of packets at one or more victims. Most of these tools support source address spoofing, so that the victim is flooded with packets that do not bear the real source address, making them difficult to trace. The flood itself, of course, has left the victim unable to use their Internet connection. A single command from an attacker can result in gigabits in attack data every second, a multiplication factor not seen in any other form of denial of service attack.
The first well-known distributed denial of service occurred in August of 1999: The Trinoo attack tool was used to flood an Internet Relay Chat server at the University of Minnesota. This attack went on for two days, with thousands of systems running agents used in the attack. At one point, there were 214 systems simultaneously flooding a single server at the University. Malicious packets were traced back to their sources, aided by the fact that the Trinoo tool does not spoof source addresses. Security managers and system administrators at the University worked at contacting the owners of the systems running the daemons.
As quickly as the defenders could find the daemons, the attackers would bring more daemons online. Disabling the daemons is initially as simple as disconnecting the network connection. But then each system must be cleaned up, removing all traces of the daemons, any supporting software, and the vulnerability on the system patched so it cannot be abused again. The attackers often used rootkits, tools designed to hide traces of an attacker's presence and provide backdoors to make it easy to break back into the system again (see Resources).
David Dittrich of the University of Washington has written several thorough (although technical) analyses of Trinoo, TFN, and Stacheldraht. Other analysts have published analyses of TFN2K, a more recent variant of TFN. Dittrich's experience comes from being a system administrator at the University of Washington, one of the sites where daemons were installed and used in the University of Minnesota attack. According to information provided by Dittrich, as well as information provided by David Brumley, a security administrator who works at Stanford University in California, these attacks begin with finding and exploiting vulnerable systems.
The first phases of a distributed denial of service attack involves finding as many vulnerable systems as possible to host the daemons. The attacker uses a tool, such as sscan, to search thousands of Internet addresses, gathering information on a short list of vulnerabilities. The scanner is run from a system that the attacker has already compromised, so that if the scan is discovered, the attacker's identity will still be unknown.
Once the attacker has a list of vulnerable systems ready, he or she moves to another compromised system. This system hosts an automated attack script that runs through the list of vulnerable systems. For each system in the list, the script runs an exploit setting up a backdoor on the vulnerable system, uploads the daemon program, installs the daemon and starts it.
The attacker now moves to yet another compromised system, and installs the master. The master is provided with the list of systems where the daemons have been installed, so that it knows which IP addresses to communicate with.
In the attacks to date, mainly Solaris and Linux systems have been used as masters and daemons. The TFN2K distributed denial of service attack tool also supports NT 4, but there have yet to be reports of NT 4 being used as either a master or a daemon host.
Any network with a properly configured firewall easily blocks the first stage in this sequence. Firewalls should prevent network scans from succeeding. The WatchGuard Firebox will detect network scans, and automatically block a site from which a scan is detected. Also, you can configure the monitoring system to notify you whenever a system has been site blocked, thus putting you on the alert for malicious activity.
The four known tools do not all work exactly the same. They differ in the ability to spoof source addresses, commands used, types of attacks used, communication techniques, and the presence of backdoors or self-upgrade capability.
Trinoo is the simplest and most "benign" of these tools. Trinoo daemons have only one attack, sending floods of UDP packets to the victim. The source addresses of these packets are not spoofed, so the attack source(s) is easy to determine.
The attacker uses telnet to connect to the master, and must enter a password before the master can be used (similar to a login). The master and daemons communicate using UDP packets, and the commands in these packets are not encrypted. Even though Trinoo is simpler than the other tools, this was the tool used to flood the University of Minnesota's network for two days. That network has two OC3's for connecting to the Internet (approximate capacity of 90 megabits per second). Simplicity, in this case, is no indication of a lack of capability to do damage.
TFN, or Tribe Flood Network, was actually written before Trinoo. The confessed author of TFN and TFN2K is Mixter, a well-known German hacker. TFN daemons can generate a variety of floods: ICMP flood, SYN flood, UDP flood, and Smurf style attacks. The tool also includes a backdoor that provides root (administrator) access to the daemonís host system.
The attacker can use several means of communicating with the master program, depending on installation. No password is required, but the attacker must have the list of daemons on hand if the master is to be used successfully.
The master communicates with daemons using ICMP ECHO REPLY packets. This unusual mechanism was designed to make master-daemon communication more difficult to detect. Also, many firewalls (excepting WatchGuardís Firebox) will block incoming ICMP ECHO REQUESTs, but not the replies, which are assumed (incorrectly, in this case) to be the result of legitimate requests. The commands themselves are based on numeric codes, and are not encrypted.
Mixter published an updated version of his program in late 1999, named TFN2K. The updated version adds encryption to the communication link, as well as one way spoofed communication to the daemons. Instead of communicating directly with the daemons, commands are sent to the network in which the daemon is running; and the daemon sniffs the commands from the network. No responses are sent back to the master, so each command is sent twenty times, to be certain that the daemons have received the commands. Both TFN and TFN2K include back-doors for root access and command execution on the compromised servers.
Stacheldraht, German for barbed wire, represents a hybrid of Trinoo and TFN. Like TFN, Stacheldraht supports ICMP flood, SYN flood, UDP flood, and Smurf style attacks. Unlike TFN, it uses an encrypted link for sending commands (TFN2K was rewritten to do this). Stacheldraht also has a built-in mechanism for self-updates: The master can send a command that causes the daemon to download, install, and execute an updated version of itself.
Determining that you are the target of a distributed denial of service attack will be relatively simple: The systems under attack will stop responding to network requests. Determining the type of attack will be more difficult.
Trinoo is the only tool that uses exclusively UDP packets and does not spoof source addresses. Any of the other tools can also send UDP floods, and if hundreds of daemons are in use, it will be difficult to tell if you are seeing the same set of source addresses.
Most likely, only prominent Internet sites will be the victims of these attacks. Considering the amount of effort required to set up one of these attacks locating hundreds of vulnerable systems, breaking into those systems, then installing the software only a few groups of hackers can or would want to do this. Given the effort and level of sophistication involved, these hackers will generally choose high-profile targets.
The majority of victims in these attacks most of us have systems that might be used as daemon hosts or masters. If you are using a well-configured firewall, it is less likely that you will become a secondary victim.
A well-configured firewall detects and blocks IP address and port scans. It blocks by default all dangerous or unnecessary ICMP packets, and only permits UDP packets into a network that correspond to UDP requests sent out of the network. Your Web server is located on the third (optional) interface, as is any other public server. Direct connections to systems on the internal network are extremely limited, if allowed at all; for example, only your DNS and e-mail server allow connections where these are not placed on the third (optional) interface. Where direct connections to internal systems are permitted, these use VPN software.
You can scan your own networks for daemons either by using commercial software, or free software. Vendors of commercial network scanners, such as ISS, have announced patches for their scanners that may detect Trinoo, TFN, and Stacheldraht. The Resources section lists two free scanners that search networks or individual systems for daemons as well. The dds tool listed below is a UNIX program that can also be used, but requires UNIX C programming skills to build. Dittrich's three papers include Perl scripts that will run on UNIX or NT, and detect daemons running in a network.
While you might consider yourself safe today if you have no UNIX systems, remember that converting these tools to NT has already been done in one case (TFN2K), and methods for installing these tools remotely on NT systems exist as well.
Distributed denial of service attacks represent an escalation in denial of service attacks. The flood of packets generated by these attacks is overwhelming, even to sites with a large capacity connection. Sites where the daemons have been installed make up the majority of a distributed denial of service attackís victims, but the most effected are the prominent victims, like eBay and Yahoo! that are the ultimate targets of these attacks.
Avoid involvement in an attack by using a properly configured firewall, and installing applicable software patches on all of your systems. If you are the target of a distributed denial of service attack, contact your ISP for assistance in blocking the attack and tracing it back to the daemon hosts. If you find attack software on any of your systems, do not simply delete it; send it to an organization like CERT, which acts as a clearinghouse for attacks. The software you send may contain lists of other compromised sites; this information can be used to find and remove other daemons or masters.
The digitization of the human race is inevitable. To survive it, we must address the collapse of the paper based, token exchange processes that we as a race have spent the last 2.5 millennium codifying into social process and law, onto the transactions operated in the virtual world.
What this means is the creation of uniform, strong evidentiary model for digital transactions. This is made more critical by the fact that the speed at which computers and networked systems do their deeds is so fast that when applied to a number of processes originally erected over paper instruments, a number of new liabilities that become serious ones.
The unrestricted and unchecked adaptation of human processes has caused many systems and real-world transaction models that depend on the time-delay in their method to break and many more to turn from benign to potentially very virulent in their ability to effect damage faster than it can be stopped or caught. Banking and the financial world are particularly at risk.
This then brings some new criteria to the forefront of digital transaction processing. The concept of Risk Mitigation, Privacy, and Legal Culpability have become common place in modern eBusiness operations.
Digital acts then, for lack of a better phrase, have a unique set of requirements to fully equal the paper based efforts that mankind has evolved.
From the three requirements listed, the most difficult one in modern computing is to remove the human culpability model. In most cases, the SysAdmin or the Database administration is the weak link. With modern legislation like the criminal penalty section of the Health Insurance Portability and Accessibility Act (HIPAA sect 1077) having passed into active law, these issues are more than ever on the forefront of risk-managers and IT directors minds, or at least they should be.
With commercial PKI coming of age and X.509 certificates becoming more and more mainstream it will not be too much longer before everyone has an identity certificate. So it can be left that we are all headed for some form of PKI identity to assure us of protection on the Net.
The key missing piece is a culpable time and time base management services. Many rely on GPS and mechanical systems to get time data. When analyzed, these systems are either totally non-functional as a trust anchor, or have very limited functionality in the risk-model.
The goal in managing time is simple:
With these requirements, some simple questions can be asked about time sources and timing practices e.g., does using GPS as the ultimate source of time in a secured computing system work? I believe that the answer is simply no.
GPS per se has many functional liabilities and is easily spoofed or knocked out through Denial Of Service (DoS) attack models. It also has the distinct problem that there is no way to prove where the time data came from, no identity signature and that the actual time acquisition model is broadcast-only leaving no UNICAST method of gaining time as NTP Provides.
NTP on the open Internet has similar liabilities, and since it does not support a PKI nor do the Governmental Operators provide a PKI based Timing Solutions.
Many people have opted for local board-level timing solutions and while these systems may keep accurate time inside these people environments, their initialization process is what installs the critically culpable time-sense into them. since I dismiss GPS and its services, and NTP across the open Internet, these systems are also at risk.
Telephonic, ACTS, time setting systems also have a similar liability in that while they may deliver good time data to the client's side, they do not log or authenticate the user or time data, making the totality of the proofing model the phone-billing the clients get suspect.
The answer is simple to define but difficult to implement. It includes the development of secured access to time data and the methods of conveying into the vessels that use it, i.e. the creation of Timing Authorities. This time data is provable in its source, and is synchronized and certified by a standards laboratory as being spot-on UTC. Only such a time source will withstand critical audit and evidentiary questions going forward into the future.