OW-001-tac_plus, révision 2 Sortie : 30 Mai 2000 Mise à jour : 10 Juillet 2000 (Note du traducteur : traduction achevée le 07 mai 2001) Une Analyse du Protocole TACACS+ et de ses Mises en Oeuvre ---------------------------------------------------------- Cet avis présente une analyse de plusieurs vulnérabilités dans le protocole TACACS+. Malheureusement, seulement quelques unes des vulnérabilités peuvent être fixées sans casser l'interopérabilité. Ainsi, le but principal de cet avis est d'identifier les faiblesses, pour permettre qu'une décision réfléchie soit prise sur la quantité de confiance à placer dans le chiffrement offert par TACACS+ -- sur la base du cas par cas. Citant le draft RFC, "TACACS+ fournit du contrôle d'accès pour les routeurs, les accès réseaux aux serveurs et d'autres périphériques informatisés en réseau via un ou plusieurs serveurs centralisés... TACACS+ améliore TACACS et XTACACS en séparant les fonctions d'authentification, d'autorisation et de comptabilité et en chiffrant tout le trafic entre les NAS et les démons... TACACS+ utilise TCP pour son transport." Une copie du draft RFC peut être obtenu à l'un des endroits suivants : ftp://ftpeng.cisco.com/pub/tacacs/tac-rfc.1.78.txt http://www.cisco.com/warp/public/459/tac-rfc.1.76.txt Vulnérabilités -------------- Les attaques décrites ici assument un attaquant avec un accès au réseau mais pas de connaissance de la clé de chiffrement, sauf spécifié autrement. Les deux premières vulnérabilités peuvent sembler évidentes à ceux familiers avec le protocole. Elles sont listées d'abord pour aider à simplifier la compréhension du reste de l'analyse, malgré leurs impacts relativement mineurs. 1. Manque de vérification d'intégrité. Impact : les enregistrements de comptabilité peuvent être altérés durant la transmission. Presqu'aucune vérification d'intégrité n'existe dans TACACS+. La seule vérification définie dans le draft RFC est de s'assurer que la somme des longueurs des composants corresponde à la taille totale du paquet. Combiné avec l'algorithme de chiffrement de flux basé sur MD5 utilisé pour chiffrer les paquets TACACS+, ceci laisse un attaquant avec un accès au réseau changer presque tous les bits dans le paquet (ce qui affecte le texte en clair de la même manière) sans que le changement soit détecté. En particulier, il est possible de faire des changements significatifs aux paquets de comptabilité, tel que modifier un elapsed_time (ndt : temps écoulé) de 9000 à 1000 avec le changement d'un bit. 2. Vulnérabilité aux attaques de rejeu. Impact : des enregistrement de comptabilité peuvent être produits, peut-être avec des champs task_id forgés pour éviter la détection. TACACS+ manque pratiquement de toute protection contre les attaques de rejeu. Le seul besoin est que les paquets aient un numéro de séquence correct. Puisque toutes les sessions TACACS+ commencent avec un numéro de séquence de 1 (non une vulnérabilité en soi), le serveur TACACS+ traitera toujours un paquet avec un seq_no (ndt : numéro de séquence) fixé à 1. Les paquets du milieux d'une session TACACS+ ne peuvent pas toujours être rejoués, puisque l'attaquant aurait besoin d'obtenir avec succès que la session soit d'abord au seq_no requis. Spécialement faciles à rejouer sont les sessions de comptabilité, qui consistent seulement en un seul paquet envoyé au serveur (avec un seq_no de 1). Évidemment, il est également possible de rejouer les paquets avec certains bits changés, tel que pour obtenir un task_id différent au cas où le système de facturation soit suffisamment malin pour vérifier les enregistrements dupliqués. Le fait que TACACS+ utilise TCP ne fournit pas de sécurité contre le rejeu, puisqu'une nouvelle connexion TCP peut être ouverte par un attaquant pour rejouer les sessions TACACS+ enregistrées. 3. Collisions forcées de session_id. Impact : le chiffrement de paquets réponse peut être compromis. A cause de son utilisation d'un algorithme de chiffrement de flux, la force du chiffrement de TACACS+ dépend fortement d'un unique session_id pour chaque session. Si deux paquets différents arrivent à avoir le même session_id et le même seq_no, ils deviennent tous deux vulnérables à une attaque d'analyse de fréquence simple. De plus, s'il y a du texte en clair connu dans un des paquets, les parties correspondantes de l'autre peuvent être déchiffrées trivialement. Malheureusement, il est possible d'obtenir du serveur TACACS+ de chiffrer un paquet réponse en utilisant un session_id de notre choix. Combiné avec notre capacité de rejouer des paquets envoyés à un serveur TACACS+, ceci nous laisse compromettre le chiffrement de presque tous les paquets sur le chemin retour. Ceci reste vrai pour presque tous les paquets avec un seq_no de 2 (le premier paquet réponse dans une session), comme nous sommes toujours capables d'au moins faire regarder notre paquet rejoué initial (seq_no de 1) au serveur et y répondre. Afin de s'assurer que la seconde réponse est différente de l'originale, nous pouvons changer quelques bits dans le paquet requête, ou vraiment tout dans son entête en clair, avant de rejouer. Heureusement, les mots de passe sont typiquement contenus seulement dans les paquets voyageant vers le serveur (qui ne sont pas affectés par cette vulnérabilité) -- pas sur le chemin retour. Il y a, cependant, des exceptions à cela : les mots de passe pour les PAP sortants doivent être envoyés vers le côté distant du lien PPP; de même, les mots de passe pour les CHAP entrants étaient usuellement donnés au NAS (dans la minor_version 0 du protocole, maintenant déprécié). Des informations autres que les mots de passe utilisateurs peuvent être également de quelque utilité pour un attaquant; ceci inclut les noms d'utilisateurs et les paires AV. 4. Le paradoxe des anniversaires et les session_id. Impact : étant données suffisamment de sessions, le chiffrement de beaucoup peut être compromis. Un autre problème avec les session_id est qu'ils sont trop petits pour être unique s'ils sont choisis aléatoirement (comme requis par le draft RFC), et il n'y a pas d'autre façon de les garder uniques au travers de plusieurs NAS et rechargements. A cause du paradoxe des anniversaires, nous pouvons espérer voir deux sessions différentes avec le même session_id si nous regardons environ 100.000 sessions TACACS+. Comme des sessions séparées sont utilisées pour l'authentification, l'autorisation, et la comptabilité, et comme plusieurs enregistrements de comptabilité sont envoyés par TACACS+ à différentes étapes de la session d'un utilisateur à un NAS, ceci peut correspondre à environ seulement 20.000 sessions de connexion à distance. Même pour un relativement petit ISP, nous pouvons espérer voir une correspondance en moins d'une journée. Si nous regardons pendant un mois, nous pouvons obtenir 1000 correspondances, ce qui devrait nous donner quelques centaines de mots de passe utilisateurs étant donnés la quantité de chance (c.-à-d., quels types de paquets obtiennent le même session_id) et de textes en clair connus (tels que les attributs nominaux) que nous pouvons raisonnablement espérer. 5. Manque de bourrage. Impact : les longueurs des mots de passe utilisateurs peuvent être déterminées. Le draft RFC précise que "il ne devrait pas y avoir de bourrage dans n'importe quel champ ou à la fin d'un paquet". Effectivement, les mises en oeuvre suivent ce besoin. L'implication en sécurité, cependant, est que les longueurs des champs de taille variable peuvent souvent être déterminées depuis les tailles des paquets -- un attaquant nécessite seulement une façon de trouver quels paquets contiennent les informations qu'il cherche. Cette tâche est simplifiée par le fait que les numéros de séquence et les types de paquets sont transmis en clair. Dans le cas de la détermination des longueurs des mots de passe, les noms d'utilisateurs peuvent être obtenus via finger vers le NAS ou des approches similaires. 6. fuite de contexte MD5. Impact : non pratique; dans des cas pathologiques, une partie du paquet peut être déchiffrée. Cette vulnérabilité a seulement valeur théorique quand elle est appliquée à TACACS+, et elle est incluse ici dans le but d'être complet, aussi bien que pour rappeler aux développeurs la façon dont les empreintes du style MD5 ne doivent pas être utilisées. Vous devez être familiers avec MD5 (RFC 1321) afin de comprendre cette courte description. Le corps des paquets TACACS+ est chiffré en lui appliquant un XOR avec une suite d'empreintes MD5 (chacune longue de 16 octets). Les deux premières empreintes (utilisées pour chiffrer les 32 premiers octets du corps du paquet) sont spécifiées ainsi dans le draft RFC : MD5_1 = MD5{session_id, key, version, seq_no} MD5_2 = MD5{session_id, key, version, seq_no, MD5_1} Maintenant, assumons ce scénario pathologique : -- la clé est longue de 49 octets; -- nous connaissons ou pouvons deviner les 16 premiers octets du corps du paquet; -- les 9 premiers octets de MD5_1 sont : 80 B8 01 00 00 00 00 00 00. (En pratique, cela prendrait environ 2**72 paquets jusqu'à ce que nous en voyons un avec les octets requis dans MD5_1. C'est clairement bien trop.) Comme nous avons les 16 octets de texte en clair, nous pouvons déterminer MD5_1 en entier (pas seulement les 9 octets que nous recherchons) depuis le paquet chiffré. Ce MD5_1 va correspondre au contexte MD5 normalement inconnu dans le calcul de MD5_2 (après traitement du premier bloc de 64 octets). Maintenant, MD5_2 devient seulement une fonction de MD5_1; nous n'avons plus besoin de connaître la clé afin de calculer MD5_2. Une fois que nous avons MD5_2, le décryptage des 16 octets suivants du corps du paquet est trivial. Une façon de rendre cette attaque impossible (et non juste infaisable) serait de définir MD5_1 comme ceci : MD5_0 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 MD5_1 = MD5{session_id, key, version, seq_no, MD5_0} 7. Dénis de service et/ou débordement des longueurs des corps des paquets. Impacts : dénis de service de serveurs et de clients TACACS+, intrusions potentielles. Contrairement aux autres problèmes discutés ici, ceci est un défaut de mise en oeuvre. Toutefois, l'erreur est assez "indispensable" pour que les deux mises en oeuvre vérifiées (le kit de développement TAC_PLUS non supporté vF4.0.3.alpha et Cisco IOS 11.3(9)T) se soient avérées être vulnérables. Un des champs dans l'entête en clair de 12 octets du paquet est la longueur du corps. La façon évidente de lire un paquet depuis la socket est de lire l'entête en premier, d'allouer la mémoire pour le corps, et alors de lire le corps avec un autre appel. L'erreur "indispensable" ici est de ne pas vérifier le bon sens du champ longueur avant d'allouer la mémoire. Ainsi, une attaque en déni de service sur un serveur TACACS+ est de le faire tomber à court de mémoire en lui envoyant un paquet avec une grande valeur dans le champs longueur. Selon la mise en oeuvre de malloc(3), il peut également être requis d'effectivement remplir la mémoire avec des données (ce qui requière du temps pour la transmission des données, mais qui est toujours trivial). Il est également indispensable pour les mises en oeuvre d'allouer de la mémoire pour l'entête et le corps du paquet, et de copier l'entête vers cette mémoire avant de lire le corps depuis la socket. L'erreur "indispensable" ici est de ne pas vérifier pour un débordement d'entier en calculant la taille mémoire totale à allouer. Dans tac_plus, ceci résulte dans la capacité de déborder le tampon avec jusqu'à 11 octets des données de l'entête de notre paquet. Ceci est habituellement sans mal, mais il peut exister des plate-formes où ce n'est pas le cas. Évidemment, ces deux attaques requièrent soit l'accès au réseau, soit la connaissance de la clé. La seule nécessité est la capacité de se connecter au serveur TACACS+. De plus il est au moins possible de faire mal conduire tac_plus en exploitant les deux premières vulnérabilités mentionnées ici, ensembles avec le manque de vérification de débordement d'entier dans le calcul de la somme des longueurs des composants du paquet pour la comparaison. Il est probable que d'autres attaques sur tac_plus et les OS sous-jacents sont possibles quand la clé de chiffrement est connue, mais celles-ci sont en dehors de la portés de cette analyse. Des attaques similaires sont possibles contre les clients; toutefois, elles requièrent soit l'accès au réseau, soit la capacité de faire de la prédiction aveugle de numéros de séquence TCP et de temps. Dans le cas de l'IOS Cisco, il est possible d'allouer toute la mémoire accessible pour la durée de la connexion TCP. Réparations ----------- Cisco a fixé les déni de service et débordement de tac_plus dans la version F4.0.4.alpha de leur kit de développement non-supporté. Vous pouvez télécharger cette version à : ftp://ftp-eng.cisco.com/pub/tacacs/ Cette vulnérabilité sera également fixée dans les versions 0.96 et ultérieures de tac+ia (un clone de tac_plus) Alternativement, vous pouvez appliquer ce simple patch à une version plus ancienne de tac_plus : --- tac_plus.F4.0.3.alpha.orig/packet.c Sat Apr 3 10:03:46 1999 +++ tac_plus.F4.0.3.alpha/packet.c Sun Nov 28 08:28:27 1999 @@ -446,6 +446,13 @@ /* get memory for the packet */ len = TAC_PLUS_HDR_SIZE + ntohl(hdr.datalength); + if ((ntohl(hdr.datalength) & ~0xffffUL) || + len < TAC_PLUS_HDR_SIZE || len > 0x10000) { + report(LOG_ERR, + "%s: Illegal data size: %lu\n", + session.peer, ntohl(hdr.datalength)); + return(NULL); + } pkt = (u_char *) tac_malloc(len); /* initialise the packet */ Recommandations --------------- Note : ceci sont des recommandations générales de sécurité sur la configuration de TACACS+ -- ils ne peuvent pas fixer quelques défauts inhérents au protocole discutés ci-dessus. 1. Appliquez du filtrage de paquets où c'est possible. Dans un cas simple, vous aurez tous les clients et serveurs TACACS+ dans votre réseau. Assurez vous que les serveurs sont accessibles seulement depuis votre réseau, et de façon préférée seulement par les adresses IP des clients (ceci peut nécessiter une combinaison de filtres sur les systèmes serveurs eux-mêmes et des filtres anti-spoofing sur vos routeurs externes). Le port par défaut du serveur TACACS+ est 49/tcp. 2. Choisissez des clés de chiffrement fortes. Les attaques déconnectées contre la clé de chiffrement sont possibles avec seulement un paquet collecté depuis le réseau, et exécutées bien plus vite que les attaques similaires contre les mots de passe Unix. Ainsi, une clé de chiffrement forte devrait être plus longue qu'un mot de passe utilisateur typique. Gardez à l'esprit que si la clé devient connue, d'autres attaques contre les systèmes serveurs et les clients TACACS+ deviennent possibles. 3. Évitez d'exécuter tac_plus en root. Malheureusement, la version F4.0.3.alpha possède quelques problèmes en s'exécutant en non-root, mais il supporte les définitions de TAC_PLUS_USERID et TAC_PLUS_GROUPID à la compilation. Assurez vous de ne pas avoir d'autres groupes supplémentaires quand vous lancez tac_plus, puisqu'il n'est pas suffisamment malin pour les abandonner. tac+ia-0.96 et ultérieurs auront l'option --enable-tacplus-username dans 'configure'. Crédits et informations de contact ---------------------------------- L'analyse a été effectuée par Solar Designer . J'aimerais remercier Dug Song d'avoir révisé cet avis et Damir Rajnovic de Cisco Systems PSIRT pour la prise en charge de ces vulnérabilités dans Cisco. Les version mises à jour de cet avis et des autres avis Openwall seront disponibles sur : http://www.openwall.com/advisories/ Note du traducteur : cette traduction française (non officielle) a été réalisée par Denis Ducamp et est disponible sur : http://www.groar.org/~ducamp/english.html#sec-trad