(Aircrack)Yet another WEP cracking tool for Linux - Page 5

topolb · 08-23-2004

New weplab v0.0.8-beta, with new Korek's attacks, is out.

Attacks 5/6 (10%) seems to be failing so I have disabled them by default. In my tests, 128-bit keys are cracked from 500-700k packets.

Thnks Korek for this

About aircrack and it's replay-attack... What kind of packets does it generate to produce responses? arp? How do you know which one is arp if all of them are encrypted? Is it possible to generate traffic replaying other packet types (for example icmp?).
Good job

devine · 08-23-2004

Quote:

Originally Posted by topolb

New weplab v0.0.8-beta, with new Korek's attacks, is out.

Attacks 5/6 (10%) seems to be failing so I have disabled them by default.
In my tests, 128-bit keys are cracked from 500-700k packets.

Thanks Korek for this

Yeah, his attacks really are awesome

Quote:

Originally Posted by topolb

About aircrack and it's replay-attack... What kind of packets does it generate to produce responses? arp? How do you know which one is arp if all of them are encrypted? Is it possible to generate traffic replaying other packet types (for example icmp?).

It may be possible. Nevertheless, arp requests are the most suitable kind of packets for this attack, because the other host always responds with an arp reply (even when a firewall is present). Furthermore, they have a very specific size and can be distinguished easily from the rest of the traffic.

kleptophobiac · 08-23-2004

So, if they are easily indentifiable... do they vary at all from packet to packet? Does an ARP storm really get you any new IV's?

devine · 08-23-2004

Quote:

Originally Posted by kleptophobiac

So, if they are easily indentifiable... do they vary at all from packet to packet? Does an ARP storm really get you any new IV's?

The plaintext content of the arp-replies does not vary. But the wifi hardware increments its IV counter before encrypting each reply, therefore it does provide new usable IVs; which is the point of this attack.

You mustn't be too far from the AP though; also, it's better to perform the attack with multiple cards resending the arp-requests, so that the maximum bandwidth is reached. This usually doesn't go unnoticed

sylvain · 08-23-2004

Devine, I sent you a private message : I got some troubles with your tool and dump files generated with Kismet and cisco aironet cards

devine · 08-23-2004

Quote:

Originally Posted by sylvain

Devine, I sent you a private message : I got some troubles with your tool and dump files generated with Kismet and cisco aironet cards

Thanks, got your dump file and identified the bug: the keyid was not selected automatically along with the bssid when the user did not specify a value. This will be fixed in aircrack 1.4.

kleptophobiac · 08-23-2004

I dunno, there's a darn good chance this would go unnoticed.

I know the school net admin very well, and I know the WEP key. Let's see if he notices when I try this on the network.

b0nk · 08-23-2004

Hi,

I'm looking for a paper describing KoreK's attacks.
Anyone could help ?

Thanks !
PS : aircrack & weplab : great job !

King_Ice_Flash · 08-24-2004

If it is possible, could you post the links to the patches on the aircrack download page with a description of what they fixed?

devine · 08-24-2004

Quote:

Originally Posted by King_Ice_Flash

If it is possible, could you post the links to the patches on the aircrack download page with a description of what they fixed?

Well, there would be quite a few of them; anyway aircrack 1.4 is to be released very soon, possibly today or tomorrow.

King_Ice_Flash · 08-24-2004

Fair enough. I couldn't find the patches easy enough, but if I won't need them, there's no point in doing all of that work. Thank you!

sylvain · 08-24-2004

yep, great job devine and topolb

b0nk · 08-24-2004

Hello,

I'm just playing with arp-request reinjection with aireplay.
I had an original ~90MB (~260K unique IVs) capture file, and aireplay finds about 500 possible ARP packets.
After reinjecting about 2M packets to the traffic & launching aircrack, it only finds about 4000 unique IVs.
Reading aireplay.c source :

if( pkh.len + ( h80211[27] & 0x3F ) != 0x44 )
continue;

0x44 = 68 decimal.
The calculated packet length must be 68 bytes length exactly if I understand well (and match every post conditions before this line).
I believe some false positive are possible.

What about improving the predictable packet filtering mechanism ?
ARP packets are not the only predictable ones, SYN/ACK/RST/FIN TCP packets are also predictable.
I would be pleased to have feedback for this.
I could rewrite the filtering mechanism and make a standalone filter code.

Thanks.
b0nk.

b0nk · 08-24-2004

Hi back,

After playing with aireplay code, I discovered few things.
I analysed manually my capture file with ethereal (which is far more useful to analyse packets than tcpdump

), to search for some recurrent patterns.
I had a look at broadcasted queries. I found many packets of 118 & 368 bytes (raw) length.

I found that the usual 68 bytes check (original aireplay source) had a tendency to give non optimal results.

Explanation :

At first, usable IVs received with traffic injection are quite good, but after 50K packets, usable IVs are more and more rare, reaching its limit after some time.
By replaying 118 & 368 bytes packets, this behavior seems to be more tolerent. I think it's certainly has a limit, but possible usable IVs reduces slower than the 68 bytes filter.

I also added 3 features I found useful for aireplay :
- Hexadecimal dump of selected packets
- Possibility to repeat a specific packet
- Set length check manually

More testing is needed, if someone want to try the code, let me know !
Feedback appreciated !

Bye.

b0nk · 08-24-2004

Hi again ..

I decided to graph some stats about usable IV's / time, with different lenghts of reinjected ARP packets (see previous post about aireplay modifications).
In attachement, you'll find a gnuplot dump of the results.
X axis : time, in seconds
Y axis : number of received packets containing usable IV's

I modified the airodump code to generate a list of coordinates to be used with gnuplot.
I didn't had time to make statistics on a 1 hour time basis. I'll dump that soon.

Regards,
b0nk.

08-23-2004	#61 (permalink)
topolb Registered Member Join Date: Jun 2004 Posts: 67	weplab New weplab v0.0.8-beta, with new Korek's attacks, is out. Attacks 5/6 (10%) seems to be failing so I have disabled them by default. In my tests, 128-bit keys are cracked from 500-700k packets. Thnks Korek for this About aircrack and it's replay-attack... What kind of packets does it generate to produce responses? arp? How do you know which one is arp if all of them are encrypted? Is it possible to generate traffic replaying other packet types (for example icmp?). Good job

08-24-2004	#69 (permalink)
King_Ice_Flash Alien Paranoid Stumbler Join Date: May 2003 Location: WI Posts: 2,624	If it is possible, could you post the links to the patches on the aircrack download page with a description of what they fixed? __________________ "Yeah," said a voice from under the table, "you go to pieces so fast people get hit by the shrapnel."

08-24-2004	#71 (permalink)
King_Ice_Flash Alien Paranoid Stumbler Join Date: May 2003 Location: WI Posts: 2,624	Fair enough. I couldn't find the patches easy enough, but if I won't need them, there's no point in doing all of that work. Thank you! __________________ "Yeah," said a voice from under the table, "you go to pieces so fast people get hit by the shrapnel."

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

08-23-2004	#63 (permalink)
kleptophobiac Registered Member Join Date: Sep 2002 Posts: 310	So, if they are easily indentifiable... do they vary at all from packet to packet? Does an ARP storm really get you any new IV's?

08-23-2004	#65 (permalink)
sylvain Wireless Auditor Join Date: Jun 2004 Location: Paris, France Posts: 175	Devine, I sent you a private message : I got some troubles with your tool and dump files generated with Kismet and cisco aironet cards

08-23-2004	#67 (permalink)
kleptophobiac Registered Member Join Date: Sep 2002 Posts: 310	I dunno, there's a darn good chance this would go unnoticed. I know the school net admin very well, and I know the WEP key. Let's see if he notices when I try this on the network.

08-23-2004	#68 (permalink)
b0nk Registered Member Join Date: Aug 2004 Location: Paris, France Posts: 8	Hi, I'm looking for a paper describing KoreK's attacks. Anyone could help ? Thanks ! PS : aircrack & weplab : great job !

08-24-2004	#72 (permalink)
sylvain Wireless Auditor Join Date: Jun 2004 Location: Paris, France Posts: 175	yep, great job devine and topolb

08-24-2004	#73 (permalink)
b0nk Registered Member Join Date: Aug 2004 Location: Paris, France Posts: 8	Hello, I'm just playing with arp-request reinjection with aireplay. I had an original ~90MB (~260K unique IVs) capture file, and aireplay finds about 500 possible ARP packets. After reinjecting about 2M packets to the traffic & launching aircrack, it only finds about 4000 unique IVs. Reading aireplay.c source : if( pkh.len + ( h80211[27] & 0x3F ) != 0x44 ) continue; 0x44 = 68 decimal. The calculated packet length must be 68 bytes length exactly if I understand well (and match every post conditions before this line). I believe some false positive are possible. What about improving the predictable packet filtering mechanism ? ARP packets are not the only predictable ones, SYN/ACK/RST/FIN TCP packets are also predictable. I would be pleased to have feedback for this. I could rewrite the filtering mechanism and make a standalone filter code. Thanks. b0nk.

08-24-2004	#74 (permalink)
b0nk Registered Member Join Date: Aug 2004 Location: Paris, France Posts: 8	Hi back, After playing with aireplay code, I discovered few things. I analysed manually my capture file with ethereal (which is far more useful to analyse packets than tcpdump ), to search for some recurrent patterns. I had a look at broadcasted queries. I found many packets of 118 & 368 bytes (raw) length. I found that the usual 68 bytes check (original aireplay source) had a tendency to give non optimal results. Explanation : At first, usable IVs received with traffic injection are quite good, but after 50K packets, usable IVs are more and more rare, reaching its limit after some time. By replaying 118 & 368 bytes packets, this behavior seems to be more tolerent. I think it's certainly has a limit, but possible usable IVs reduces slower than the 68 bytes filter. I also added 3 features I found useful for aireplay : - Hexadecimal dump of selected packets - Possibility to repeat a specific packet - Set length check manually More testing is needed, if someone want to try the code, let me know ! Feedback appreciated ! Bye.