16. Security Considerations (Considérations de sécurité)
16.1. Attacks against the Protocol (Attaques contre le protocole)
16.1.1. Outside Attacks (Attaques externes)
Un attaquant peut tenter de modifier les messages STUN en transit, afin de provoquer l'échec d'une opération STUN. Ces attaques contre les requêtes et les réponses peuvent être détectées grâce au mécanisme d'intégrité des messages, en utilisant soit les identifications à court terme soit à long terme. Bien entendu, une fois détectés, les paquets manipulés seront abandonnés, provoquant l'échec effectif de la transaction STUN. Cette attaque ne peut être lancée que par un attaquant sur le chemin.
Un attaquant qui peut observer, mais ne peut pas modifier, les messages STUN en transit (par exemple, un attaquant présent sur un support d'accès partagé, tel que Wi-Fi) peut voir une requête STUN puis envoyer immédiatement une réponse STUN, généralement une réponse d'erreur, afin de perturber le traitement STUN. Pour les messages avec MESSAGE-INTEGRITY, cette attaque est également empêchée. Cependant, certaines réponses d'erreur, spécifiquement celles liées à l'authentification, ne peuvent pas être protégées par MESSAGE-INTEGRITY. Lorsque STUN lui-même est exécuté sur un protocole de transport sécurisé, tel que TLS, ces attaques sont complètement atténuées.
Selon l'utilisation STUN, ces attaques peuvent avoir des conséquences minimes et par conséquent l'intégrité des messages peut ne pas être nécessaire pour les contrer. Par exemple, lorsque STUN est utilisé avec un serveur STUN de base pour découvrir un candidat réfléchi par le serveur pour une utilisation avec ICE, l'authentification et l'intégrité des messages ne sont pas nécessaires, car ces attaques sont détectées pendant la phase de vérification de la connectivité. Cependant, les vérifications de connectivité elles-mêmes nécessitent une protection pour que ICE fonctionne correctement dans l'ensemble. Comme discuté dans la Section 14, une utilisation STUN décrit quand l'authentification et l'intégrité des messages sont nécessaires.
Étant donné que STUN utilise HMAC avec un secret partagé pour l'authentification et la protection de l'intégrité, il est susceptible aux attaques par dictionnaire hors ligne. Lorsque l'authentification est utilisée, les mots de passe devraient (SHOULD) être choisis de manière à ne pas être sujets à de telles attaques par dictionnaire hors ligne. Sécuriser le canal lui-même en utilisant TLS peut atténuer ces attaques. Cependant, STUN est le plus souvent exécuté sur UDP, et dans ces cas, les mots de passe forts sont la seule défense contre ces attaques.
16.1.2. Inside Attacks (Attaques internes)
Un client malveillant pourrait essayer de lancer une attaque DoS contre un serveur en lui envoyant un grand nombre de requêtes STUN. Heureusement, les requêtes STUN peuvent être traitées sans état par un serveur, ce qui rend de telles attaques difficiles à lancer.
Un client malveillant peut utiliser un serveur STUN comme réflecteur, en lui envoyant des requêtes avec une adresse IP et un port source falsifiés. Dans ce cas, la réponse serait livrée à cette adresse IP et ce port source. Il n'y a pas d'amplification du nombre de paquets avec cette attaque (le serveur STUN envoie un paquet pour chaque paquet envoyé par le client), bien qu'il y ait une petite amplification de la quantité de données, car les réponses STUN sont généralement plus grandes que les requêtes. Le filtrage de l'adresse source en entrée peut aider à atténuer cette attaque.
Révéler la version logicielle spécifique de l'agent via l'attribut SOFTWARE pourrait permettre à un attaquant de lancer plus facilement des attaques contre un logiciel connu pour contenir des failles de sécurité. Les implémenteurs devraient (SHOULD) faire de l'utilisation de l'attribut SOFTWARE une option configurable.
16.2. Attacks Affecting the Usage (Attaques affectant l'utilisation)
Cette section répertorie les attaques qui pourraient être lancées contre une utilisation STUN. Chaque utilisation STUN doit (must) considérer si ces attaques sont applicables et, le cas échéant, discuter des contre-mesures.
La plupart des attaques dans cette section tournent autour d'un attaquant modifiant l'adresse réfléchie apprise par le client STUN via une transaction requête/réponse Binding. Étant donné que l'utilisation de l'adresse réfléchie est une fonction de l'utilisation, l'applicabilité et les remèdes pour ces attaques sont spécifiques à l'utilisation. Dans le cas le plus courant, un attaquant sur le chemin peut facilement modifier l'adresse réfléchie. Considérez, par exemple, le cas courant de STUN exécuté directement sur UDP. Dans ce cas, un attaquant sur le chemin peut modifier l'adresse IP source de la requête Binding avant qu'elle n'arrive au serveur STUN. Le serveur STUN retournera alors cette adresse IP dans l'attribut XOR-MAPPED-ADDRESS au client et enverra la réponse à cette adresse IP et ce port (falsifiés). Si l'attaquant peut également intercepter cette réponse, il peut la rediriger vers le client. Se protéger contre cette attaque en utilisant une vérification d'intégrité de message est impossible, car la valeur d'intégrité de message ne peut pas couvrir l'adresse IP source, car elle doit être modifiable par les NAT intermédiaires. Au lieu de cela, une solution pour prévenir les attaques listées ci-dessous est pour le client de vérifier l'adresse réfléchie apprise, comme cela est fait dans ICE [MMUSIC-ICE]. D'autres utilisations peuvent utiliser d'autres moyens pour prévenir ces attaques.
16.2.1. Attack I: Distributed DoS (DDoS) against a Target (Attaque DDoS distribuée contre une cible)
Dans cette attaque, l'attaquant fournit à un ou plusieurs clients la même adresse réfléchie falsifiée qui pointe vers une cible prévue. Cela trompe les clients STUN en leur faisant croire que leurs adresses réfléchies sont égales à celle de la cible. Si les clients distribuent cette adresse réfléchie pour recevoir du trafic sur celle-ci (par exemple, dans un message SIP), le trafic sera plutôt envoyé à la cible. Cette attaque peut fournir une amplification substantielle, en particulier lorsqu'elle est utilisée avec des clients qui utilisent STUN pour activer des applications multimédias. Cependant, elle ne peut être lancée que contre une cible pour laquelle les paquets du serveur STUN vers la cible passent par l'attaquant, limitant les cas où elle est possible.
16.2.2. Attack II: Silencing a Client (Réduire au silence un client)
Dans cette attaque, l'attaquant fournit à un client STUN une adresse réfléchie falsifiée. L'adresse réfléchie fournie est une adresse de transport qui ne mène nulle part. En conséquence, le client ne recevra aucun des paquets qu'il s'attend à recevoir lorsqu'il distribue l'adresse réfléchie. Cette exploitation n'est pas très intéressante pour l'attaquant. Elle affecte un seul client, qui n'est fréquemment pas la cible souhaitée. De plus, tout attaquant qui peut monter l'attaque peut lancer des attaques DoS plus efficaces contre le client d'autres manières, par exemple en empêchant le client de recevoir toute réponse du serveur STUN, ou même d'un serveur DHCP. Comme pour l'attaque de la Section 16.2.1, cette attaque n'est possible que lorsque l'attaquant est sur le chemin des paquets envoyés depuis le serveur STUN vers cette adresse IP inutilisée.
16.2.3. Attack III: Assuming the Identity of a Client (Assumer l'identité d'un client)
Cette attaque est similaire à l'attaque II. Cependant, l'adresse réfléchie falsifiée pointe vers l'attaquant lui-même. Cela permet à l'attaquant de recevoir le trafic destiné au client.
16.2.4. Attack IV: Eavesdropping (Écoute clandestine)
Dans cette attaque, l'attaquant force le client à utiliser une adresse réfléchie qui mène à lui-même. Il transmet ensuite tous les paquets qu'il reçoit au client. Cette attaque permettrait à un attaquant d'observer tous les paquets envoyés au client. Cependant, pour lancer l'attaque, l'attaquant doit avoir déjà pu observer les paquets du client vers le serveur STUN. Dans la plupart des cas (comme lorsque l'attaque est lancée depuis un réseau d'accès), cela signifie que l'attaquant pouvait déjà observer les paquets envoyés au client. Cette attaque n'est donc utile que pour observer le trafic par des attaquants sur le chemin du client vers le serveur STUN mais pas généralement sur le chemin des paquets acheminés vers le client.
16.3. Hash Agility Plan (Plan d'agilité de hachage)
Cette spécification utilise HMAC-SHA-1 pour le calcul de l'intégrité des messages. Si, à un moment futur, HMAC-SHA-1 est compromis, la correction suivante peut être appliquée.
Nous définirons une extension STUN qui introduit un nouvel attribut d'intégrité de message calculé en utilisant un nouveau hachage. Les clients devraient inclure à la fois les nouveaux et anciens attributs d'intégrité de message dans leurs requêtes ou indications. Les nouveaux serveurs utiliseraient le nouvel attribut d'intégrité de message, et les anciens serveurs utiliseraient l'ancien. Après une période de transition au cours de laquelle des implémentations mixtes sont déployées, l'ancien attribut d'intégrité de message sera déprécié par une autre spécification, et les clients cesseraient de l'inclure dans les requêtes.
Il est également important de noter que la clé utilisée par HMAC est elle-même calculée en utilisant un hachage du nom d'utilisateur et du mot de passe. Le choix du hachage MD5 a été fait pour le stockage hérite de mots de passe sous cette forme dans des bases de données. Si, à l'avenir, des travaux découvrent que l'utilisation de HMAC avec des entrées MD5 est non sécurisée, et qu'un hachage différent est nécessaire, ce plan peut également être utilisé pour ce changement. Cependant, cela nécessiterait que les administrateurs repopulent leurs bases de données.