Making network protocols go crazy - Mot-clé - firewall 2016-03-31T08:13:27+02:00 gr urn:md5:823289cecb88b10a72ab37a35928e25d Dotclear Qu'est-ce que l'attaque "Off-Path TCP Sequence Number Inference" urn:md5:14dd8cbb799c31f7b003e24821395a5e 2012-07-12T14:20:00+02:00 2012-09-12T16:45:17+02:00 gr Vulnérabilité firewallprotocoletcp <p>Je suis récemment tombé sur un papier intitulé <em>Off-Path TCP Sequence Number Inference Attack - How Firewall Middleboxes Reduce Security</em> [1]. Je ne connaissais pas la classification <em>Off-path</em>, ou littéralement, <em>hors du chemin</em>. Du coup, j'ai regardé de plus près le contenu de celui-ci.</p> <p>[1] <a href="http://www.protocol-hacking.org/post/2012/07/12/" hreflang="en">http://web.eecs.umich.edu/~zhiyunq/pub/oakland12_TCP_sequence_number_inference.pdf</a></p> <p>Ce papier propose une nouvelle attaque pour injecter un contenu dans une session <em>TCP</em>, depuis le coté client (en mode non-privilégié). La faute serait sur les <em>middle-boxes</em>, telles que nos chères modems ADSL, par exemple, ou autres firewalls <em>NAT</em>ant. Plus précisémment, celles faisant du suivi de session en se basant sur l' <em>ISN</em> (<em>Initial Sequence Number</em>) de <em>TCP</em>. C'est ici que serait la faille, ce numéro pourrait fuire à cause d'une fuite d'information accessible en <em>off-path</em>.</p> <p>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.</p> <p>Qu'est-ce que l' <em>off-path</em>&nbsp;? C'est différent d'un <em>man-in-the-middle</em> dans le sens ou l'écoute se fait à coté de la communication. Ici, l' <em>off-path</em> se passe sur le poste client, via un malware. Par exemple, les informations IP/ports se trouvent en utilisant la commande <em>netstat</em>. Ensuite, un <em>side-channel</em> permet de découvrir l' <em>ISN</em> possible. Par l'envoi de segments <em>TCP</em> depuis l'extérieur (adresse IP spoofée) avec un <em>TTL</em> ajusté pour émettre un message d'erreur, et par la consultation des statistiques via le <em>/proc filesystem</em> en local, il est possible de savoir si le segment TCP est passé au travers du firewall (ou non). Si il est passé, l' <em>ISN</em> choisi est autorisé par le <em>firewall</em>. Toutes les infos en mains, l'injection dans une session existante est réalisable. Bon, après, il faut avoir le bon <em>timing</em>, mais des propositions concrêtes sont faites dans le papier [1] que je vous invite à lire.</p> <p>Plus techniquement, un <em>firewall</em> peut avoir plusieurs politiques pour accepter un segment TCP <em>out-of-order</em>, c'est à dire accepter s'il fait bien partie d'une session établie. En gros, l' <em>ISN</em> est dans la fenêtre (<em>TCP window</em>) ou non. Mais pour connaitre cette fenêtre, le <em>firewall</em> 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 <em>firewall</em>s 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' <em>ISN</em>, je vous invite à lire le papier.</p> <p>En gros, tous les dispositifs se reposant sur le suivi de session utilisant l' <em>ISN</em> 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 <em>TCP</em> ;) genre installer un <em>plugin</em> navigateur Web pour avoir un accès lecture/écriture au contenu.</p>