Making network protocols go crazy

Aller au contenu | Aller au menu | Aller à la recherche

jeudi, juillet 12 2012

Qu'est-ce que l'attaque "Off-Path TCP Sequence Number Inference"

Je suis récemment tombé sur un papier intitulé Off-Path TCP Sequence Number Inference Attack - How Firewall Middleboxes Reduce Security [1]. Je ne connaissais pas la classification Off-path, ou littéralement, hors du chemin. Du coup, j'ai regardé de plus près le contenu de celui-ci.

[1] http://web.eecs.umich.edu/~zhiyunq/pub/oakland12_TCP_sequence_number_inference.pdf

Ce papier propose une nouvelle attaque pour injecter un contenu dans une session TCP, depuis le coté client (en mode non-privilégié). La faute serait sur les middle-boxes, telles que nos chères modems ADSL, par exemple, ou autres firewalls NATant. Plus précisémment, celles faisant du suivi de session en se basant sur l' ISN (Initial Sequence Number) de TCP. C'est ici que serait la faille, ce numéro pourrait fuire à cause d'une fuite d'information accessible en off-path.

Pour qu'une session TCP ne soit pas facilement détournable, un numéro de séquence est généré aléatoirement (sur 32-bits). Si ce numéro venait à être prédictible, ou à fuire, un attaquant pourrait insérer un contenu dans la session. Bien sur, l'attaquant devra également connaitre les adresses IP source et destination, ainsi que les ports TCP source et destination.

Qu'est-ce que l' off-path ? C'est différent d'un man-in-the-middle dans le sens ou l'écoute se fait à coté de la communication. Ici, l' off-path se passe sur le poste client, via un malware. Par exemple, les informations IP/ports se trouvent en utilisant la commande netstat. Ensuite, un side-channel permet de découvrir l' ISN possible. Par l'envoi de segments TCP depuis l'extérieur (adresse IP spoofée) avec un TTL ajusté pour émettre un message d'erreur, et par la consultation des statistiques via le /proc filesystem en local, il est possible de savoir si le segment TCP est passé au travers du firewall (ou non). Si il est passé, l' ISN choisi est autorisé par le firewall. Toutes les infos en mains, l'injection dans une session existante est réalisable. Bon, après, il faut avoir le bon timing, mais des propositions concrêtes sont faites dans le papier [1] que je vous invite à lire.

Plus techniquement, un firewall peut avoir plusieurs politiques pour accepter un segment TCP out-of-order, c'est à dire accepter s'il fait bien partie d'une session établie. En gros, l' ISN est dans la fenêtre (TCP window) ou non. Mais pour connaitre cette fenêtre, le firewall doit aussi garder cet état (tailles de la fenêtre initiale) depuis l'initialisation de la connexion TCP. Evidemment, pour des raisons de performance, ce n'est pas fait dans tous les produits. Du coup, certains firewalls utilisent une fenêtre hardcodée de 1 000 000 000 (1G), par exemple. Ca réduit l'espace des possibles. Il y a d'autres méthodes de suivi de l' ISN, je vous invite à lire le papier.

En gros, tous les dispositifs se reposant sur le suivi de session utilisant l' ISN sont vulnérables de manière plus ou moins critique. Mais la contrainte pour exploiter cette menace est de taille, un malware (non privilégié) doit être installé sur le poste de la victime. Je serai un malware, je ferai autre chose qu'injecter du contenu dans une session TCP ;) genre installer un plugin navigateur Web pour avoir un accès lecture/écriture au contenu.

mardi, octobre 14 2008

Déni de service universel dans TCP

Bon, difficile d'y échapper, surtout à quelques jours de la diffusion des détails. Ce billet fait suite à l'annonce vu sur le blog des chercheurs de chez Outpost24 relatant une nouvelle faille dans le design du protocole le plus utilisé dans l'Internet.

Cette faille, si l'on en croit le peu qui a pu filtrer, porte sur la gestion de la machine à état de TCP. En amenant cette machine dans un certain état, il serait possible de bloquer de l'allocation mémoire sur le système cible, finissant par saturer sa mémoire. Ou bien de saturer sa bande passante. Seulement 200 packets par secondes seraient même suffisant. Tous les systèmes d'exploitation seraient affectés. Well. Want to see that.

Du coup, je me suis (re)penché sur des techniques aussi vieilles que Naphta, en y apportant certaines modifications. Je ne vais pas faire un billet complet sur Naphta, mais en gros, Naphta amène la pile TCP/IP cible soit dans l'état ESTABLISHED, soit dans l'état FIN_WAIT_1 pour accomplir sa sombre tâche de destruction.

Une des dernières hypothèses sur le sujet était une évolution de Naphta, avec en plus l'envoi d'un payload applicatif vers la cible. En n'acquittant pas la réponse obtenue à une requête applicative, la cible va réémettre de nombreuses fois sa réponse, saturant un peu plus sa bande passante ainsi que sa mémoire (le tampon de réponse n'étant jamais libéré).

Faisons un rapide calcul. Soit une adresse IP ouvrant 60 000 connexions vers un serveur Apache. Imaginons que chacune de ces connexions entraîne l'émission d'une réponse HTTP d'environ 2 ko (chiffre arbitraire, mais je le prends comme moyenne acceptable). 60 000 x 2, soit 120 Mo. Outre le fait que je vais me prendre 120 Mo de trafic dans la tronche, la cible risque fort de garder 120 Mo de tampon alloués en mémoire. Et oui, puisque je n'acquitterai pas (au sens TCP ACK), la cible va garder ça dans un tampon, et réémettre à certains intervalles ce packet (et encore me balancer 120 Mo dans la tronche).

Vous allez me dire : la cible supportera certainement 120 Mo dans sa mémoire et sur sa bande passante. Par contre moi ... Maintenant, multipliez ce nombre par 10. 10 machines lançant cette attaque. En cherchant un peu, il est possible (hypothèse de ma part) que les chercheurs en question utilisent plusieurs adresses IP sources pour leur attaque. D'abord pour contourner la limitation de bande passante de l'attaquant, ensuite pour contourner la limitation des 60 000 (65 535, en fait) connexions correspondant au tuple adresseSource,portSource,adresseDestination,portDestination. Là, on atteint 1 Go pour 10 IP. 10 Go pour 100 IP. Ca à l'air pas mal.

Ainsi, j'ai développé un programme en utilisant mon framework préféré (Net::Frame) pour tester l'efficacité des ces attaques. Mais comme ce soir, j'ai la flemme de mettre ça au propre, ce sera peut-être l'objet d'un autre billet.