[1]News / Hotspot Public Fr * [2]Home * [3]Publications * [4]Projects * [5]Presentations * [6]In The News * [7]Speaking Schedule De la sécurité des points d'accès sans fil payant Par Xavier Poli, [8]secuobs.com Le 24/02/2006 Vous utilisez peut-être régulièrement les offres d'accès sans fil payante proposée dans les lieux publics et plus particulièrement dans les hôtels. Le paiement afférant à ce type d'offre peut se faire de façon soit directe avec un paiement par carte bancaire soit en décalé, le prix de l'accès étant impacté sur la facture finale de votre séjour. Une troisième alternative de paiement ? pas de paiement ! Nous allons vous expliquer pourquoi il est possible que vous soyez facturé sur votre note d'hôtel alors que vous n'avez même pas de carte WIFI voir encore moins d'ordinateur portable. Cet article est basé sur une présentation réalisée par Jim Geovedi, contributeur à plusieurs projets opensource ; cette présentation a eu lieu lors de It Underground à Prague les 23 & 24 février, la conférence était notamment organisée par l'éditeur des magazines Hakin9 & Linux+. Vous en tirerez surement certaines conclusions vis à vis de la sécurité des informations bancaires que vous échangez avec ce type de service et celle des données confidentielles stockées sur votre machine que vous exposez dans ces lieux via vos partages réseaux non filtrés par exemple. Ce genre d'offre est généralement surfacturée par les hôtels (20 euros pour 24 heures !) ou plutôt les opérateurs (Orange ?), certains hôtels n'étant pas intéressés à ces ventes, déjà bien contents de pouvoir offrir un service supplémentaire à leur client. Si l'on peut appeler cela un service au client, vous êtes surement déjà tombé sur ce genre d'offre commerciale où l'on vous assure d'une connexion WIFI à votre arrivée dans la chambre, sans préciser au préalable que vous aurez à la payer, de surcroît au prix fort. Les bons comptes faisant les bons amis, il est possible de ne pas la payer, plusieurs techniques ont émergé avec le temps, nous allons les décrire. La majorité de ces offres est basée sur la technologie de portail captif. La méthodologie est la suivante, vous connectez votre ordinateur au Hotspot en question en précisant soit son ESSID (nom) soit son BSSID (adresse MAC matérielle) ou en choisissant dans une liste de points d'accès disponibles ; l'attribution de vos configurations réseaux (automatiquement par le service DHCP attaché) plus tard, vous ouvrez un navigateur (Firefox de préférence) et quelque soit votre page d'accueil votre session va être redirigée vers le fameux portail captif, il est propre à chaque type de Hotspot ou à chaque opérateur. C'est via ce portail que vous allez pouvoir choisir, et la plupart du temps payer, votre offre d'accès à Internet. Premier problème, ces portails sont parfois en HTTP & pas en HTTPS, il est donc possible à l'aide d'un outil d'écoute réseau (tcpdump, ethereal, ettercap) de récupérer de nombreuses informations sensibles (configuration IP des clients légitimes, couple utilisateur mot de passe d'accès ou autres). Le paiement en ligne se fait quand à lui en https, merci aux organismes bancaires pour le coup, mais vous le verrez plus loin il est également possible de contourner cela afin de récupérer les informations relatives à ces opérations financières. Certains opérateurs vous proposent (gracieusement ?) une période d'essai (teasing) parfois limitée à quelques sites de recherches (google.com en général) où vous n'irez pas plus loin que la page affichant les résultats de votre requête (quid des résultats en cache google ?). Cette limite de temps peut, vous pouvez facilement l'imaginer, être contournée et réinitialisée à zéro avec un peu d'imagination et un script qui va bien. D'autres Hotspots bloquent par défaut le trafic http/https entièrement, redirigeant vos requêtes vers le portail captif comme indiqué précédemment, mais il ne bloque pas les résolutions DNS (IP vers nom de domaine), il est alors possible d'exploiter le port 23 (DNS) via la mise en place d'un tunnel. Des logiciels, à cet effet, existent, OzymanDNS ( http:[click] ) entre autres par exemple ; la seule contrainte consiste à contrôler un sous domaine propre sur un serveur DNS et avoir à disposition un serveur OzymanDNS accessible à l'extérieur (./nonde.pl -i interface domaine_dns). Un accès SSH tunnelé en DNS via le sous domaine ozy.secuobs.com en tant que root vers le serveur hébergeant www.exoscan.net ressemblerait à la commande suivante : ssh -v -o ProxyCommand ="./droute.pl -r ozy.secuobs.com" root@www.exoscan.net Intéressons nous maintenant de plus près à la page assurant l'authentification sur le portail captif, une visualisation rapide de la source html de cette page peut se révéler parfois très utile notamment avec des options de liste qui ne sont documentées ni sur la page ni dans la source mais que l'on peut aisèment déduire en fonction de leur absence de la liste : form method=post action=./check_form.cgi select name=product_id option value=1 1 jour pour 20 euros /option option value=2 2 jour pour 37 euros /option /select select name=billing_method option value=2 CB /option option value=3 Room charged /option /select input type=submit value=Go /form Mais où est donc passée l'option 1 pour le paramètre billing_method ? Un essai sur www.exemple.com/defaultportal/check_form.cgi?billing_ method=1&product_id=2 ... vous êtes maintenant habilité à faire tout ce que vous désirez pendant deux jours dans la limite des services autorisés (vers l'extérieur, contournable via le tunneling) pour les utilisateurs ayant effectué un paiement. Des options même cachées ne sont pas pour autant non accessibles et non utilisables. D'autres Hotspots segmentent les allocations DHCP en fonction de l'état d'authentification du client, un client authentifié se verra par exemple affecter une adresse IP sur la range 10.0.0.1/24 alors qu'un client qui ne le sera pas aura une IP appartenant au réseau 10.1.1.1/24. Un peu d'écoute sur le réseau permet alors de récupérer les informations de configuration nécessaires à un état authentifié et vous pourrez, en ajustant vos paramètres locaux en fonction de ces informations, naviguer sans problème de restriction d'authentification et sans avoir eu à payer quoi que ce soit. Le vol de session et des configurations réseau d'un client déjà authentifié est également une possibilité via cette méthode. Dans le même ordre d'idée, lorsque le paiement est reporté sur la facture globale, il est possible via la manipulation d'un paramètre (idéalement RN pour Room Number) dans l'url d'enregistrement de charger la facture d'une autre chambre que la votre tout en profitant de l'accès qui en résulte. Il vous suffit pour cela de positionner une valeur différente de celle de votre chambre sur le paramètre en question et de laisser la surprise au locataire de celle-ci lors de la réception de sa facture au check-out. La suite devrait vous faire encore un peu plus réfléchir avant de donner vos coordonnées bancaires sur ce genre de service. Il est possible pour un attaquant de mettre en place son propre Hotspot WIFI dans sa chambre d'hôtel avec un portail captif ressemblant à s'y méprendre au portail légitime (même design, url usurpée). Il utilise ensuite le principe du Takeover AP, la puissance d'émission de son AP est plus importante que celle du Hotspot de l'hôtel. Les cartes WIFI des clients se connectent sur ce fake-AP, les utilisateurs sont redirigés vers le portail captif malicieux, ils remplissent le formulaire adéquat avec leur numéro de carte bancaire, l'attaquant simule un paiement en échec (Phishing style) puis utilise ces informations pour payer son propre accès et/ou continue à stocker les numéros de carte bancaire valides pour d'autres utilisations futures. Alternative il peut simuler un paiement qui ne soit pas en échec, laisser les utilisateurs naviguer via son AP et un accès déjà payé frauduleusement ou non. Cette AP fait alors office de relai, il peut récupérer toutes les informations de connexion (mail, compte web, compte d'accès distant, messagerie instantannée) transitant par l'AP à la manière d'une attaque par Man In The Middle (MITM). Il est possible de mettre en place ce genre de solutions pour connecter les ordinateurs « dormant ». Les cartes WIFI non désactivées (notamment sur les systèmes d'exploitation Windows) se connectent automatiquement aux réseaux les plus proches et/ou les plus puissants. Un attaquant peut alors naviguer dans vos partages réseaux ou utiliser des codes (exploit/shellcode) afin de profiter des failles présentes sur votre machine et la compromettre pour profiter de l'accès à vos données. Conseil de circonstance, désactiver vos cartes WIFI lorsque vous ne vous en servez pas et éviter si possible de donner vos coordonnées bancaires n'importe où, à n'importe qui et dans n'importe quelle circonstance ! Apprenez à utiliser les mêmes outils, tout au moins certains, que les attaquants pour vérifier qu'un point d'accès remplit au minimum les conditions nécessaires à une sécurité même basique ; mais n'en profitez pas frauduleusement, dans le cas contraire c'est à vos risques et périls si vous ne savez pas exactement ce que vous faites et que vous n'avez pas une idée précise des traces que vous pourriez laisser. De plus ce genre d'infractions est sévèrement puni par la loi, même et d'autant plus si vous savez ce que vous faites. Une dernière possibilité pour la route ? Attaquer directement l'AP légitime sur ses failles non patchées (pas si rare que ça) afin de récupérer les fichiers en charge de l'attribution des noms d'utilisateurs et des mots de passes, ces derniers sont parfois encodés avec des solutions dites « faibles » que vous pouvez craquer dans un laps de temps convenable. Ces AP ajoutent généralement des règles de filtrage dynamiquement en fonction des clients qui ont passé l'authentification, vous pouvez ajouter une rêgle pour votre machine et naviguer tranquillement. Comme vous pouvez le constater, les techniques sont multiples et chaque solution apportée par les vendeurs trouve sa contre mesure chez les attaquants pour un jeu du chat et de la souris qui ne semble pas près à s'interrompre. Copyright © 2004-2006. Jim Geovedi <[9]jim@geovedi.com> Page last modified on March 28, 2006, at 01:10 PM References 1. http://jim.geovedi.com/News 2. http://jim.geovedi.com/Main/HomePage 3. http://jim.geovedi.com/Publications/HomePage 4. http://jim.geovedi.com/Projects/HomePage 5. http://jim.geovedi.com/Presentations/HomePage 6. http://jim.geovedi.com/News/HomePage 7. http://jim.geovedi.com/SpeakingSchedule/HomePage 8. http://www.secuobs.com/news/24022006-hotspot_public.shtml 9. mailto:jim@geovedi.com