18. Security Considerations (Considérations de sécurité)

Il existe plusieurs types d'attaques possibles dans un système ICE. Cette section examine ces attaques et leurs contre-mesures. Ces contre-mesures comprennent :

• Utiliser ICE en conjonction avec des techniques de signalisation sécurisées, telles que SIPS.

• Limiter le nombre total de vérifications de connectivité à 100, et éventuellement limiter le nombre de candidats qu'ils accepteront dans une offre ou une réponse.

18.1. Attacks on Connectivity Checks (Attaques sur les vérifications de connectivité)

Un attaquant peut tenter de perturber les vérifications de connectivité STUN. En fin de compte, toutes ces attaques trompent un agent en lui faisant penser quelque chose d'incorrect sur les résultats des vérifications de connectivité. Les fausses conclusions possibles qu'un attaquant peut essayer de provoquer sont :

False Invalid (Faux invalide) : : Un attaquant peut tromper une paire d'agents en leur faisant croire qu'une paire de candidats est invalide, alors qu'elle ne l'est pas. Cela peut être utilisé pour amener un agent à préférer un candidat différent (tel que celui injecté par l'attaquant) ou pour perturber un appel en forçant tous les candidats à échouer.

False Valid (Faux valide) : : Un attaquant peut tromper une paire d'agents en leur faisant croire qu'une paire de candidats est valide, alors qu'elle ne l'est pas. Cela peut amener un agent à poursuivre une session, mais ensuite à ne pas être en mesure de recevoir de média.

False Peer Reflexive Candidate (Faux candidat réflexif pair) : : Un attaquant peut amener un agent à découvrir un nouveau candidat réflexif pair, alors qu'il n'aurait pas dû. Cela peut être utilisé pour rediriger les flux multimédias vers une cible de déni de service (DoS) ou vers l'attaquant, à des fins d'écoute ou à d'autres fins.

False Valid on False Candidate (Faux valide sur un faux candidat) : : Un attaquant a déjà convaincu un agent qu'il existe un candidat avec une adresse qui ne route pas réellement vers cet agent (par exemple, en injectant un faux candidat réflexif pair ou un faux candidat réflexif serveur). Il doit alors lancer une attaque qui force les agents à croire que ce candidat est valide.

Si un attaquant peut provoquer un faux candidat réflexif pair ou un faux valide sur un faux candidat, il peut lancer n'importe quelle attaque décrite dans [RFC5389].

Pour forcer le résultat faux invalide, l'attaquant doit attendre que la vérification de connectivité de l'un des agents soit envoyée. Lorsqu'elle l'est, l'attaquant doit injecter une fausse réponse avec une réponse d'erreur irrécupérable, telle qu'un 400. Cependant, puisque le candidat est, en fait, valide, la requête d'origine peut atteindre l'agent pair et aboutir à une réponse de succès. L'attaquant doit forcer ce paquet ou sa réponse à être abandonné, par une attaque DoS, une perturbation du réseau de couche 2 ou une autre technique. S'il ne le fait pas, la réponse de succès atteindra également l'initiateur, l'alertant d'une attaque possible. Heureusement, cette attaque est complètement atténuée par le mécanisme d'accréditation à court terme STUN. L'attaquant doit injecter une fausse réponse, et pour que cette réponse soit traitée, l'attaquant a besoin du mot de passe. Si la signalisation offre/réponse est sécurisée, l'attaquant n'aura pas le mot de passe et sa réponse sera rejetée.

Forcer le résultat faux valide fonctionne de manière similaire. L'agent doit attendre la requête Binding de chaque agent et injecter une fausse réponse de succès. L'attaquant n'aura pas besoin de s'inquiéter de perturber la réponse réelle puisque, si le candidat n'est pas valide, il ne serait probablement pas reçu de toute façon. Cependant, comme l'attaque faux invalide, cette attaque est atténuée par le mécanisme d'accréditation à court terme STUN en conjonction avec un échange offre/réponse sécurisé.

Forcer le résultat de faux candidat réflexif pair peut être fait soit avec de fausses requêtes ou réponses, soit avec des rejeux. Nous considérons d'abord le cas des fausses requêtes et réponses. Il nécessite que l'attaquant envoie une requête Binding à un agent avec une adresse IP et un port source pour le faux candidat. De plus, l'attaquant doit attendre une requête Binding de l'autre agent et générer une fausse réponse avec un attribut XOR-MAPPED-ADDRESS contenant le faux candidat. Comme les autres attaques décrites ici, cette attaque est atténuée par les mécanismes d'intégrité des messages STUN et les échanges offre/réponse sécurisés.

Forcer le résultat de faux candidat réflexif pair avec des rejeux de paquets est différent. L'attaquant attend que l'un des agents envoie une vérification. Il intercepte cette requête et la rejoue vers l'autre agent avec une fausse adresse IP source. Il doit également empêcher la requête d'origine d'atteindre l'agent distant, soit en lançant une attaque DoS pour provoquer l'abandon du paquet, soit en le forçant à être abandonné à l'aide de mécanismes de couche 2. Le paquet rejoué est reçu par l'autre agent et accepté, car la vérification d'intégrité réussit (la vérification d'intégrité ne peut pas et ne couvre pas l'adresse IP et le port source). Il est ensuite répondu. Cette réponse contiendra une XOR-MAPPED-ADDRESS avec le faux candidat et sera envoyée à ce faux candidat. L'attaquant doit alors la recevoir et la relayer vers l'initiateur.

L'autre agent lancera alors une vérification de connectivité vers ce faux candidat. Cette validation doit réussir. Cela nécessite que l'attaquant force un faux valide sur un faux candidat. L'injection de fausses requêtes ou réponses pour atteindre cet objectif est empêchée à l'aide des mécanismes d'intégrité de STUN et de l'échange offre/réponse. Ainsi, cette attaque ne peut être lancée que par des rejeux. Pour ce faire, l'attaquant doit intercepter la vérification vers ce faux candidat et la rejouer vers l'autre agent. Ensuite, il doit intercepter la réponse et la rejouer également.

Cette attaque est très difficile à lancer à moins que l'attaquant ne soit identifié par le faux candidat. C'est parce qu'elle nécessite que l'attaquant intercepte et rejoue des paquets envoyés par deux hôtes différents. Si les deux agents sont sur des réseaux différents (par exemple, sur l'Internet public), cette attaque peut être difficile à coordonner, car elle doit se produire contre deux points de terminaison différents sur différentes parties du réseau en même temps.

Si l'attaquant lui-même est identifié par le faux candidat, l'attaque est plus facile à coordonner. Cependant, si SRTP est utilisé [RFC3711], l'attaquant ne pourra pas lire les paquets multimédias, mais ne pourra que les rejeter, désactivant ainsi le flux multimédia pour l'appel. Cependant, cette attaque nécessite que l'agent perturbe les paquets afin d'empêcher la vérification de connectivité d'atteindre la cible. Dans ce cas, si l'objectif est de perturber le flux multimédia, il est beaucoup plus facile de le perturber simplement avec le même mécanisme, plutôt que d'attaquer ICE.

18.2. Attacks on Server Reflexive Address Gathering (Attaques sur la collecte d'adresses réflexives serveur)

Les points de terminaison ICE utilisent des requêtes STUN Binding pour collecter des candidats réflexifs serveur à partir d'un serveur STUN. Ces requêtes ne sont authentifiées d'aucune manière. Par conséquent, il existe de nombreuses techniques qu'un attaquant peut employer pour fournir au client un faux candidat réflexif serveur :

• Un attaquant peut compromettre le DNS, provoquant le retour d'une adresse de serveur STUN malveillante par les requêtes DNS. Ce serveur peut fournir au client de faux candidats réflexifs serveur. Cette attaque est atténuée par la sécurité DNS, bien que DNS-SEC ne soit pas nécessaire pour y remédier.

• Un attaquant qui peut observer les messages STUN (comme un attaquant sur un segment de réseau partagé, comme le WiFi) peut injecter une fausse réponse qui est valide et sera acceptée par le client.

• Un attaquant peut compromettre un serveur STUN au moyen d'un virus et lui faire envoyer des réponses avec des adresses mappées incorrectes.

Une fausse adresse mappée apprise par ces attaques sera utilisée comme candidat réflexif serveur dans l'échange ICE. Pour que ce candidat soit réellement utilisé pour le média, l'attaquant doit également attaquer les vérifications de connectivité et, en particulier, forcer un faux valide sur un faux candidat. Cette attaque est très difficile à lancer si la fausse adresse identifie une quatrième partie (ni l'offrant, ni le répondeur, ni l'attaquant), car elle nécessite d'attaquer les vérifications générées par chaque agent dans la session, et est empêchée par SRTP si elle identifie l'attaquant lui-même.

Si l'attaquant choisit de ne pas attaquer les vérifications de connectivité, le pire qu'il puisse faire est d'empêcher l'utilisation du candidat réflexif serveur. Cependant, si l'agent pair a au moins un candidat accessible par l'agent attaqué, les vérifications de connectivité STUN elles-mêmes fourniront un candidat réflexif pair qui peut être utilisé pour l'échange de médias. Les candidats réflexifs pairs sont généralement préférés aux candidats réflexifs serveur. À ce titre, une attaque uniquement sur la collecte d'adresses STUN n'aura normalement aucun impact sur une session.

18.3. Attacks on Relayed Candidate Gathering (Attaques sur la collecte de candidats relayés)

Un attaquant peut tenter de perturber la collecte de candidats relayés, forçant le client à croire qu'il a un faux candidat relayé. Les échanges avec le serveur TURN sont authentifiés à l'aide d'un identifiant à long terme. Par conséquent, l'injection de fausses réponses ou requêtes ne fonctionnera pas. De plus, contrairement aux requêtes Binding, les requêtes Allocate ne sont pas sensibles aux attaques par rejeu avec des adresses IP et des ports source modifiés, car l'adresse IP et le port source ne sont pas utilisés pour fournir au client son candidat relayé.

Cependant, les serveurs TURN sont sensibles aux attaques DNS ou aux virus visant le serveur TURN, dans le but de le transformer en zombie ou en serveur malveillant. Ces attaques peuvent être atténuées par DNS-SEC et par une bonne sécurité des boîtiers et des logiciels sur les serveurs TURN.

Même si un attaquant a amené le client à croire en un faux candidat relayé, les vérifications de connectivité font qu'un tel candidat n'est utilisé que si elles réussissent. Ainsi, un attaquant doit lancer un faux valide sur un faux candidat, comme ci-dessus, ce qui est une attaque très difficile à coordonner.

18.4. Attacks on the Offer/Answer Exchanges (Attaques sur les échanges offre/réponse)

Un attaquant qui peut modifier ou perturber les échanges offre/réponse eux-mêmes peut facilement lancer diverses attaques avec ICE. Ils pourraient diriger les médias vers une cible d'une attaque DoS, ils pourraient s'insérer dans le flux multimédia, et ainsi de suite. Celles-ci sont similaires aux considérations générales de sécurité pour les échanges offre/réponse, et les considérations de sécurité de la RFC 3264 [RFC3264] s'appliquent. Celles-ci nécessitent des techniques d'intégrité et de chiffrement des messages pour les offres et les réponses, qui sont satisfaites par le mécanisme SIPS [RFC3261] lorsque SIP est utilisé. À ce titre, l'utilisation de SIPS avec ICE est RECOMMENDED.

18.5. Insider Attacks (Attaques d'initiés)

En plus des attaques où l'attaquant est un tiers essayant d'insérer de fausses offres, réponses ou messages stun, il existe plusieurs attaques possibles avec ICE lorsque l'attaquant est un participant authentifié et valide à l'échange ICE.

18.5.1. The Voice Hammer Attack (L'attaque Voice Hammer)

L'attaque Voice Hammer est une attaque par amplification. Dans cette attaque, l'attaquant initie des sessions vers d'autres agents et inclut malicieusement l'adresse IP et le port d'une cible DoS comme destination du trafic multimédia signalé dans le SDP. Cela provoque une amplification substantielle ; un seul échange offre/réponse peut créer un flux continu de paquets multimédias, éventuellement à des débits élevés (considérez les sources vidéo). Cette attaque n'est pas spécifique à ICE, mais ICE peut aider à fournir une remédiation.

Plus précisément, si ICE est utilisé, l'agent recevant le SDP malveillant effectuera d'abord des vérifications de connectivité vers la cible du média avant d'y envoyer le média. Si cette cible est un hôte tiers, les vérifications ne réussiront pas et le média ne sera jamais envoyé.

Malheureusement, ICE n'aide pas s'il n'est pas utilisé, auquel cas un attaquant pourrait simplement envoyer l'offre sans les paramètres ICE. Cependant, dans les environnements où l'ensemble des clients est connu et limité à ceux qui prennent en charge ICE, le serveur peut rejeter toutes les offres ou réponses qui n'indiquent pas la prise en charge d'ICE.

18.5.2. STUN Amplification Attack (Attaque par amplification STUN)

L'attaque par amplification STUN est similaire au Voice Hammer. Cependant, au lieu que les paquets vocaux soient dirigés vers la cible, les vérifications de connectivité STUN sont dirigées vers la cible. L'attaquant envoie une offre avec un grand nombre de candidats, disons 50. Le répondeur reçoit l'offre et commence ses vérifications, qui sont dirigées vers la cible et, par conséquent, ne génèrent jamais de réponse. Le répondeur commencera une nouvelle vérification de connectivité toutes les Ta ms (disons, Ta=20ms). Cependant, les temporisateurs de retransmission sont définis sur un grand nombre en raison du grand nombre de candidats. En conséquence, les paquets seront envoyés à un intervalle d'un toutes les Ta millisecondes, puis avec des intervalles croissants par la suite. Ainsi, STUN n'enverra pas de paquets à un débit plus rapide que le média ne serait envoyé, et les paquets STUN ne persistent que brièvement, jusqu'à ce qu'ICE échoue pour la session. Néanmoins, il s'agit d'un mécanisme d'amplification.

Il est impossible d'éliminer l'amplification, mais le volume peut être réduit grâce à diverses heuristiques. Les agents SHOULD limiter le nombre total de vérifications de connectivité qu'ils effectuent à 100. De plus, les agents MAY limiter le nombre de candidats qu'ils accepteront dans une offre ou une réponse.

Fréquemment, les protocoles qui souhaitent éviter ce type d'attaques forcent l'initiateur à attendre une réponse avant d'envoyer le message suivant. Cependant, dans le cas d'ICE, ce n'est pas possible. Il n'est pas possible de différencier les deux cas suivants :

• Il n'y a pas eu de réponse parce que l'initiateur est utilisé pour lancer une attaque DoS contre une cible sans méfiance qui ne répondra pas.

• Il n'y a pas eu de réponse car l'adresse IP et le port ne sont pas accessibles par l'initiateur.

Dans le second cas, une autre vérification doit être envoyée à la prochaine occasion, tandis que dans le premier cas, aucune autre vérification ne doit être envoyée.

18.6. Interactions with Application Layer Gateways and SIP (Interactions avec les passerelles de couche application et SIP)

Les passerelles de couche application (ALG) sont des fonctions présentes dans un dispositif NAT qui inspectent le contenu des paquets et les modifient, afin de faciliter la traversée NAT pour les protocoles d'application. Les contrôleurs de session en périphérie (SBC) sont des cousins proches des ALG, mais sont moins transparents car ils existent réellement en tant qu'intermédiaires SIP de couche application. ICE a des interactions avec les SBC et les ALG.

Si un ALG est compatible SIP mais pas compatible ICE, ICE fonctionnera à travers lui tant que l'ALG modifie correctement le SDP. Une implémentation ALG correcte se comporte comme suit :

• L'ALG ne modifie pas les lignes m et c ou l'attribut rtcp s'ils contiennent des adresses externes.

• Si les lignes m et c contiennent des adresses internes, la modification dépend de l'état de l'ALG :

  Si l'ALG a déjà une liaison établie qui mappe un port externe à une adresse IP interne et un port correspondant aux valeurs dans les lignes m et c ou l'attribut rtcp, l'ALG utilise cette liaison au lieu d'en créer une nouvelle.

  Si l'ALG n'a pas déjà de liaison, il en crée une nouvelle et modifie le SDP, réécrivant les lignes m et c et l'attribut rtcp.

Malheureusement, de nombreux ALG sont connus pour mal fonctionner dans ces cas limites. ICE n'essaie pas de contourner les ALG défectueux, car cela dépasse le cadre de ses fonctionnalités. ICE peut aider à diagnostiquer ces conditions, qui se manifestent souvent par une inadéquation entre l'ensemble des candidats et les lignes m et c et les attributs rtcp. L'attribut ice-mismatch est utilisé à cette fin.

ICE fonctionne mieux via les ALG lorsque la signalisation est exécutée sur TLS. Cela empêche l'ALG de manipuler les messages SDP et d'interférer avec le fonctionnement d'ICE. Les implémentations qui devraient être déployées derrière des ALG SHOULD prévoir le transport TLS du SDP.

Si un SBC est compatible SIP mais pas compatible ICE, le résultat dépend du comportement du SBC. S'il agit comme un agent utilisateur dos à dos (B2BUA) approprié, le SBC supprimera tous les attributs SDP qu'il ne comprend pas, y compris les attributs ICE. Par conséquent, l'appel apparaîtra aux deux points de terminaison comme si l'autre partie ne prenait pas en charge ICE. Cela entraînera la désactivation d'ICE et le flux multimédia via le SBC, si le SBC l'a demandé. Si, toutefois, le SBC transmet les attributs ICE sans modification, mais modifie la destination par défaut pour les médias (contenue dans les lignes m et c et l'attribut rtcp), cela sera détecté comme une incompatibilité ICE et le traitement ICE est abandonné pour l'appel. Il est en dehors du cadre d'ICE d'agir comme un outil pour "contourner" les SBC. S'il en existe un, ICE ne sera pas utilisé et les techniques SBC prévalent.