Insecurity enforced...

L

a semaine dernière, j'ai fait un crochet par São Paulo en revenant d'une mission à Brasilia pour assister à la 7e édition de H2HC. Outre d'excellentes présentations sur lesquelles j'ai la flemme de faire un retour, ça m'a donné l'occasion de faire face à un des portails captifs parmi les plus gonflants que j'ai pu rencontrer.

Le syndrome est le suivant. Aucun problème pour s'associer ou récupérer une IP. Le page d'accueil s'affiche et on se logue sans problème. Et là, forcément, tout soucieux qu'on est de sa sécurité, on lance une session VPN. Une quinzaine de secondes plus tard, chrono en main, le trafic s'interrompt. Vous venez de vous faire jeter du portail, il faut renouveler votre session...

Le problème est reproductible sans aucun soucis. Enfin... Je dis problème parce que je considère qu'il n'est pas normal de ne pas pouvoir lancer une session VPN sur un réseau Wi-Fi ouvert, même si ça n'a pas l'air d'être l'avis du support du fournisseur... Qui, d'ailleurs, mais est-ce plus surprenant que ça, n'a pas le début d'un indice de compréhension de ce qui peut bien se passer...

J'ai quand même fini par trouver. Et c'est la manière dont ils facturent la connexion qui m'a mis sur la voie. 1BRL/min avec un maximum de 30BRL pour 24h. Comment diantre font-ils pour avoir une précision à la minute ?... La réponse était enfouie dans le code du portail captif, aux tréfonds d'un JavaScript. Une petite fonction de rien du tout qui va en quelque sorte pinger un service web toute les dix secondes. Et si elle n'est pas à l'heure ? Bah ça coupe...

Et le service web en question n'est accessible que de l'infrastructure du fournisseur... Alors forcément, quand vous lancez votre VPN qui va rediriger, comme il se doit, l'intégralité de votre trafic à travers son tunnel dûment authentifié et chiffré, ben la petite requête du JavaScript échoue lamentablement à joindre le service qui va bien, et vous vous faites kicker comme un malpropre. À moins évidemment, une fois ceci compris, de coller une route directe vers le serveur qui va bien...

Et quand on voit la tête de la requête en question sur le réseau, on ne peut s'empêcher de commencer à avoir des idées...

On sait fort bien que les environnements Wi-Fi ouverts sont incroyablement vulnérables, et ce n'est pas tout neuf. La publication de Firesheep nous le rappelait encore tout récemment. D'où l'intérêt, quand on se trouve connecté par ce genre de moyens, de tunneler le plus rapidement possible l'intégralité de votre trafic.

Et je dis bien l'intégralité. Parce que les setups qui interrogent le serveur DNS local, en dehors du tunnel, sont des choses qui arrivent et qui ne sont, de toute évidence, pas top niveau sécurité. Ceux qui ne protègent que les flux à destination du réseau d'entreprise et laissent le reste transiter en clair ne sont pas terribles non plus. Les attaques cross-sessions sur les navigateurs, ça marche très bien aussi, en particulier quand vous avez affaire à un master d'entreprise, à jour d'il y a deux ans...

Ce qui fait de ce système de portail captif une fort jolie machine à exposer les utilisateurs... Une de plus...

Tout ceci étant dit, les utilisateur de Dns2tcp n'ont eu à se plaindre d'aucun soucis de ce genre... Comme quoi...