Roys Hills de la société "NTA Monitor" a publié fin juillet un avis de sécurité intitulé "Cisco VPN Concentrator IKE resource exhaustion DoS" traitant un problème dans la gestion des communications IKE au sein des équipements VPN de Cisco (concentrateurs VPN, gardes-barrière; routeurs avec accès VPN).

Cette vulnérabilité de type "déni de service" empêche toute nouvelle connexion VPN sur un équipement vulnérable pendant un laps de temps variable selon l'intensité de l'attaque.

Cisco mentionne que cette vulnérabilité est inhérente à la version 1 du protocole de gestion de clés IKE et qu'elle n'est pas due à une erreur d'implémentation de sa part.

Cette vulnérabilité nous semblant alors plus générique qu'elle ne pouvait paraître lors de sa description initiale, nous proposons de vous la présenter en détail dans cet article.

Nota : Si des solutions techniques sont prochainement proposées par les éditeurs d'équipements réseau, un avis Cert-IST sera vraisemblablement publié.

IKE version 1 ("Internet Key Exchange" – RFC 2409) est un protocole de gestion de clés utilisé par le protocole de chiffrement des communications réseau IPSec.

IKE assure une gestion sécurisée des clés cryptographiques et de leur échange. Les principales fonctions d'IKE sont :

• Authentification des deux extrémités IPSec
• Négociation des clés IPSec
• Choix du type de clé : clé à secret partagé/clé publique
• Négociation des "associations de sécurité" (SA –"Security Association") IPSec caractérisées par :
• Le choix d'un algorithme de chiffrement : DES, 3DES, AES
• Le choix d'un algorithme de signature ou "hash" : SHA, MD5
• Le choix du groupe "Diffie Hellman" : 1 768 bits, 2 1024 bits ou 5 1536 bits
• Le choix de la durée de vie de la SA
  

Pour mener à bien ces différentes fonctions, IKE utilise les protocoles et mécanismes suivants :

• ISAKMP ("Internet Security Association and Key Management Protocol" – RFC 2408)
• Cette RFC définit le cadre générique ("framework") de gestion des associations de sécurité. Elle peut s'appliquer à n'importe quel protocole implémentant de la sécurité : IPsec, TLS ("Transport Layer Security"), SSL ("Secure Socket Layer").
• Oakley/SKEME ("Secure Key Exchange Mechanism" – RFC 2412)
• Cette RFC définit le protocole d'échange de clés (de session)
• IPSEC DOI ("Domain Of Interpretation" – RFC 2407)
• Cette RFC spécifie les paramètres signalant que les échanges ISAKMP sont destinés à la mise en œuvre du protocole IPSec.

Vulnérabilité :

Il a été découvert que, lors de l'envoi de manière soutenue de paquets IKE légitimes ("Phase-1" du protocole IKE) vers un équipement VPN, les files d'attente dédiées aux connexions IKE saturaient assez rapidement. Une fois les files d'attente pleines, aucune nouvelle connexion IKE (et donc VPN) n'est possible durant un certain laps de temps (le temps que les files d'attente se vident).

Ce type d'attaque ne requiert aucune authentification vers le poste cible et peut même être effectuée de manière anonyme via l'utilisation de paquets IP "spoofés" (utilisation d'une adresse IP source erronée) car le trafic réseau utilisé est de type UDP (protocole facile à "spoofer").

Selon Cisco, cette vulnérabilité tendrait plus vers une problématique d'allocation de ressources (files d'attente) qu'à un problème d'implémentation de protocole. On peut faire dès lors le parallèle avec la problématique bien connue du "Syn flooding" sur la pile TCP/IP.

Solutions/palliatifs :

De part la nature de cette vulnérabilité, Cisco n'est pas en mesure de proposer une solution définitive pour protéger ses équipements VPN. Néanmoins l'éditeur propose une série de mesures de protection pour ce type d'équipements. Certaines de ces mesures pourraient également être appliquées à des solutions VPN d'autres éditeurs.

• Mise en place des listes de contrôle d'accès (ACL)

Cette solution consiste à définir les adresses IP qui peuvent légitimement accéder au service VPN de l'équipement. Bien que ce moyen de protection soit relativement efficace pour des configurations VPN de type "Site à Site" (où les deux extrémités sont aisément identifiables), il reste difficilement applicable pour des connexions VPN provenant de PC nomades (puisque l'adresse IP de ces PC est en général dynamique). De plus le fait que le l'attaquant puisse utiliser des adresses sources "spoofées" ne rend pas cette mesure totalement efficace.

• Contrôle du trafic réseau

Un outil de contrôle du trafic réseau (comme "Netflow") peut permettre de déceler (mais pas d'arrêter) les attaques en cours que subit un équipement VPN.

• Utilisation de fonctionnalités/outils spécifiques (ex : chez Cisco, CAR et CAC)

D'autres outils/fonctionnalités propres aux éditeurs peuvent être mis en œuvre pour minimiser ce type d'attaque.

A titre d'exemple la fonctionnalité CAR ("Commited Acces Rate") des équipements Cisco peut limiter le trafic IKE à destination d'un équipement VPN vulnérable en fonction de l'intensité du trafic réseau constatée.

Une autre fonctionnalité des équipements Cisco, CAC ("Call Admission Control"), permet aussi de protéger l'équipement contre une consommation excessive des ressources système afin d'éviter un "crash" du système.

Ces solutions spécifiques sont détaillées dans la réponse de Cisco mentionnée ci-dessous.

Cependant des discussions autour de ces solutions, et notamment des solutions CAR et CAC, ont montré les limites de ces dernières. En effet, si le but de ce type de solution est d'empêcher toute nouvelle connexion IKE à partir d'un certain seuil, l'attaquant en atteignant ce seuil empêche alors toute nouvelle connexion légitime. L'attaque par déni de service est donc toujours possible.

A notre sens, il n'existe donc pas de solution absolue pour ce problème, et il est fort probable que cette vulnérabilité affecte d'autres solutions VPN que celles de Cisco. Il nous semble donc souhaitable que les organisations mettant à place des solutions VPN :

• soient capables de détecter la saturation des accès VPN (de façon à détecter d'éventuelles attaques par saturation IKE),
• puissent continuer à fonctionner (au moins en mode dégradé) si les accès VPN deviennent indisponibles.

Pour plus d'informations :

• Avis de sécurité de NTA : http://www.nta-monitor.com/posts/2006/07/cisco-concentrator-dos.html
• Réponse de Cisco : http://www.cisco.com/warp/public/707/cisco-sr-20060726-ike.shtml
• RFC :
• IKE (version 1) : http://www.ietf.org/rfc/rfc2409.txt
• ISAKMP : http://www.ietf.org/rfc/rfc2408.txt
• Oakley/SKEME : http://www.ietf.org/rfc/rfc2412.txt
• IPSEC DOI : http://www.ietf.org/rfc/rfc2407.txt