Reseau Wifi non securise: que fai re ?

Le
Bertrand
Bonjour,

Je vais d'abord expliciter un peu le sujet. Je suis un utilisateur forcé
d'un reseau wifi non securisé. J'entends par là que le réseau ne dispose
d'aucun cryptage, seulement d'un systeme d'authentification HTTPS, et
que je suis forcé de l'utiliser pour acceder à certains services n'ayant
pas accés au réseau filaire partout. Une fois authentifié, tout transite
en clair c'est à dire qu'aucun cryptage type WEP n'est mis en oeuvre.
Lorsqu'un client s'associe à un point d'accés, tout le trafic est
bloqué, sauf celui vers le port 80, qui est redirigé quel que soit le
site demandé vers le portail d'authentification (en HTTPS avec un
certificat auto signé). On peut de là s'authentifier, ce qui débride
la connection en ouvrant vers l'exterieur certains ports (80, 443, 110,
25, ). Le problème c'est que les "credentials" (login/password) sont
certes cryptés pendant l'authentification (et encore, vu que le
certificat est self signé et que personne ne l'ajoute à son catalogue,
personne n'y fait attention et on peut se retrouver facilement en
situation de MITM), mais une fois l'authentification faite, les
credentials pour accéder aux autres services de l'entreprise passent en
clair donc la protection des credentials est nulle ou presque.

Le portail d'authentification Wifi est gerée par
http://www.chillispot.org/, et les points d'accés sont de marque Cisco
Systems mais je n'en sais pas plus.

Comment puis-je faire comprendre aux gens qui s'occupent de
"l'informatique" et de ce réseau Wifi qu'ils font une grosse annerie (et
je suis poli) en ne sécurisant pas leur réseau comme il convient ? A ce
stade c'est pas seulement le réseau Wifi qu'il faut revoir mais tous les
services (tout est en HTTP non crypté ou presque, ), sans parler de
TRES grave failles de sécu découvertes par un ami dans l'Intranet
compromettant l'Intranet mais aussi l'ensemble des services associés
(failles +- fixées aprés qu'on les ait signalées, heureusement) que je
ne detaillerai pas ici

M'amuser à sniffer les passwords de tout le monde pour ensuite mettre le
bazar avec n'est pas une solution me convenant, bien que j'ai peur qu'un
jour quelqu'un de bien moins scrupuleux s'y mette (Ethereal suffit
:). je n'ai pas non plus très envie d'aller voir les admins pour
leur dire texto "c'est pas securisé votre truc", ils ne reagiraient pas
forcément comme on pourrait l'attendre

Je pense qu'avec des points d'accés Cisco et tout le matériel necessaire
on devrait normalement pouvoir avoir un niveau de sécurité bien plus
important. C'est pourtant pas le fric qui manque peut etre la
motivation et/ou les compétences.

Bref, que suggèrez vous:
- Pour faire bouger les admins (textes légaux ?)
- 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)

Merci
@+
Bertrand
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
EoIP
Le #838671
Bertrand :

Bonjour,
bonjour



Bref, que suggèrez vous:
- Pour faire bouger les admins (textes légaux ?)
- 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)



Je ne connais pas votre boite, mais ne jouez pas trop à sniffer ou scanner parce
que ça pourrait se retourner contre vous.

Parlez-en avec les admins, autour d'un café. Peut-être auront-ils des
explication valables. S'ils n'en ont pas vous avez plusieurs possibilités :

Leur faire la leçon,
ou
en parler à un responsable, en gros aller lui dire comment les admins devraient
faire leur boulot,
ou
prendre vos dispositions et protéger vos données.

Il est bon de rappeler que les administrateurs font le travail pour lequel ils
sont payés et que vous n'avez peut-être pas tous les paramètres pour pouvoir
affirmer qu'ils commettent des fautes.


Merci
@+
Bertrand


Cedric Blancher
Le #838664
Le Wed, 12 Apr 2006 13:56:49 +0000, EoIP a écrit :
Il est bon de rappeler que les administrateurs font le travail pour
lequel ils sont payés et que vous n'avez peut-être pas tous les
paramètres pour pouvoir affirmer qu'ils commettent des fautes.


Il est également bon de rappeler à ces administrateurs que déployer de
la vraie sécurité WiFi est plus simple et efficace que de coller du
portail captif, surtout quand ce dernier nécessite un RADIUS en backend...

Maintenant, si leur hiérarchie leur met un pistolet sur le tempe...


--
«En fait, le but de la fission de fcol etais de creer encore plus de
trafic sur usenet car les newbies postent de toutes facons sur tous les
groupes avec linux dedans.»
-+- MA in Guide du linuxien pervers - "De la linuxitude..." -+-

Cedric Blancher
Le #838453
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 -+-

Vincent Bernat
Le #838450
OoO En ce début de soirée du jeudi 13 avril 2006, vers 21:25, Cedric
Blancher
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 :)


Il est possible que le DNS resolve toujours vers la meme IP. C´est ce
que je fais sur le semblant de portail captif d´une association (il
sert à expliquer aux gens comment configurer le VPN, il est donc
sensible aux autres attaques citées).
--
#if 0
2.2.16 /usr/src/linux/fs/buffer.c

Cedric Blancher
Le #838449
Le Thu, 13 Apr 2006 20:03:50 +0000, Vincent Bernat a écrit :
Il est possible que le DNS resolve toujours vers la meme IP.


C'est effectivement possible. Le problème, c'est que les clients 2k/XP
arrivent avec un cache DNS client activé par défaut que tu vas
joyeusement polluer, pollution qui va persister après l'authentification
du client, l'empêchant d'accéder à tous les sites qu'il aura pu
demander avant authentification.

Il va donc falloir être très fin dans la configuration du serveur DNS
pour fournir des TTLs très basses et éviter ainsi le cache sauvage, ce
qui suppose également un client dont le resolver tient la route...

Bref, comme tout ce qui repose sur un cache, ça se prend avec des
pincettes, un peu comme les systèmes de failover qui ne virtualisent
qu'une IP et dont les clients ne basculent pas à cause du cache ARP :)


--
Quels sont les symptômes délirants? 255 c'est un peu téléphoné comme
valeur...
TL> C'est vrai que c'est la valeur max d'un unsigned char.


OM> 2**8-1 (hein)
-+- TL et OM sur debian-french: "Heckel et Jeckel" -+-


Vincent Bernat
Le #838448
OoO En ce milieu de nuit étoilée du vendredi 14 avril 2006, vers
03:19, Cedric Blancher
Il est possible que le DNS resolve toujours vers la meme IP.


C'est effectivement possible. Le problème, c'est que les clients 2k/XP
arrivent avec un cache DNS client activé par défaut que tu vas
joyeusement polluer, pollution qui va persister après l'authentification
du client, l'empêchant d'accéder à tous les sites qu'il aura pu
demander avant authentification.


A priori, le cache est soit propre à une interface, soit flushé lors
de la mise en place d'IPsec. Je n'ai jamais eu de problème de ce côté
(au contraire des clients Linux avec nscd, mais c'est un setup assez
rare).
--
BOFH excuse #391:
We already sent around a notice about that.


Cedric Blancher
Le #838447
Le Fri, 14 Apr 2006 10:15:47 +0000, Vincent Bernat a écrit :
A priori, le cache est soit propre à une interface, soit flushé lors
de la mise en place d'IPsec. Je n'ai jamais eu de problème de ce côté


C'est ton cas particulier. Dans le cas général du portail captif, le
spoof DNS pose problème parce qu'on ne change pas d'interface.

(au contraire des clients Linux avec nscd, mais c'est un setup assez
rare).


Il reste encore des dinos pour utiliser nscd ;)

Sinon, en parlant de DNS, je me souviens d'un évènement annuel de
l'OSSIR d'il n'y a pas très longtemps, dans une salle couverte en WiFi
via portail captif qui laissait sortir UDP/53 à tous vents. Je sais pas
pourquoi je te dis ça, à toi, d'ailleurs ::grin::


--
JK: Y a-t-il un mot français pour tamagotchi (cette petite bête électronique) ?
JR: J'ai en préparation un cathogauchi pour PC. Dès qu'il sera prêt je le poste.
-+- in: Guide du Cabaliste Usenet - L'écran catholique de la Cabale -+-

Nicob
Le #841463
On Wed, 12 Apr 2006 08:23:19 +0000, Bertrand wrote:

- Pour faire bouger les admins (textes légaux ?)


Si des données personnelles sont stockées sur le réseau (ce qui est
quasiment toujours le cas sur un Intranet via la compta, la DRH, les
serveurs de fichiers ou les mails), l'évocation des risques juridiques
(pas à un admin, hein, mais au "management") peut être un bon moyen de
faire bouger les choses :

http://www.cnil.fr/index.php?id

La sécurité des fichiers :

"Tout responsable de traitement informatique de données personnelles
doit adopter des mesures de sécurité physiques (sécurité des locaux) et
logiques (sécurité des systêmes d'information) adaptées à la nature des
données et aux risques présentés par le traitement. [...] Le
non-respect de l'obligation de sécurité est sanctionné de 5 ans
d'emprisonnement et de 300 000 euros d'amende. (art. 226-17 du code
pénal)"

La confidentialité des données :

"Seules les personnes autorisées peuvent accéder aux données
personnelles contenues dans un fichier. Il s'agit : des destinataires
explicitement désignés pour en obtenir régulièrement communication,
des "tiers autorisés" ayant qualité pour les recevoir de façon
ponctuelle et motivée (ex. : la police, le fisc). [...] La communication
d'informations à des personnes non-autorisées est punie de 5 ans
d'emprisonnement et de 300 000 euros d'amende. La divulgation
d'informations commise par imprudence ou négligence est punie de 3 ans
d'emprisonnement et de 100 000 euros d'amende. (art. 226-22 du code
pénal)"

La dernière phrase pourrait suffire à convaincre ;-)
Bonne chance ...


Nicob

Publicité
Poster une réponse
Anonyme