fr.comp.securite
Affichage de l'article :
Re: Reseau Wifi non securise: que fai re ?

Date : Le 13 avril 2006
From : Cedric Blancher
Sujet : Re: Reseau Wifi non securise: que fai re ?

Le Wed, 12 Apr 2006 08:23:19 +0000, Bertrand a écrit :
[portail captif, Chilispot]

Pour commencer, on va regarder l'infrastructure elle-même et se poser la
question de savoir si le portail captif rend bien le service pour lequel
il est déployer. Alors un portail captif, ça marche ? Réponse : non. Un
portail captif se contourne du fait que sur un domaine de collision, deux
utilisateurs peuvent utiliser la même adresse MAC sans problème et que
le pas qui reste à franchir pour usurper l'adresse IP en même temps
n'est pas super grand. C'est ce que j'ai montré rapidement pendant n
lightning talk à Eusecwest/core06 :

http://sid.rstack.org/pres/0602_ESW_CaptiveBypass.pdf

La démo est faite sur NoCatSplash en usurpant la MAC et l'IP d'un client
autorisé.

Ensuite, pour ce qui de l'accès HTTPS au portail captif, il y a
évidemment le problème du certificat qui se pose de manière cruelle. Si
le certificat est autosigné, cela va poser des problèmes de
vérification aux clients. D'abord parce que le fait qu'il soit autosigné
oblige à l'installer directement en lieu et place de sa CA. Du coup, s'il
expire, il va falloir installer un nouveau certificat autosigné que
personne ne peut certifier. Si on passe par une CA, on peut installer la
CA, qu'on peut affubler d'une clé de grande taille et donc d'une durée
de vie plus longue, et gérer les changements de certificat plus
simplement. Bref, qui dit problème de certificat dit popup, qui dit popup
dit clic sur OK, qui dit clic sur OK dit Man in the Middle sur la session
SSL et vol de crédences. Ceci étant, l'administrateur, avec un peu de
mauvaise foi, pourra arguer le manque de discernement de l'utilisateur,
même s'il me semble de sa responsabilité de s'assurer que les
utilisateurs n'aient pas ce genre de problème.

Mais de toute manière, le vol de crédence n'est pas nécessaire au
contournement du portail captif. En effet, ce dernier récupère l'adresse
MAC et l'adresse IP de la station d'où il voit venir le flux. Donc, vous
faites un MiM de niveau 3, genre ARP cache poisoning, vous routez/NATez le
flux du client à travers vous. Quand il va s'authentifier, ce sont votre
MAC et votre IP qui entrerons dans le ruleset. Et paf.

Dans le genre nettement plus simple et définitif, il y a l'encapsulation
DNS, qui marche tout le temps puisque les portails captifs fournissent
toujours ce service. Ceci étant, ça demande un domaine qui peut se faire
tracer. Maintenant, si on devait fournir son identité pour avoir un
domaine, ça se saurait :)

Donc en gros, n'importe qui d'un peu motivé (mais vraiment un tout petit
peu) peut contourner le portail, directement ou en usurpant un utilisateur
valide, voire voler des crédences. C'est grave, parce que ça veut dire
que tes administrateurs ne peuvent pas compter sur l'authentification et
ne peuvent donc pas imputer les actions. Si M. Evil décide d'usurper M.
Dupont pour faire des conneries, c'est M. Dupont qui va prendre. Ce
dernier, sûr de sa bonne foi, pourra trouver simplement des informations
comme les slides cités précédemment montrant que le système
d'authentification n'est pas efficace et qu'ils ne peuvent donc pas lui
imputer la faute. M. Evil peut également se montrer plus fin, c'est à
dire faire ses conneries en son nom et invoquer la faille pour échapper
à la sanction.

L'infrastructure mise en place, qui vise à authentifier les utilisateurs,
ne remplit pas son rôle. C'est mal, les administrateurs ont bossé pour
rien.


Maintenant, côté client... Et bien côté client, il y a d'abord le
risque de se faire voler ses crédences, pour l'accès Wifi d'une part,
mais également sur pleins de services à droite et à gauche (là encore,
perte pour les admins). L'utilisateur est donc mis dans une situation de
fragilité puisqu'il est forcé d'utiliser un servie pour lequel on ne lui
fournit aucune protection. Je pense qu'il n'y a pas loin à invoquer la
loi informatique et liberté sur la carence de protection des données
personnelles qui ne doivent pas manquer de foisonner sur ce réseau
(courrier électronique par exemple).

En outre, la nature ouverte de réseau permet à tout un chacun d'attaquer
le poste de qui bon lui semble, soit directement, soit par injection de
trafic, type d'attaque relativement discrète, sans association
nécessaire.

Le fin du fin restant de polluer les flux, ce qui est relativement
trivial et non traçable, l'attaquant n'ayant là encore même pas besoin
d'être associé, comme ça a été montré à la Defcon en 2004 avec
l'outil airpwn qui permettait à ses auteurs de renvoyer des images
arbitraires en réponses à des requêtes HTTP sniffées sur le réseau.
Dans ce cas c'était très drôle, mais si on commence à injecter du PNG
ou du WMF mal formé, ou encore des scripts un peu pernicieux, je connais
des navigateurs qui vont faire la tronche (suivez mon regard).

J'ai résumé tout ceci dans quelques séries de slides dont voilà la
dernière en date:

http://sid.rstack.org/pres/0602_Securecon_WirelessInjection.pdf

> Bref, que suggèrez vous:
> - Pour faire bouger les admins (textes légaux ?)

Non fourniture des éléments nécessaire à l'application de la politique
de sécurité qui la rend inapplicable.
Non recevabilité des journaux de connexion en cas de soucis.
Informatique et liberté pour les données personnelles.

> - Comme solutions alternatives (c'est bien beau de casser ce qui est
> fait, encore faut il apporter une solution alternative, même si c'est
> pas à moi de le faire normalement)

WPA/WPA2 avec authentification en PEAP-MSCHAPv2 sur le RADIUS déjà en
place pour Chilispot. Ceci permet de distribuer des login/password
individuels, de réaliser des authentifications mutuelles correctes et
donc de pouvoir imputer les dautes. Ensuite, un firewall derrière le tout
avec les restrictions d'accès désirées. On peut recycler la machine qui
héberge le Chilispot pour installer ce firewall. C'est donc un migration
qui ne demande pas de matos ou fonctionnalité supplémentaire par rapport
à l'existant.

On te répondra que le WPA, c'est pas supporté par tout le monde, ce
qui est faux dans 99% des cas, la plupart des systèmes le prenant après
upgrade générale (OS+drivers). Et puis c'est leur réseau, s'il veulent
poser des conditions, ils peuvent (doivent), certains le font déjà...

En outre, les APs Cisco supportent plusieurs ESSID avec des configurations
différentes sur le même canal. Ils peuvent donc créer un réseau
WPA/WPA2 pour ceux qui veulent être protégés un minimum, et un réseau
séparé (au niveau 3 mini) pour les feignants avec le joli portail captif
qui sert à rien. Mais ceci ne fera que protéger les clients, dans la
mesure ou M. Evil se fera un plaisir d'aller sur le réseau ouvert pour
faire ses conneries.


--
non mais si les grandes socites de jeux videos se mettent a payer les
piratins, c 'est la porte ouverte aux enfonceurs de porte, comme les
terroriste, c'est pour ca que dans Deus EX, l'unatco ne negocie jamais
-+- GaVaGe in GPJ: Never open the door to terrorist-players -+-

Posez vos questions, réponses et remarques sur les forums de AuthSecu