Re: [tram] stun amplification vulnerability

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 <misi@majd.eu> wrote:
> 
> 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
> 
> 
> 
> 
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram