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 <solar@false.com>. 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 <Denis.Ducamp@groar.org> et est disponible sur :
http://www.groar.org/~ducamp/english.html#sec-trad