16. Security Considerations
16.1. Attacks against the Protocol
16.1.1. Outside Attacks
An attacker can attempt to modify STUN messages in transit, in order to cause a STUN operation to fail. These attacks against requests and responses can be detected through the message-integrity mechanism, using either the short-term or long-term credential. Of course, once detected, the manipulated packets will be dropped, causing the STUN transaction to effectively fail. This attack can only be launched by an on-path attacker.
An attacker that can observe, but not modify, STUN messages in transit (for example, an attacker present on a shared access medium, such as Wi-Fi) can see a STUN request and then immediately send a STUN response, typically an error response, in order to disrupt STUN processing. For messages with MESSAGE-INTEGRITY, this attack is also prevented. However, some error responses, specifically those related to authentication, cannot be protected by MESSAGE-INTEGRITY. When STUN itself is run over a secure transport protocol, such as TLS, these attacks are completely mitigated.
Depending on the STUN usage, these attacks may be of minimal consequence and therefore message integrity may not be needed to thwart them. For example, when STUN is used with a basic STUN server to discover a server reflexive candidate for usage with ICE, authentication and message integrity are not needed, since these attacks are detected during the connectivity check phase. However, the connectivity checks themselves need protection in order for ICE to operate properly overall. As discussed in Section 14, a STUN usage describes when authentication and message integrity are needed.
Since STUN uses HMAC with a shared secret for authentication and integrity protection, it is susceptible to offline dictionary attacks. When authentication is used, passwords SHOULD be chosen that are not subject to such offline dictionary attacks. Securing the channel itself using TLS can mitigate these attacks. However, STUN is most commonly run over UDP, and in those cases, strong passwords are the only defense against these attacks.
16.1.2. Inside Attacks
A malicious client might try to launch a DoS attack against a server by sending it a large number of STUN requests. Fortunately, STUN requests can be processed statelessly by a server, making such attacks hard to launch.
A malicious client may use a STUN server as a reflector, sending it requests with a falsified source IP address and port. In this case, the response would be delivered to that source IP and port. There is no amplification of the number of packets with this attack (the STUN server sends one packet for each packet sent by the client), although there is a small amount of amplification of the amount of data, since STUN responses are typically larger than requests. Ingress source address filtering can help mitigate this attack.
Revealing the specific software version of the agent through the SOFTWARE attribute might allow an attacker to launch attacks more easily against software that is known to contain security holes. Implementers SHOULD make usage of the SOFTWARE attribute a configurable option.
16.2. Attacks Affecting the Usage
This section lists attacks that might be launched against a STUN usage. Each STUN usage must consider whether these attacks are applicable to it, and if so, discuss countermeasures.
Most of the attacks in this section revolve around an attacker modifying the reflexive address learned by the STUN client through a Binding request/response transaction. Since the usage of the reflexive address is a function of the usage, the applicability and remedies for these attacks are usage-specific. In the most common case, an on-path attacker can easily modify the reflexive address. Consider, for example, the common case of STUN run directly over UDP. In this case, an attacker on-path can modify the source IP address of the Binding request before it arrives at the STUN server. The STUN server will then return this IP address in the XOR-MAPPED-ADDRESS attribute to the client and will send the response back to that (falsified) IP address and port. If the attacker can also intercept this response, it can redirect it back to the client. Protecting against this attack using a message-integrity check is impossible, since the message-integrity value cannot cover the source IP address, since it must be modifiable by intervening NATs. Instead, one solution to preventing the attacks listed below is for the client to verify the reflexive address learned, as is done in ICE [MMUSIC-ICE]. Other usages may use other means for preventing these attacks.
16.2.1. Attack I: Distributed DoS (DDoS) against a Target
In this attack, the attacker provides one or more clients with the same falsified reflexive address that points to a intended target. This will trick the STUN clients into thinking that their reflexive addresses are equal to that of the target. If the clients hand out that reflexive address in order to receive traffic on it (for example, in a SIP message), the traffic will instead be sent to the target. This attack can provide substantial amplification, especially when used with clients that are using STUN to enable multimedia applications. However, it can only be launched against a target for which packets from the STUN server to the target pass through the attacker, limiting the cases in which it is possible.
16.2.2. Attack II: Silencing a Client
In this attack, the attacker provides a STUN client with a falsified reflexive address. The reflexive address it provides is a transport address that routes to nowhere. As a result, the client will receive none of the packets it expects to receive when it hands out the reflexive address. This exploit is not very interesting for the attacker. It impacts a single client, which is frequently not the desired target. Furthermore, any attacker that can mount the attack can launch more effective DoS attacks against the client in other ways, such as by preventing the client from receiving any response at all from the STUN server, or even a DHCP server. As with the attack in Section 16.2.1, this attack is only possible when the attacker is on-path for packets sent from the STUN server towards this unused IP address.
16.2.3. Attack III: Assuming the Identity of a Client
This attack is similar to attack II. However, the falsified reflexive address points to the attacker itself. This allows the attacker to receive traffic that was destined for the client.
16.2.4. Attack IV: Eavesdropping
In this attack, the attacker forces the client to use a reflexive address that routes to itself. It then forwards any packets it receives to the client. This attack would allow an attacker to observe all packets sent to the client. However, in order to launch the attack, the attacker must have already been able to observe packets from the client to the STUN server. In most cases (such as when the attack is launched from an access network), this means that the attacker could already observe packets sent to the client. This attack is, therefore, only useful for observing traffic by attackers on the path from the client to the STUN server but not generally on the path of packets being routed to the client.
16.3. Hash Agility Plan
This specification uses HMAC-SHA-1 for computation of the message integrity. If, at a future time, HMAC-SHA-1 is found to be compromised, the following remediation can be applied.
We will define a STUN extension that introduces a new message-integrity attribute computed using a new hash. Clients would need to include both the new and old message-integrity attributes in their requests or indications. New servers would utilize the new message-integrity attribute, and old servers would utilize the old. After a transition period in which mixed implementations are in deployment, the old message-integrity attribute will be deprecated by another specification, and clients would cease including it in requests.
It is also important to note that the key used by HMAC is itself computed using a hash of the username and password. The choice of MD5 hash was done for legacy database storage of passwords in this form. If, in the future, work discovers that the usage of HMAC with MD5 inputs is insecure, and a different hash is needed, this plan can be used for that change as well. However, this would require administrators to repopulate their databases.