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)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
EoIP
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
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.
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 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..." -+-
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..." -+-
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 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 :
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:
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 -+-
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 :
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:
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 -+-
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 :
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:
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
OoO En ce début de soirée du jeudi 13 avril 2006, vers 21:25, Cedric Blancher disait:
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
OoO En ce début de soirée du jeudi 13 avril 2006, vers 21:25, Cedric
Blancher <blancher@cartel-securite.fr> disait:
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
OoO En ce début de soirée du jeudi 13 avril 2006, vers 21:25, Cedric Blancher disait:
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 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" -+-
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" -+-
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
OoO En ce milieu de nuit étoilée du vendredi 14 avril 2006, vers 03:19, Cedric Blancher disait:
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.
OoO En ce milieu de nuit étoilée du vendredi 14 avril 2006, vers
03:19, Cedric Blancher <blancher@cartel-securite.fr> disait:
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.
OoO En ce milieu de nuit étoilée du vendredi 14 avril 2006, vers 03:19, Cedric Blancher disait:
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 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 -+-
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 -+-
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
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
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 ...
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 ...
