Bugreports for the Aircrack suite, version 2.2betaX

Bugreports for the Aircrack suite, version 2.2betaX

Postby Dutch » Wed Jun 29, 2005 6:05 am

Occasional "Write buffer full." error, and exiting of aireplay during arp replay attack.
Atheros based 802.11b/g card, using MadWiFi drivers pulled from CVS 06292005, and patched with the MadWiFi patch from the first aireplay 2.2 beta.

Restarting aireplay sometimes works, sometimes give the same error.

When it works, it works well, giving me appr. 23000 unique IV's pr. minute.
Managed to detect my test AP's 128 bit wep key within 10 minutes (including fake authentication, chopchop'ing packet , generating an arp packet with arpforge, reinjecting and collecting 203394 unique IV's), when using fudge factor 4 for aircrack.
Admittedly a very easy key used on the test setup (00:00:00:00:00:00:00:00:00:00:00:00:00), but just shows that WEP, even 128bit, as a security measure is FUBAR...

Dutch
All your answers are belong to Google. SEARCH DAMMIT!
Warning. Warning.
Low C8H10N4O2 level detected. Operator halted....
User avatar
Dutch
 
Posts: 6698
Joined: Fri Mar 05, 2004 12:00 pm
Location: City of Mermaids, Denmark

Postby devine » Wed Jun 29, 2005 7:44 am

Dutch wrote:Occasional "Write buffer full." error, and exiting of aireplay during arp replay attack.


Thanks! This can be fixed quite easily I think, by calling usleep and retrying. I hope to release the next beta in a couple of days :)

Dutch wrote:Admittedly a very easy key used on the test setup (00:00:00:00:00:00:00:00:00:00:00:00:00), but just shows that WEP, even 128bit, as a security measure is FUBAR...


Yup. People are starting to use WPA, a good thing indeed -- even WPA1 which has no current flaws if the passphrase is robust enough.
devine
 
Posts: 389
Joined: Thu Jul 29, 2004 10:09 am
Location: Paris

Postby grcore » Thu Jun 30, 2005 4:48 am

I noticed while trying the fake authentication, that other APs respond (other than the one you are attempting the association with) and these packets are picked up by aireplay and arps sent out.
User avatar
grcore
 
Posts: 121
Joined: Wed Aug 11, 2004 4:55 pm

Postby devine » Thu Jun 30, 2005 5:34 am

grcore wrote:I noticed while trying the fake authentication, that other APs respond (other than the one you are attempting the association with) and these packets are picked up by aireplay and arps sent out.


Yes, I've noticed that too. I've added a check in attack 3, so that aireplay filters packets on the BSSID: the option -b will be mandatory.
devine
 
Posts: 389
Joined: Thu Jul 29, 2004 10:09 am
Location: Paris

Postby scope » Fri Jul 01, 2005 3:35 am

Hi!

2 things I noticed:

1.
Grabbed a packet, faked authentication, tried to chopchop the packet.
chopchop and aireplay -4 work, but the keystream differs.
arpforged the chopchop keystream and injected it, produces ivs.
The arpforged packet from the aireplay keystream does not work. Actually that keystream is far smaller than the one chopchop produces.
(tested with pcmcia Netgear ma401ra, prism2_cs on newest auditor).

I´d be glad if the aireplay -4 worked, because I could use my prismgt for chopping then :)
I saved all the packets and keystreams for further reference, well, can produce new ones too, if needed :)

2.
Fake authentication works great on most aps I tested. But I got several ones where it didn´t work. Suprisingly I could associate to the ap by hand (iwconfig eth essid xxxx enc restricted... and so on...).

If I use aireplay-chop in combination with fake authentication it keeps saying it got an deauth packet from the ap and stops, though chopchop does the job in that situation.

hope that helps a bit,
thx,

scope
scope
Mini Stumbler
 
Posts: 5
Joined: Sat May 14, 2005 9:38 am

Postby devine » Fri Jul 01, 2005 4:06 am

scope wrote:Grabbed a packet, faked authentication, tried to chopchop the packet. chopchop and aireplay -4 work, but the keystream differs.


Ok. Could you send me the two keystreams ? And also the original packet and the WEP key if possible.

scope wrote:Fake authentication works great on most aps I tested. But I got several ones where it didn´t work.


Yes, that is a known problem that lies within injection in monitor mode. Basically aireplay can't send ACK frames fast enough, the max. delay is 0.3 ms which is really short. Most APs will let the association work even if they don't receive the ACKs, but others don't.

scope wrote:If I use aireplay-chop in combination with fake authentication it keeps saying it got an deauth packet from the ap and stops, though chopchop does the job in that situation.


Could you also send me the decrypted packet and the keystream generated by chopchop in this situation ?

Thanks!

-- Christophe
devine
 
Posts: 389
Joined: Thu Jul 29, 2004 10:09 am
Location: Paris

Postby devine » Fri Jul 01, 2005 6:02 am

devine wrote:Ok. Could you send me the two keystreams ? And also the original packet and the WEP key if possible.


Had a look at your files. It appeared you used the aireplay keystream and mistakingly named the resulting arp request "arp-chopchop". Similarly, you named the arp forged with the chopchop keystream "arp-aireplay".

The "arp-aireplay" forged packet (created from the chopchop keystream) didn't worked, because the keystream format used by chopchop is different from the keystream format used by attack 4 in aireplay. Hence the different sizes. But if we look closer at the keystreams, they are identical:

Code: Select all
xxd stream-chopchop |head -n 3
0000000: e6fc b500 0c01 0000 b001 0000 0401 0000  ................
0000010: 4701 0000 3701 0000 a301 0000 2701 0000  G...7.......'...
0000020: 9801 0000 f001 0000 b201 0000 0001 0000  ................


Code: Select all
xxd stream-aireplay |head -n 3
0000000: e6fc b500 0cb0 0447 37a3 2798 f0b2 0035  .......G7.'....5
0000010: 3e01 cae6 7f03 56ac aba4 c874 aeee 8b19  >.....V....t....
0000020: 75f7 72be 54c9 e0c5 e282 8787 1a38 d13e  u.r.T........8.>


As of now, one cannot use the chopchop xor mask (keystream) with arpforge.

EDIT: some people reported that chopping with prism54 sometimes hangs; I'm looking into it.
devine
 
Posts: 389
Joined: Thu Jul 29, 2004 10:09 am
Location: Paris

Postby Dutch » Fri Jul 01, 2005 6:27 am

devine wrote:As of now, one cannot use the chopchop xor mask (keystream) with arpforge.


Huh ? That's what I have been doing, when generating my arp packet for reinjecting with aireplay -3.
Worked fine with beta 3, and generated 49K IV's a minute, when injecting with the -x param set to 800.

Dutch
All your answers are belong to Google. SEARCH DAMMIT!
Warning. Warning.
Low C8H10N4O2 level detected. Operator halted....
User avatar
Dutch
 
Posts: 6698
Joined: Fri Mar 05, 2004 12:00 pm
Location: City of Mermaids, Denmark

Postby devine » Fri Jul 01, 2005 7:01 am

Dutch wrote:Huh ? That's what I have been doing, when generating my arp packet for reinjecting with aireplay -3.


Ah, perhaps I haven't made myself clear enough. arpforge is not compatible with the original "chopchop-0.1" as released by KoreK last year.
devine
 
Posts: 389
Joined: Thu Jul 29, 2004 10:09 am
Location: Paris

Postby scope » Fri Jul 01, 2005 7:14 am

devine wrote:Had a look at your files. It appeared you used the aireplay keystream and mistakingly named the resulting arp request "arp-chopchop". Similarly, you named the arp forged with the chopchop keystream "arp-aireplay".

The "arp-aireplay" forged packet (created from the chopchop keystream) didn't worked, because the keystream format used by chopchop is different from the keystream format used by attack 4 in aireplay. Hence the different sizes. But if we look closer at the keystreams, they are identical:


Ok. Tried it again, it worked. Sorry, really confused the different files, versions and stuff.

Thanks!

However the second issue persists:

ap, no client associated.

Two terminals on my desktop:

1. terminal:

aireplay -1 try2hackme -a apmac -h clmac eth2

clmac is the mac of a client usually connected.

aireplay says:

16:28:57 Sending Authentication Request
16:28:57 Authentication successful
16:28:57 Sending Association Request
16:28:57 Association successful

this is repeated every 30 seconds.

2. terminal:

aireplay -4 -a apmac -h clmac -r chop eth2

Will run for a while, successful guessing bytes, then break with:
"Failure: Got a deauth from..." (aireplay.c, line 1905 to 1912)

I noticed that this happens exactly when the other terminal sends a request sequence.
So if aireplay got lucky, guessing all the bytes beetween the 30 seconds auth interval, everything works.
Maybe the two aireplay instances disturb each other?

What does actually work is the following:
Start fake auth, let it auth and associate, immediately stop it again (so it can´t send another request after 30s). Then start aireplay.
My AP keeps thinking for a while that the station is connected, enough time for aireplay to decrypt the packet.

Well, if I associate by hand, aireplay -4 works, too.

I uncommented the above error message, then recompiled aireplay.c.
Now, when terminal 1 does another fake auth terminal 2 breaks with the next error: "Failure: the access point does not properly discard..." (aireplay.c line 1922 to 1928).
If I uncomment this, too, something weird happens:

aireplay -4 stops guessing bytes when terminal 1 send an auth, but will continue to guess for 2 seconds on every auth send after that.
So it kinda reversed now, aireplay guesses only when an auth is send.
This will take a lot of time, but is successful.
Not the way it should be used ;)

The packet I tried to decrypt was just a simple ping to the ap from inside of the network.

Hope this helps,

scope
scope
Mini Stumbler
 
Posts: 5
Joined: Sat May 14, 2005 9:38 am

Postby devine » Sun Jul 03, 2005 9:53 am

Will run for a while, successful guessing bytes, then break with:
"Failure: Got a deauth from..." (aireplay.c, line 1905 to 1912)


Ok, I've added a workaround in beta4. Please try it out.

Thanks,

-- Christophe
devine
 
Posts: 389
Joined: Thu Jul 29, 2004 10:09 am
Location: Paris

Postby King_Ice_Flash » Sun Jul 03, 2005 10:41 am

devine wrote:Will run for a while, successful guessing bytes, then break with:
"Failure: Got a deauth from..." (aireplay.c, line 1905 to 1912)


Ok, I've added a workaround in beta4. Please try it out.

Thanks,

-- Christophe

No, thank you!
"Yeah," said a voice from under the table, "you go to pieces so fast people get hit by the shrapnel."
User avatar
King_Ice_Flash
 
Posts: 2658
Joined: Tue May 20, 2003 11:00 am
Location: WI

Can't Get Fake Authenication to work

Postby 2marshall8 » Sat Jul 09, 2005 12:31 am

I have the mac address of the ap and the client but get the errors below when running this command. Does my nic have to have the same mac address as the client that is associated? It's in monitor mode so I didn't think so. I'm running this version of auditor: "auditor-150405-04.iso". For the attack I am using a Senao 2511 ext-2 using the prism2 wlan drivers. I recently upgraded the firmware on the Senao to 1.8.4 The AP is a Cisco 350 w/11.07 firmware. The client that is associated is using a Belkin 11mbps Wireless Nic. I'm running the command:

Code: Select all
aireplay -1 LETSCRACKWEP -a <mac of ap> -h <mac of associated client> wlan0


The output says this:
Code: Select all
06:33:12 Sending Authentication Request
printk: 63 messages suppressed.
protocol 1900 is buggy, dev wlan0
protocol 1900 is buggy, dev wlan0
protocol 1900 is buggy, dev wlan0
protocol 1900 is buggy, dev wlan0
protocol 1900 is buggy, dev wlan0
protocol 1900 is buggy, dev wlan0
protocol 1900 is buggy, dev wlan0
protocol 1900 is buggy, dev wlan0
protocol 1900 is buggy, dev wlan0
protocol 1900 is buggy, dev wlan0
protocol 1900 is buggy, dev wlan0
06:33:12 Authentication failed (code 13)

It will keep going. that is just the beginning part. I can provide more if you need it. It does say it's "buggy" so I think this reply fits her just fine ;)

On another note I have tried the aireplay arp/replay option and had success but was only bringing in around 1000 IV's every 7-8 seconds. This is quite low for what I have seen. The best I've done with my Senao is 1000 iv's every 3 seconds. that is about 20000 a minute. If you can give me some tips on this as well that would be great.

I appreciate any help you can provide. thanks
2marshall8
Mini Stumbler
 
Posts: 14
Joined: Sun Dec 19, 2004 12:30 pm

Postby grcore » Sat Jul 09, 2005 2:57 am

I noticed that the -3 "classic" attack now requires an associated client MAC (-h), I would not think that this is necessary, rather it should be optional.

It seems the -1 fake association does not work an many APs, and with some it reports successful association but no ARPs are generated.

With the -0 "deauth" function, it would be nice to be able to specify a single AP or BSSID to focus on.

It also appears that I can generate IVs twice as fast witn an Atheros card as opposed to a Prism2.5 card. I may try recompiling the Prism source + patch to see if something in there might be the problem. (there does not appear to be any changes to the driver/patch though).

nice work though!

g
User avatar
grcore
 
Posts: 121
Joined: Wed Aug 11, 2004 4:55 pm

Postby devine » Sat Jul 09, 2005 11:26 am

2marshall8 wrote:protocol 1900 is buggy, dev wlan0


That message is totally benign.

2marshall8 wrote:06:33:12 Authentication failed (code 13)


Code 13 means, "Responding station does not support the specified authentication algorithm". The target AP probably requires shared-key authentication.

2marshall8 wrote:On another note I have tried the aireplay arp/replay option and had success but was only bringing in around 1000 IV's every 7-8 seconds.


Make sure you have RTC support. Also, beta5 (to be released shortly) will have support for injection in monitor mode on hostap, perhaps it'll fix your rate problem.
devine
 
Posts: 389
Joined: Thu Jul 29, 2004 10:09 am
Location: Paris

Next

Return to Unix/Linux

Who is online

Users browsing this forum: No registered users and 1 guest