+++ to secure your transactions use the Bitcoin Mixer Service +++

Groupe de travail Réseau	S. Bellovin, AT&T Research
Request for Comments : 1948	mai 1996
Catégorie : Information	Traduction Claude Brière de L’Isle

Défense contre les attaques de numéro de séquence

Statut du présent mémo

Le présent mémo fournit des informations pour la communauté de l’Internet. Le présent mémo ne spécifie aucune sorte de norme de l’Internet. Sa distribution n’est soumise à aucune restriction.

Résumé

Les attaques de surveillance du trafic IP fondées sur le chapardage du numéro de séquence sont devenues une menace sérieuse sur l’Internet (avis du CERT CA-95:01). Bien qu’une authentification cryptographique généralisée soit la bonne réponse, on propose aux mises en œuvre de TCP une modification simple qui devrait être une barrière très substantielle contre la vague d’attaques actuelle.

Généralités et motivations

En 1985, Morris [1] a décrit une forme d’attaque fondée sur la prévision des numéros de séquence que TCP [2] va utiliser pour les nouvelles connexions. En bref, l’attaquant bâillonne un hôte de confiance pour la cible, usurpe l’adresse IP de l’hôte de confiance lorsqu’il parle avec la cible, et achève la prise de contact à trois sur la base de sa prévision du prochain numéro de séquence initial à utiliser. Une connexion ordinaire avec la cible est utilisée pour rassembler les informations d’état de numéro de séquence. Cette séquence entière, couplée à l’authentification fondée sur l’adresse, permet à l’attaquant d’exécuter des commandes sur l’hôte cible.

Il est clair que la solution appropriée est l’authentification cryptographique [3,4]. Mais il s’écoulera encore assez longtemps avant qu’elle soit développée. Il a donc été nécessaire pour de nombreux sites de restreindre l’utilisation des protocoles qui s’appuient sur l’authentification fondée sur l’adresse, tels que rlogin et rsh. Malheureusement, la fréquence des attaques de "renifleurs" – espionnage du réseau (avis du CERT CA-94:01) -- a aussi rendu le TELNET [5] ordinaire très dangereux. L’Internet est donc dépourvu d’un mécanisme sûr et de confiance pour la connexion à distance.

Nous proposons un changement simple aux mises en œuvre de TCP, changement qui va bloquer la plupart des attaques de prévision de numéro de séquence. Plus précisément, de telles attaques ne resteront possibles que si et seulement si le mauvais garçon a déjà la capacité de lancer des attaques encore plus dévastatrices.

Détails de l’attaque

Afin de comprendre le cas particulier de la prévision de numéro de séquence, on doit examiner la prise de contact à trois utilisée dans la séquence d’ouverture de TCP [2]. Supposons qu’une machine client A veuille parler au serveur rsh B. Elle envoie le message suivant :

A→B : SYN, ISNa

C’est à dire qu’elle envoie un paquet avec le bit SYN ("synchroniser le numéro de séquence") établi (mis à un) et un numéro de séquence initial ISNa.

B répond par

B→A : SYN, ISNb, ACK(ISNa)

En plus de l’envoi de son propre numéro de séquence initial, il accuse réception de celui de A. Noter que la valeur numérique réelle ISNa doit apparaître dans le message.

A conclut la prise de contact en envoyant

A→B : ACK(ISNb)

Les numéros de séquence initiaux sont destinés à être plus ou moins aléatoires. Plus précisément, la RFC 793 spécifie que le compteur de 32 bits soit incrémenté de 1 dans la position de plus faible poids environ toutes les 4 microsecondes. Au lieu de cela les noyaux dérivés de Berkeley l’incrémentent d’une constante toutes les secondes, et d’une autre constante pour chaque nouvelle connexion. Et donc, si vous ouvrez une connexion avec une machine, vous savez avec un très fort degré de confiance quel numéro de séquence elle va utiliser pour sa prochaine connexion. Et c’est là que repose le nœud de l’attaque.

L’attaquant X ouvre d’abord une connexion réelle avec sa cible B -- disons, sur l’accès messagerie ou l’accès d’écho TCP. Cela donne ISNb. Il se fait ensuite passer pour A et envoie

Ax→B : SYN, ISNx

où "Ax" note un paquet envoyé par X prétendant être A.

La réponse de B au SYN original (si l’on peut dire) de X

B→A : SYN, ISNb', ACK(ISNx)

va au A légitime, sur lequel on n’en dira pas plus. X ne verra jamais ce message mais peut alors envoyer

Ax→B : ACK(ISNb')

en utilisant la valeur prédite pour ISNb'. Si la prévision est juste – et elle le sera habituellement – le serveur rsh de B pensera qu’il a une connexion légitime avec A, alors qu’en fait c’est X qui envoie les paquets. X ne peut pas voir le résultat de cette session, mais il peut exécuter des commandes à peu près comme n’importe quel utilisateur – et dans ce cas, le jeu est fini et c’est X qui a gagné.

Il y a ici une difficulté mineure. Si A voit le message de B, il va réaliser que B accuse réception de quelque chose qu’il n’a jamais envoyé, et va envoyer un paquet RST en réponse pour supprimer la connexion. Il y a divers moyens pour empêcher cela ; le plus facile est d’attendre que le vrai A soit terrassé (éventuellement par suite d’une action hostile, bien sûr). Dans la pratique, X peut bâillonner A en exploitant une erreur de mise en œuvre très commune ; c’est ce qui est décrit maintenant.

Le dilemme

Le choix des numéros de séquence initiaux pour une connexion n’est pas aléatoire. Ou plutôt, il doit être choisi de façon à minimiser la probabilité que de vieux paquets périmés soient acceptés au moyen de réapparitions sur la même connexion [6, Appendice A]. De plus, les mises en œuvre de TCP dérivées de 4.2BSD contiennent un code particulier pour traiter de telles réapparitions lorsque l’extrémité serveur de la connexion originale est toujours dans l’état TIMEWAIT [7, p. 945]. En conséquence, la simple randomisation, telle que suggérée en [8], ne fonctionnera pas bien.

Mais les paquets dupliqués, et donc les restrictions sur le numéro de séquence initial pour les réapparitions, sont spécifiques des connexions individuelles. C’est-à-dire qu’il n’y a pas de connexion, syntaxique ou sémantique, entre les numéros de séquence utilisés pour ceux connexions différentes. On peut empêcher les attaques de prévision de numéro de séquence en donnant à chaque connexion – c’est à dire à chaque quadruplet <localhost, localport, remotehost, remoteport> (hôte local, hôte distant, accès local, accès distant) -- un espace de numéro de séquence séparé. Au sein de chaque espace, le numéro de séquence initial est incrémenté conformément à [2] ; cependant, il n’y a pas de relations évidentes entre la numérotation dans les différents espaces.

La façon évidente de faire cela est de maintenir l’état des connexions mortes, et la façon la plus facile de le faire est de changer le diagramme de transition d’état de TCP de façon que les deux extrémités de toutes les connexions passent à l’état TIMEWAIT. Cela marcherait, mais c’est inélégant et cela consomme de l’espace mémoire. Au lieu de cela, on utilise le temporisateur M de 4 microsecondes actuel et on règle

ISN = M + F(localhost, localport, remotehost, remoteport).

Il est vital que F ne puisse pas être calculé de l’extérieur, car un attaquant pourrait toujours prévoir les numéros de séquence à partir du numéro de séquence initial utilisé pour quelque autre connexion. On suggère donc que F soit une fonction de hachage cryptographique de l’identifiant de connexion et de quelques données secrètes. MD5 [9] est un bon choix, car le code est largement disponible. Les données secrètes peuvent être un vrai nombre aléatoire [10], ou elles peuvent être la combinaison d’un secret particulier à l’hôte et de l’heure d’amorçage de la machine. L’heure d’amorçage est incluse pour assurer que le secret est changé à chaque fois. D’autres données, telles que l’adresse IP de l’hôte et son nom, peuvent aussi bien être incluses dans le hachage ; cela facilite l’administration en permettant à un réseau de stations de travail de partager les mêmes données secrètes tout en leur donnant quand même des espaces de numéro de séquence séparés. Notre recommandation, en fait, est d’utiliser ensemble ces trois éléments : un nombre aussi aléatoire que peut en générer le matériel, une phrase de passe installée par l’administration du site, et l’adresse IP de la machine. Cela permet un choix local sur le niveau de sécurisation du secret.

Noter que le secret ne peut pas être changé facilement sur une machine active. Le faire changerait les numéros de séquence initiaux utilisés pour les connexions réincarnées ; pour conserver une certaine sécurité, même les connexions mortes doivent être conservées ou gardées pendant un temps d’observation de deux durées de vie de segment au maximum après un tel changement.

Une erreur courante de TCP

Comme mentionné plus haut, les attaques qui utilisent la prévision de numéro de séquence doivent "bâillonner" d’abord la machine de confiance. Bien qu’un certain nombre de stratégies soient possibles, la plupart des attaques détectées jusqu’à présent s’appuient sur des erreurs de mise en œuvre.

Lorsque les paquets SYN sont reçus pour une connexion, le système qui reçoit crée un nouveau TCB dans l’état SYN-RCVD. Pour éviter une surconsommation de ressources, les systèmes dérivés de 4.2BSD ne permettent qu’un nombre limité de TCB dans cet état par connexion. Une fois cette limite atteinte, les paquets SYN ultérieurs pour de nouvelles connexions sont éliminés ; on suppose que le client les retransmettra en tant que de besoin.

Lorsqu’un paquet est reçu, la première chose qui doit être faite est de chercher le TCB pour cette connexion. Si aucun TCB n’est trouvé, le noyau recherche un TCB "générique" utilisé par les serveurs pour accepter des connexions à partir de tous les clients. Malheureusement, dans beaucoup de noyaux, ce code est invoqué pour tous les paquets entrants, et non pas seulement pour les paquets SYN initiaux. Si la file d’attente SYN-RCVD est pleine pour le TCB générique, tout nouveau paquet ne spécifiant que cet hôte et ce numéro d’accès sera éliminé, même si ce n’est pas un paquet SYN.

Pour bâillonner un hôte, l’attaquant envoie alors quelques douzaines de paquets SYN à l’accès rlogin à partir de différents numéros d’accès sur une machine non existante. Cela remplit la file d’attente de SYN-RCVD, alors que les paquets SYN+ACK sortent dans le baquet binaire. L’attaque contre la machine cible paraît alors venir de l’accès rlogin sur la machine de confiance. Les réponses -- les SYN+ACK provenant de la cible –seront perçues comme des paquets qui appartiennent à une file d’attente complète et seront éliminés en silence. Cela pourrait être évité si le code de file d’attente complète vérifiait le bit ACK, qui ne peut pas légalement être établi sur des demandes ouvertes légitimes. Si il est mis, RST devrait être envoyé en réponse.

Considérations sur la sécurité

De bons numéros de séquence ne peuvent remplacer l’authentification cryptographique. Au mieux, c’est un palliatif.

Un espion qui peut observer les messages d’initialisation d’une connexion peut déterminer son état de numéro de séquence, et peut encore être capable de lancer des attaques de prévision de numéro de séquence en se faisant passer pour cette connexion. Cependant, un tel espion peut aussi capturer des connexions existantes [11], et donc la menace supplémentaire n’est pas si importante. Ceci étant, comme le décalage entre une fausse connexion et une connexion réelle donnée sera plus ou moins constant pour la durée de vie du secret, il est important de s’assurer que des attaquants ne peuvent jamais capturer de tels paquets. Les attaques typiques qui pourraient les découvrir sont aussi bien l’espionnage que les diverses attaques sur l’acheminement exposées en [8].

Si des nombres aléatoires sont utilisés comme seule source du secret, ils DOIVENT être choisis conformément aux recommandations données en [10].

Remerciements

Matt Blaze et Jim Ellis ont fourni plusieurs idées cruciales pour cette RFC. Frank Kastenholz a contribué au présent mémo par des commentaires constructifs.

Références

[1] R.T. Morris, "A Weakness in the 4.2BSD UNIX TCP/IP Software", CSTR 117, 1985, AT&T Bell Laboratories, Murray Hill, NJ.

[2] J. Postel, "Protocole de contrôle de transmission", STD 7, RFC 793, septembre 1981.

[3] J. Kohl et C. Neuman, "Le service d’authentification de réseau Kerberos (V5)", RFC 1510, septembre 1993.

[4] R. Atkinson, "Architecture de sécurité pour le protocole Internet", RFC 1825, août 1995.

[5] J. Postel et J. Reynolds, "Spécification du protocole Telnet", STD 8, RFC 854, mai 1983.

[6] V. Jacobson, R. Braden et L. Zhang, "Extension TCP pour voies à grande vitesse", RFC 1885, octobre 1990.

[7] G.R. Wright, W. R. Stevens, "TCP/IP Illustrated, Volume 2", 1995. Addison-Wesley.

[8] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite", avril 1989, Computer Communications Review, vol. 19, no. 2, pp. 32-48.

[9] R. Rivest, "L’algorithme de résumé de message MD5", RFC 1321, avril 1992.

[10] D. Eastlake, S. Crocker et J. Schiller, "Recommandations d’aléa pour la sécurité", RFC 1750, décembre 1994.

[11] L. Joncheray, "A Simple Active Attack Against TCP, 1995, Proc. Fifth Usenix UNIX Security Symposium.

Adresse de l’auteur

Steven M. Bellovin
AT&T Research
600 Mountain Avenue
Murray Hill, NJ 07974
Téléphone : (908) 582-5886
mél : smb@research.att.com