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.

hubiC, maintenant vraiment ubiquitous

2012-01-29T18:02:00+01:00

Votre serviteur s'est intéressé au cloud storage tel qu'implémenté par hubiC. Malheureusement, OVH ne fournit pas encore de binaire pour Linux. Eh oui, OVH a choisi de rendre disponible son espace de stockage uniquement via un client lourd. J'ai décidé d'analyser ce programme afin rendre ce cloud storage interopérable avec mon système (c'est légal).

Tout d'abord, certaines personnes arrivent à se connecter depuis Linux. Ces personnes possédaient un compte CloudNAS, le prédécesseur d'hubiC. Pour ces personnes, pas de problèmes. Pour les nouveaux arrivants (comme moi), le sytème de gestion des comptes d'OVH a changé. Un WAS (Web Application Service) est utilisé pour gérer les crédences d'hubiC. En analysant le programme Windows, je me suis aperçu que le client hubiC effectue 3 requêtes avant d'obtenir les informations qui serviront ensuite à la connexion WebDAV. Pour pouvoir se connecter, il est nécessaire d'avoir :

l'URL du WebDAV
le login du WebDAV
le mot de passe du WebDAV

Les 3 requêtes sus-mentionnées sont destinées au serveur ws.ovh.com et permettent d'obtenir ces trois informations indispensables à la connexion WebDAV. Sans plus tarder, voici ces requêtes (en mode raw), toutes à destination de ws.ovh.com en HTTPS :

Requête POST nasLogin :

'POST /cloudnas/r0/ws.dispatcher/nasLogin HTTP/1.1'."\r\n".
'Content-Type: application/x-www-form-urlencoded'."\r\n".
'User-Agent: hubiC/1.0.9 (Windows NT 6.1; fr_FR)'."\r\n".
'Content-Length: 126'."\r\n".
'Connection: Keep-Alive'."\r\n".
'Accept-Encoding: gzip'."\r\n".
'Accept-Language: fr-FR,en,*'."\r\n".
'Host: ws.ovh.com'."\r\n".
''."\r\n".
'session=&params=%7B%20%22email%22%20%3A%20%22<login>%22%2C%20%22password%2
2%20%3A%20%22<password>%22%20%7D'."\r\n".
"\r\n";

Requête POST getNas :

'POST /cloudnas/r0/ws.dispatcher/getNas HTTP/1.1'."\r\n".
'Content-Type: application/x-www-form-urlencoded'."\r\n".
'User-Agent: hubiC/1.0.9 (Windows NT 6.1; fr_FR)'."\r\n".
'Content-Length: 54'."\r\n".
'Connection: Keep-Alive'."\r\n".
'Accept-Encoding:gzip'."\r\n".
'Accept-Language: fr-FR,en,*'."\r\n".
'Host: ws.ovh.com'."\r\n".
''."\r\n".
'session=<id>'."\r\n".
"\r\n";

Requête POST getCredentials :

'POST /cloudnas/r0/ws.dispatcher/getCredentials HTTP/1.1'."\r\n".
'Content-Type: application/x-www-form-urlencoded'."\r\n".
'User-Agent: hubiC/1.0.9 (Windows NT 6.1; fr_FR)'."\r\n".
'Content-Length: 54'."\r\n".
'Connection: Keep-Alive'."\r\n".
'Accept-Encoding: gzip'."\r\n".
'Accept-Language: fr-FR,en,*'."\r\n".
'Host: ws.ovh.com'."\r\n".
''."\r\n".
'session=<id>'."\r\n".
"\r\n";

Et voilà. Ca va renvoyer les trois précieuses informations.

Certains pourraient me demander : mais comment avez-vous fait pour avoir ces informations ? Le serveur d'hubiC est en HTTPS ; on ne peut pas écouter la conversation entre le client et le serveur. Effectivement, sauf que le client tourne sur mon système. Rien ne m'empêche de brancher un débuggeur sur mon programme sur ma machine. En deux mots : OllyDbg, SSL_write.

Bon, comme j'aime aussi le Perl, je fournis le programme qui permet de récupérer les précieux sésames : http://www.protocol-hacking.org/public/hubic.pl

% ./hubic.pl 
Usage: ./hubic.pl -l login [-d] [-h]
% ./hubic.pl -l <mon_login_genre_une_adresse_email>
Password:
URL:      https://cloudnas1.ovh.com/XXXXXXXXXX/
Login:    cloudnas
Password: YYYYYYYYYY

mount -t davfs https://cloudnas1.ovh.com/XXXXXXXXXX/ /mnt

Maintenant, hubiC fonctionne sur tous les systèmes supportant un client WebDAV.

UPDATE : la presse en parle :

UPDATE : autres versions du programme :

Making network protocols go crazy - Mot-clé - protocole

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

hubiC, maintenant vraiment ubiquitous