Making network protocols go crazy

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

dimanche, janvier 29 2012

hubiC, maintenant vraiment ubiquitous

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 :

vendredi, novembre 14 2008

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

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/

mardi, octobre 14 2008

Il était temps ...

Et oui, il était temps pour moi d'avoir un blog. Je ne vois pas pourquoi, moi, j'en n'aurais pas un. Alors sans hésitations, j'ai pris DotClear.

Ceux qui me connaissent se demanderont pourquoi j'ai pris un truc en Pé-Ash-Pé. Ben, parce que DotClear, c'est simple :) Et j'avais pas envie de chercher pendant 3 jours une version en Perl.

Sur ce blog, Je vais me concentrer sur le 'hack' de protocoles réseaux. Pourquoi ? parce que j'aime ça :) je montrerais des exemples concret d'utilisation de mon framework de construction et d'injection de packets réseau préféré : Net::Frame. Vous me direz : c'est quoi le hack de protocole réseau ? Eh bien c'est l'art d'exploiter les failles dans le design des protocoles, afin de faire faire des choses non-prévues dès le début. C'est aussi comment exploiter les failles d'implémentation, ou encore comment fuzzer un protocole.

Vous l'aurez compris, c'est un blog dédié à la couche réseau (and related). J'espère avoir l'inspiration suffisamment souvent, et sur des sujets suffisamment intéressant pour faire vivre ce 'yet another security blog'. Bonne lecture.