Amplification attacks explained

Tags: security, networking.
By lucb1e on 2012-07-16 20:29:03 +0100

A Google search for amplification attacks returned a disappointing number of appropriate hits (none, actually); all results are specific for the DNS protocol. This post will explain in more general terms what an amplification attack is and does.

Definition
An amplification attack is an attack where the attacker triggers a big response from a third party to be sent to the target.

Basics
Amplification means to increase something in volume, in this case a (Distributed) Denial of Service attack. The idea involves three parties:
- An attacker;
- A relay;
- And the target.

The relay is vulnerable for being fooled. You must see a packet like a letter. To send a return letter, you need to know where it came from. So the original letter includes a "Source address," telling you where it came from.

Now the attacker sends a packet to the relay, after which the relay sends a packet to wherever it believes the original packet came from (which is the source IP address that the attacker put in the packet). The packet sent by the relay is larger than the packet the attacker sent to the relay, that is why it is amplification.

For example if the attacker sends 508 bytes to the relay, and the relay responds with a packet of 1046 bytes (to the target, but the relay doesn't know that), then the attack will be amplified over two times. The target now gets an attack over twice as large as when the attacker conducted the attack himself, given that the relay has enough capacity for this.

An advantageous side-effect to the attacker is that the target can't determine where the attack came from. The source IP of the attack will come from the relay, so either the relay will be sued or manages to convince the target that he is being used.
Also the relay can't find the original attacker since the source is spoofed.

Example
The most common example is the DNS server. Many servers run DNS and enough people rely on DNS, so you can't simply turn it off at an attack. That's why it's a very popular relay to use. But almost every Google result talking about amplification attacks explicitly talks about DNS, so let's use another protocol as example here.

The Quake protocol, or specifically it's referred to as 'protocol 68', is much simpler than DNS. Here is an example attack:

The attacker sends a command to the server (relay) to request info.
Attacker to relay: [20 bytes IP header][8 bytes UDP header][payload]
The payload: ÿÿÿÿgetstatus
(Yes, the y-umlaut is supposed to be there, it's 0xFF).
All in all: 41 bytes.

The relay replies, it thinks to the original client but because the attacker entered a fake source IP it will send the reply to the target.
Relay to the target: [20 bytes IP header][8 bytes UDP header][payload]
A sample payload: ÿÿÿÿstatusResponse
\g_instantgib\1\dmflags\0\fraglimit\32\timelimit\20\sv_hostname\^3GoD^7|^1I^7nst
antgib\sv_maxclients\12\sv_minRate\0\sv_maxRate\9000\sv_minPing\0\sv_maxPing\0\s
v_floodProtect\1\g_maxGameClients\10\capturelimit\8\g_delagHitscan\1\elimination
_roundtime\90\elimination_ctf_oneway\0\version\ioq3+oa 1.35 win_mingw-x86 Oct 20
2008\g_gametype\4\protocol\71\mapname\oasago2\sv_privateClients\0\sv_allowDownlo
ad\0\bot_minplayers\1\.Hosted-by\GoD|RMF\.Location\EU/Netherlands\.Awesome\true\
.Admins\GoD|Members\g_rockets\0\gamename\baseoa\g_needpass\0\g_obeliskRespawnDel
ay\10\g_humanplayers\0
41 0 "Sergei"
49 0 "Dark"
All in all: 660 bytes.

As you can see, the reply is larger than the request, so it costs the attacker much less bandwidth to perform the attack.

The total amplification here is 16x (=660/41). That means trouble.

Protection
An attacker will try to get as much output as possible from as little input as possible, and then do that a lot of times. Often this is means there is one command to generate as much output as possible, like "getstatus," which never changes (or hardly changes). If any IP requests this command over 10 times a second (whereas a normal value for this would be a peak of 5 times a second, and commonly even under 100 times a day per IP), you know you're being attacked.

It's pretty much the same as protecting against any DDoS attack: too many request = IP block. Not a pretty solution, especially for people behind a NAT. Ban the public IP, and everyone behind it will be banned as well.So it's not a pretty solution, but the only working one.

How to protect your application
First of all, identify the need for UDP instead of TCP. TCP protocol is hardly slower than UDP because of the congestion window[1], and when Nagle's algo is turned off (also known as TCP_NODELAY) it will send everything at once instead of grouping packets to save bandwidth. With TCP it's much harder (and certainly impractical for amplification attacks) to spoof an IP address and make it appear a packet came from a different source.

So do you really need UDP? And you can't remove or change the command to trigger that big response? Alright, then there are two things, the first being extremely important:

1. If the server responds to a malformed (invalid) packet with a response, for example "error", then make sure that when the server receives "error" that it won't respond.
   For example protocol 68 sends ÿÿÿÿdisconnect when an invalid packet arrives. If the server would assume a client sent this and respond to it, you can make two servers running proto68 go into an infinite loop: Send a random message to one server, spoofing another server, and they will keep telling each other to disconnect.
   
   Make sure that this is not possible, or it will be very easy to DoS two servers at once using only a few initial packets to initiate a couple of those loops!
   
   
2. This is a bit more work, but you could also keep track of how often a certain IP requests a vulnerable command (vulnerable for amplification attacks, that is). If it is more often than reasonably possible, temporarily ban the IP where it appears to come from.
   Also make sure that this is configurable, so that high-load and low-load servers can adjust the ban threshold as needed.

What to do if you are the target
Notify the relay(s), and firewall any incoming packets from the relay(s). There isn't really much else to do; it's a plain old (D)DoS attack.


[1] The congestion window in TCP sets an amount of data that either party may send before receiving an acknowledgement. Without this A would send a TCP packet to B, B would send an acknowledgement that he received it to A, and only then A could send a new packet. With this congestion window, A can send up to X packets before it pauses to wait for an acknowledgement. This window is large enough to provide maximum throughput in almost all scenarios.