Application-Level Reflection Attacks

Tom Vogt <tom-at-lemuria-dot-org>

Abstract:

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.