Reprise du message précédent :
Oui bon bref, je ferai un premier jet sur Netbeans, avec l'éditeur de fenetre kivabien, et puis si ça me saoule, un bon vieux script bash avec zenity

Je me pose une petite question : personellement, quand je veux générer des ARP pour injecter de IV's, je déauth le client légitime, pour le forcer à se reconnecter sur l'AP ; dans ce cas, de suite j'ai un résultat en terme de paquets ARP (logique). Cela permet de faire de l'injection sans attendre que le client légitime émette du traffic.

Cependant, dans le cas où un AP ne possède pas de stations connectés et authentifiés, comment faire ?
J'essaie de trouver la faille sur un AP 3com au boulot (c'est en partie mon travail officiel donc pas de "c'est pas bien" hein )
Donc c'est juste une petite clé 64bit, cassé en 30 secs si un client est là, pas de soucis (meme s'il ne génère aucun traffic, avec une bonne deauth il se met à générer de l'arp, et là c'est bon).

Mais là, sans client, j'arrive à faire un FakeAuth sur l'AP, mais ça ne génère aucun ARP en me DeAuth moi même.

Comment récup des IV's dans ce cas ?
Ya t il une autre solution ?

merci

up
J'ai pas trouvé de réponse précise sur le net (beaucoup ne font que répéter les bonnes commandes sans expliquer le comment du pourquoi )

C'est normal que pendant une injection j'ai un rxq qui oscille entre 0 et 50 alors que sans injection il est à 100 ?

C'est quoi le RXQ d'ailleurs ?

100 pour une qualité optimale

rxq et txq sont les taux de remplissage des buffer d'émission/reception d'une interface réseau.

Pour ceux qui se demandaient comment changer l'adresse mac de leur 3945 sous windows, vous avez essayé etherchange ? (pour moi et mon intel 2200 de mon centrino je dois redemarrer pour que ça soit effectif mais bon ça marche...)
 
Bon et sinon c'est quoi ces rumeurs que l'on peut lire sur les posts d'avril comme quoi le WPA serait sur le point d'etre mis à mal de la meme façon que le wep ? (ou meme que ça serait déjà fait...)
En tout cas je me suis amusé à tester de gros dicos sur des handshake récupérés au hasard, ben j'ai pas trouver 1 seul mdp...et pourtant ils etaient gros les dicos et le pc a tourné 36 heures non stop..

Le WPA PSK (soit 90% des WPA en France), c'est du RC4... so, ce n'est pas invincible si on arrive a trouver la faille. Par contre, les cryptages AES, j'ai lu que c'est "virtuellement" ( ) inataquable

Et j'ai pas lu de remeurs sur des solutions crypto pour casser le PSK, donc logiciement il n'y a pas d'outils pour ça.

Enfin, en ce qui concerne l'attaque via dico, c'est useless sur les livebox par exemple (inutile de toute façon si plus de 23 caractères variés)

et de toute façon les dicos ont l'air un peu limités quand meme en general quand on va fouiller de dedans

 
Pour l'instant, jusqu'a ce qu'une faille dans l'algo soit trouvée.
 
A ton avis, on sponsorise beaucoup les recherches sur le pétage de RSA mais pas AES, c'est bien pour une raison...

Pas bete.. Mais la manière dont il a été conçu semble le rendre beaucoup moins faillible non (disons plus difficilement ?)

Quid des infos de "cassage" sur le RC4 du WPA ? Où peut on se renseigner

Ce ne sont que des rumeurs, et on sait tous ce qu'elles valent sur le net.

salut,
quelqu'un a déja esayer de faire passer une "nintendo wi-fi usb connector" en point d'accés sur une distribution linux ?

 
mouais, de toute façon je pense qu'on sera au courant d'une manière ou d'une autre si ça se réalise
 

 
ça dépend, c'est quel chip wifi ?

Tiens, d'ailleurs ca m'interesse cette histoire de chip nintendo

Bon, pour ceux qui font ça souvent etc. on ne rigole pas, je trouve l'idée interrésante    
 
Je vous présente l'attaque de type "glue".
 
Un soft a été mis au point par deux personnes chez FT (R&D), mais le principe est très simple a mettre en place manuelement (meme si un peu moins complet).
 
Principe : les logiciels de connexion wifi (windows/intel/autre), retiennent les AP enregistrés. En effet, pour quand on va a un endroit avec un AP déjà utilisé avant, on se retrouve connecté. Le logiciel "probe" tous les SSID qu'il connait.  
Le problème ?  
Déjà on voit exactement où vous êtes allé. Souvent les AP ont le nom de l'endroit (Hotel Bidule de Geneve, etc).
 
Mais surtout... Si vous créer un AP avec un des noms "probés", le client se connecte sur vous en quelques secondes !
Très utile pour montrer qu'il est dangereux de laisser sa carte wifi allumée sans en avoir besoin !
 
Voyons en détails sur de l'atheros, une procédure simple et rapide à mettre en place (moins complexe que hostapd, mais plus rapide)
 
Un petit airodump-ng pour trouver des clients non associés, probant des AP.
Ensuite, on kill ce qu'on a déjà :
wlanconfig athX destroy (pour chaque athX que vous avez debout)
 
Ensuite, on creer l'ap :
wlanconfig athX create wlandev wifiX wlanmode ap
 
Puis on lui donne le nom (ou un des noms) qui est probé par un client :
iwconfig athX essid SSID_AP_probé
 
Bien entendu, un petit serveur DHCP sur votre machine est le bienvenue.
Si de votre coté vous avez une connexion internet, c'est encore mieux, vous faites passer le traffic par votre poste (méthode dispo début du topic).
Sinon, il y beaucoup de failles sympa pour montrer que laisse sa carte wifi allumée n'est pas une bonne idée !

J'ai vu ça il y a un an à une conf

 
oui en effet c'est pas nouveau (introduit en 2005 je crois)

Je me souviens avoir vu ca quelque part en effet...
La premiere demo s'est faite a une conf avec 2 laptop, personne voulait croire le gars avant qu'il montre que la faille etait bien la...

Au passage, quelques chiffres (enquete fort interessante je trouve)
Dispo ici (source RSA Security via ZDnet)

C'est très biaisé et incomplet comme procédure. Sur notre réseau, aucune des bornes n'a de WEP ou WPA d'activé (ca serait vraiment trop galère à configurer et à maintenir).

A la place, le réseau wifi est dans un bac à sable ou rien n'est accessible, sauf un serveur radius pour avoir un accès VPN, qui lui permet ensuite d'obtenir le réseau interne qui est sécurisé.

La sécurité du wifi ne se mesure pas vraiment à "WEP/WPA activé/pas activé", c'est très réducteur comme analyse, et ne tient pas compte des réalités sur des gros parcs.

En effet. Par contre, qu'en est-il des attaques man on the middle sur ce type de réseau ?
De plus, j'ai déjà expérimenté ça dans la pratique : cafet' pour étudiant dans un IUT, avec wifi ouvert et VPN.
90% d'users windows, un petit scan d'ip, et une exploration samba donne tout le temps un résultat positif : disques partagés en lectures/écritures, sans compter une floppé de ports ouverts sensibles aux exploits.

C'est pas pour rien que la sécu se fait à tous les niveaux (au boulot on a F-secure client security qui est pas mal, installé chez tout les nomades, ça tient plutot bien la route)

edit : content d'avoir relancé un peu le topic

De la part la négociation VPN, tu ne peux pas te mettre en MITM et récupérer des infos en clair (c'est ce que le VPN cherche d'ailleurs à éviter en passant par l'internet).
 
Après, il reste les problèmes de failles au niveau du poste local, mais pour lequel l'AP ne peut pas grand chose.

 
C'est vrai

Hmm.. Dans le cas dont j'ai parlé, une MITM est "possible", mais pas directement. Le client VPN est téléchargeable via une page dont l'adresse est affichée.
Libre a moi de faire un faux site, avec ce que je veux dessus (un faux client vpn ?)

edit : par contre, aucune chance de MITM en VPN, meme si le traffic passe par une machine pirate qui relaie le traffic

IPSec résiste au MITM (Diffie Helman dans IKE)

Oui, visiblement :  

Mais quid de la possibilité d'injection de traffic IP via un client légitime, ce dernier étant connecté via un VPN ?
Utile pour un hacker par exemple, pour réaliser des forfaits, tout en étant masqué..

Ah? Tu comptes falsifier les certificats aussi au passage?

(Le client est télécharge sur des pages en SSL/TLS)

C'est le principe même du VPN, tu peux relayer autant de trafic que tu veux entre machine, seuls les deux bouts (comprendre: la combo radius+racoon et le poste client) comprendront les messages.

Si tu utilises un VPN, tu es forcément authentifié par un serveur type radius ou autre.

Sauf bien évidemment quand on fait dans la majorité des endroits ou on ne connait rien au VPN, à savoir un certificat et des clés partagées identiques pour tout le monde.

Edit: sauf bien évidemment si tu compromets la machine qui est connecté légitimement par un autre moyen, mais dans ce cas, WEP/WPA ne t'en protégeront pas non plus.

Et pourquoi pas ne mettre aucun certificat ? Personne ne vérifie quoi que ce soit quand il va récup' le setup du client vpn ! On parle d'users de bases qui généralement se connectent rarement (je sais, j'imagine les pires cas )
Et de toute façon, il me semble qu'il existe des outils pour ça non (j'ai cru lire un truc là dessus dans les premiers posts du topik)

ok

edit : ta édit, donc :

Oui, je suis d'accord qu'un bon VPN, le certif est propre à l'user. Mais dans le cas de l'accès "élève IUT" au wifi, via un AP en clair, et un clien VPN, voici la procédure :
- on se connecte à l'AP
- on va sur un portail (l'ip est donnée) : log in + mot de passe éleve IUT
- on récupere le client cisco VPN, on dl aussi le certif
- on se connecte
- on a le net

Donc dans ce cas précis, une autre personne présente sur l'ap mais non authentifié via VPN pourrai injecter son traffic ip ?

Et dans le cas des gares/aéroport, où l'accès est payant, je suppose qu'il est tres possible d'injecter son traffic vers un client légitime ! Non ?

 
Le certificat est celui de l'Ecole. La première chose que l'on demande de faire avant le téléchargement, c'est de vérifié la CA (c'est en gros rouge sur la page nain ternet).
 

 
Le téléchargement est validé après un challenge obtenu par le certificat du client (qui est donné quand on demande un compe VPN pour le wifi), on profite de ce moment là pour faire configurer la machine et télécharger le bon client VPN à la personne.
 
Bien sûr après, si le gusse en question s'amuse à utiliser autre chose que ce qu'on lui demande, on ne peut pas lui empecher de filer ses logins/pass.
 
Mais vu la difficulté du bouzin (la majorité ne sachant pas faire autre chose que de cliquer sur des icones), ils passent tous nous voir pour qu'on explique, qu'ils aient lu la FAQ ou pas.

 
Naon, chez nous c'est: portail sur un proxy squid, qui redirige vers une adresse en https, et ensuite, téléchargement du client.
 

 
Oui, et après? Tu injectes des datagrammes qui ne sont pas cryptés pour le VPN (ils sont sur deux couches de même niveau mais complètement distinctes, de par IKE), donc le serveur n'est pas censé les prendre en compte. Et toi, dans l'autre sens, tu ne décrypteras pas les réponses, de toute manière.
 

 
Bah ca dépend des gares et des aéroports. Pour les peu que je connaisse, ils utilisent une bête page avec un login/pass qui va enregistrer l'adresse MAC pour créer un accès qui sera mis sur un compteur, donc là oui, tu fais ce que tu veux.

Et aussi dans pas mal d'hotels, aéroport (peut être les gares), le port 53 est ouvert et c'est trèèès simple d'avoir le net gratos suffit de faire un petit VPN avec un serveur qu'on a sur le net qui écoute sur ce port

Ca peut être dangereux, car qui dit serveur sur un port 53 avec son proxy dit nécessairement un serveur home made, et donc suffit de savoir a qui est ce serveur pour remonter facilement à qui s'en est servi.

Tandis que de l'injection est légitime (on se fait passer pour l'AP), et est beaucoup plus difficilement détectable.

Pour Plam: considère que pour le VPN, c'est un raisonnement simple:
- le client est supposé sur et légitime (sinon, bah autant ne pas lui créer d'accès VPN)
- la couche physique est peu sure (elle peut être écoutée par quiconque avec une antenne)
- le point d'accès est peu sur (on ne fait pas confiance à la borne)
- le serveur radius/racoon est sur

Donc l'injection ne peut pas marcher, car tu t'intercales entre le client et la borne, or ici elle ne sert à rien à part recevoir des paquets dont elle ne sait que faire, hormis les renvoyer vers le serveur pour le VPN.

De toute manière l'AP est toujours considéré peu sur, ce sont des interfaces proprios, pas documentées, qui se configurent par une interface web (yeurk, quand tu dois gérer 100+ bornes tu t'amuses), et donc avec des vendeurs qui te vendent un logiciel qui ne marche qu'avec leur matos à eux (du coup, tu payes tous les ans et tu assumes quand le matériel n'est pas supporté par les nouvelles versions   )

Le VPN évite au moins ca, même si ca reste galère à mettre en place, compte tenu des acteurs du marché qui y mettent de la mauvaise volonté (au hasard, cisco et grosoft...    )

Oui on sait quel serveur est utilisé mais bon qui surveille et va faire les démarches quand le gas s'est connecté 1h en attendant son train ou une soirée dans sa piole à surfer ?

Ah non mais personne.

Ca dépend de la gravité des actes commis, de la volonté des gars de vouloir tout surveiller/réprimer, etc.

Ne serait-ce qu'au niveau de l'AAA, je doute que l'on soit au point dans pas mal d'endroit, et je parie que les logs ne sont ni sauvegardés, ni scrutés avec attention...

 
Interessant en effet
 
Edit: Au passage, y'a un site qui repertorie les hotspots ouverts/fermes en france ?

 
Les sauvegardes des logs sont obligatoires il me semble

 
merci pour ces précisions
C'est pour ça qu'au boulot on utilise Open Vpn
 
(ah, et pour l'IUT, j'étais juste utilisateur, pas admin so.. )

 
Oui comme le téléchargement illégal est interdit (Mr Lapalisse )
 
Ca n'empeche pas pour autant qu'une majorité ne le fait pas. Jusqu'au jour ou ca te retombe dessus, mais je n'ai jamais eu d'échos à ce sujet, et je ne sais même pas s'il y a une jurisprudence avérée en plus