Reflection+Amplification attacks abusing TURN servers

Last week there were many messages in the coturn issue tracker about TURN instances being blocked by some cloud providers because it was detected that those servers were being used to attack other hosts.

This is not new as Wire had already reported it and even suggested a mitigation some months ago.

The attacks being carried out in this case are based on two properties of TURN servers:

• Reflection: A TURN server, by design, sends the responses to the TURN messages to the source IP of the Request. If an attacker is able to change his source IP address (spoofing) then it can direct the response of his TURN request to any other host he wants.
• Amplification: TURN responses are usually bigger than the corresponding requests. This is especially problematic for authentication error responses that must include a NONCE value to be used to attempt authentication properly based on the standard authentication defined in the protocol.

We can see a real example of the second property in a commercial TURN service were the amplification factor is 2x (in other providers this amplification factor is even bigger):

Size of Allocation Request and Response in a TURN server

With those two properties in mind this is how the attack looks like:

The root cause of this problem is that the Unauthorized responses sent by the TURN server are bigger than the requests, otherwise the attacker wouldn’t get any benefit from the TURN server and would send the request directly to the attacked host. With the default coturn configuration (and similarly in other servers) this is around 2x-2.5x increase in size depending on your software name and realm configuration, so there is a big incentive to use coturn to reflect the attack instead of sending it directly.

The mitigation suggested by the Wire team was based on limiting the number of unauthenticated responses sent to a specific IP, and that’s effective as they have tested in production, and probably this featurewill be integarted in a way or another in coturn, but this approach has two limitations: 1) there can be other responses outside of 401s that could be used also for these attacks and 2) if the attacker is attacking a range of IPs instead of a single one this mechanism wouldn’t block it without adding more elaborated logic.

With all that in mind lets review the format of those error responses and see if we can optimize them. This is an example again from the same commercial TURN provider that uses coturn opensource server:

Looking at the content of those 401-Unauthorized responses we can see that we could try to reduce the size and because of that the amplification factor. These are the attributes sent in the response and what we could do with them:

• 24 bytes of SOFTWARE attribute → You should just remove it given that it is an optional attribute (this was already configurable in coturn, now with the latest version the default is off)
• 12 bytes of error phrase in ERROR-CODE → The error phrase is not required and it provides little value so we can just remove it (PR pending review)
• 16 bytes of NONCE → This probably could be shorter, specially when the type of credentials used are already valid for a short period of time, but the impact of changing this is not fully clear and requires more carefull review.
• 12 bytes of REALM → The realm is not providing any value, at least for WebRTC use cases, so we should make it as short as possible (for example just ”t”). 

With those suggested changes the message should go from 142 bytes to 95 making the amplification “only” 1.35x that hopefully makes it much less worth it.

In addition to those suggestions, if you can change firewall configuration for the TURN incoming traffic following rules will help blocking illegal traffic:

• Block traffic from illegitimate ports (for example privileged ports — below 1024 — cannot be used by normal clients and as such any traffic from those ports is illegitimate)
• STUN/TURN (and underlying UDP) allow for very long messages. But in reality, messages longer than MTU are not used, at least for WebRTC use cases. That means that any message fragment is not a valid STUN/TURN message and should be blocked.
• Monitor 401 errors from specific IPs and use fail2ban utility to block those IPs.

An interesting idea suggested by Philipp Hancke is to have STUN/TURN clients in browsers to send padding data in the request. TURN servers could ignore incoming packets without this attribute. This would make the protocol slightly less efficient but it bring the amplification factor below one. The other option could be to change the way authentication works in TURN to remove the need of those nonce attributes or rethink the authentication and authorization flows.

Let’s see how these mitigations go and if the attacks keep going maybe we should consider that. And remember to upgrade to the latest version 4.7.0 (which enables multiple options that helps mitigate this type of attacks by default) or at least review your configuration to apply some of the recommendations in this post.

Thank you very much to Philipp Hancke and Pavel Punsky for the review and contributions to this post. 🙇

You can follow me in Twitter if you are interested in Real Time Communications or want to comment about the topic of this post.