Subject: [tram] stun amplification vulnerability

From: Mészáros Mihály <[email-masked]>
Date: Tue, 12 Oct 2021 14:28:52 +0200

Hi,

I experienced, that STUN binding requests(udp) came from spoofed/strange
source addresses (from e.g. zoom,valve, etc. address range) to our STUN
servers.

I don't have better explanation for that, probably someone is using our
STUN server responses to attack the spoofed source IPs.

If a STUN server is responding to a binding request it may sends many
attributes(RFC5780 attributes and (for classical backward compatibility)
mapped address, software, fingerprint,  etc.),
this way the request/response gain factor could be ~3x.

STUN should not authenticated, so the attack could be distributed to
many STUN servers easily, but even if STUN request is authenticated,
then 401 response also gives 2x times bigger response.

If STUN not authenticated, then the amount of attack traffic could be
relativity small and distributed in time  (if attack is very well
distributed to many STUN servers).
This way the attacker's traffic could be easily under the radar threshold.

Despite the gain factor 2-3x is not very big, still it seems it has
attracted someones attention.

I am wondering if it worth to add a warning to STUN Security
Consideration about it?

Implementations should consider possibility of this type of attack.
As mitigation implementation may consider to limit the STUN response
only to send one attribute "XOR-MAPPED-ADDRESS", to reduce the gain
factor as close as possible to 1x.

Thanks,
Misi

---

From: Dan Wing <[email-masked]>
Date: Tue, 12 Oct 2021 08:50:08 -0700

Reducing the attributes in STUN responses could break existing implementations that expect attributes in the response.  But if you control those existing implementations, you could of course be confident the reduced STUN response works with those clients.

Rate limiting at the server so only, say, 5 responses are sent to an IP address per minute seems it would be pretty effective, and would require the attacker to involve a lot of different STUN servers for a successful attack (as you explained).  This doesn't require validating client interoperability.  Such rate limiting is mentioned briefly in https://datatracker.ietf.org/doc/html/rfc5389#section-16.1.2, but the mitigation described is source address filtering rather than rate limiting.

Another approach is requiring the request to be larger than the response by using the PADDING attribute in the request.  PADDING was defined by RFC8780 for a different purpose, but seems it could be useful here so attackers are required to expend the same bandwidth as the STUN server, so you're at 1x amplification factor.

-d

> On Oct 12, 2021, at 5:28 AM, Mészáros Mihály <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram