Application-Level Reflection Attacks
Tom Vogt <tom-at-lemuria-dot-org>
Current publications on the matter of distributed reflection denial-of-service (DRDOS) attacks focus on low-level (that is, reliable), but harmless variants of the theme. This article shows a sample application of reflection DOS attack mechanisms that has a much more severe impact.
The basic mechanism of a distributed reflection DOS attack, as outlined in [gibson], consists of an attacker (possibly using zombies) bouncing packets with a forged source IP address off a legitimate server so that server, acting in good faith, sends reply packets to the forged source IP, i.e. the victim.
The attack that Gibson experienced used TCPs SYN/ACK mechanism, where the reflection servers try to establish a connection with the victim by sending ACK packets its way, the sheer flood of which saturates the victim's line. Once the victim does no longer respond with RST packets, things get worse as the reflection servers start to retransmit the ACK packets, assuming them to have been lost in transit.
The attacker on Gibson used a low-level, and thus reliable, but ineffective variant of this attack mechanism. The maximum leverage factor of 4 (if we assume 3 retransmits) is only reached after the victims line is already saturated, thus adding nothing to the impact except overkill. During the initial phase of the attack, the leverage factor is 1, i.e. for every byte the victim receives, the attacker (or his zombies) needs to send out one byte himself. This is a very unsophisticated method of attack and requires considerable resources on the attacker side, either by using his own (e.g. having a fat pipe to utilise) or by the need to install a large number of zombies.
A higher leverage could obviously be reached by finding a communication that will send a large packet in reply to a small packet. TCP, with the requirement of the initial 3-way-handshake, does not offer this, so I turned my attention to other protocols.
The easiest alternative to find widely deployed and easily abused is UDP, which requires no handshaking and is in use for many different purposes. Because of the missing handshake, however, UDP itself does not include an automatic reply mechanism. The reply (and leverage) needs to be found on a higher level, namely the application that is communicating via UDP.
An extensive search will, without doubt, find a high number of UDP-based services that can be exploited in a manner similar to the one outlined here. To illustrate the mechanism, a single detailed example will do.
After a short search, I zeroed in on game servers, specifically those for first-person shooters (FPS) as a viable option. In order to minimalise latency and make full use of the ``better lost than late'' principle, many of the FPS games played on the Internet use UDP as the protocol of choice, even for non-time-critical functions such as requesting server information.
Obviously, a reply to a server information request will be much longer than the request itself, so a much higher leverage than in Gibsons example is easily obtained. Moreover, finding suitable reflection servers is a no-brainer because many games supply lists of them, often updated in real-time through the use of master servers.
Due to higher familiarity, I decided on Quake3 for a proof-of-concept implementation, but other games offer similar, or even better, platforms, as illustrated below.
The Quake3 protocol is very simple. UDP packets start with FF FF FF FF followed by a plain text command. The most interesting commands are ``getstatus'' and ``getinfo'', which return a full set of information about the server, including items like current map name, a version string and a list of players (with names). All these strings add up to - according to my tests - an average reply of over 500 bytes (including UDP headers). The request packet is 56 or 58 bytes, yielding a leverage factor of almost 10.
The Halflife protocol works very similar, unsurprisingly since Halflife is built on a modified Quake2 engine. Instead of ``getstatus'', the most interesting commands here are ``details'' and ``rules'', which can return several hundred bytes each, depending on the server.
Another candidate is Unreal Tournament, which works similar but offers the additional option of concatenating commands, say ``\info\\players\\basic\\'' which will return the server info data, the list of players and some basic information, together easily several hundred bytes in length.
More details on these UDP protocols is readily available on the Internet. The data on Halflife and UT was taken from [0x00.org].
Putting these things together, an attack tool utilising FPS game protocols is easy to create. In fact, I have implemented a proof-of-concept implementation using Quake3 in just a few hours. Someone more familiar with socket programming can easily create a full-fledged attack suite in a lazy afternoon.
The first step in such an attack is to acquire a list of servers you can use as reflectors. All of the games mentioned above are glad to provide just such a list to anyone who asks, using the same or a very similar UDP protocol and talking to a special server (the ``master server''). This is how popular tools such as Gamespy or the games own built-in server browsers work.
The game servers have built-in code to announce themselves to the master server on startup, and the master server provides the list of known servers to the game clients when they browse the available servers.
The underlying protocol - probably due to easy of implementation - uses the same mechanism as the server status communication, namely UDP, short packets, FF FF FF FF and plain text commands in the case of Q3. The command in question is ``getservers'', plus a protocol identifier and some options. The master server replies with a list of servers, simple 6 bytes (4 for the IP, 2 for the port) per server and a 5C as delimiter.
For the Halflife servers, sample code can be found at [0x00.org] and shows that the process is very similar and likewise trivial.
Once the list of reflectors has been acquired, all that is left to do is sending out UDP packets to them. The UDP packets are crafted to create the highest possible leverage factor, i.e. to be short while resulting in a lengthy server reply. Using the victim's IP address as the source IP, the game server will happily send its reply to the victim.
A leverage factor of 10 is realistic, and my tests have shown that the game servers will answer a great many of status or info requests without complaining. Since there are many game servers available (over 3000 for Quake3, over 10000 for Counterstrike/Halflife), it is easy to orchestrate an attack without using too much resources of each individual server.
If the bandwidth of the victim is known, blowing it off the Internet is a simple matter of calculation. For example, assuming that the victim has a 2 Mbit Internet connection, and knowing that the average info reply packet of a Quake3 server is 500 byte, we need to send about 4000 such packets per second that way. We can almost do this with no more than one request per server per second. Our bandwidth usage would be 56*4000 or about 220Kbit, which is available to some ADSL users and almost everyone with a permanent connection.
In order for this attack to be successful, it may not place a too high burden on the attack network, i.e. the Quake3, Halflife or other game servers. A practical limit may be hit somewhere at 2-5 requests per second1. Using the Halflife server network, this means a maximum impact of somewhere between 10 and 23 Mbit per second. It appears that only with the use of multiple applications can a high-profile site (with an assumed Internet connection of at least one 155 Mbit line) be successfully attacked.
Being perfectly legitimate requests, the attack is not likely to be immediately noticed on the reflection servers. They are not logged by the game servers, either. Since many popular servers already serve a huge number of these requests, an additional few requests per second are not likely to be noticed. Moreover, even if the attack is noticed at the reflectors (maybe due to the oddity of having the same client request so continuously) it is unlikely that it will be interpreted as part of an attack. Much more likely, the reflector admin will assume that a misbehaving client or misconfigured statistics program is causing this traffic.
The usage of reflectors in DDOS attacks is nothing new. However, all attacks known to me so far utilise TCP and/or IP features to commence the attack, such as SYN packets and their ACK replies, or ICMP traffic.
I have shown above that similar attacks can be made by exploiting the application layer instead of the network layer. This kind of attack is very simple to conduct, requiring nothing but the ability to spoof IP addresses and no more work than a few hours of coding.
Like the network-layer attacks, no trivial solution exists, because the parties conducting the actual attack (i.e. the reflectors) work as designed, and can not easily stop supplying game information, or even throttle the replies without impacting their intended workings. As in most DOS attacks, the ability to spoof IP addresses is the crucial factor for the attacker. However, since zombies can and are being used in DOS attacks, as long as spoofing is possible in huge parts of the Internet, these attacks will remain possible.
At this time, the attack networks capabilities are limited, putting a cap on the maximum impact that can be reached via what I call ``application level reflection DOS'' attacks. Nevertheless, the high leverage factor and ease of conducting this kind of attack make it necessary to put this concept on the radar.
This document was generated using the LaTeX2HTML translator Version 2K.1beta (1.48)
The command line arguments were:
The translation was initiated by Tom Vogt on 2002-07-05
Tom Vogt 2002-07-05