Page 1 of 8

Bugreports for the Aircrack suite, version 2.2betaX

PostPosted: Wed Jun 29, 2005 6:05 am
by Dutch
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

PostPosted: Wed Jun 29, 2005 7:44 am
by devine
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.

PostPosted: Thu Jun 30, 2005 4:48 am
by grcore
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.

PostPosted: Thu Jun 30, 2005 5:34 am
by devine
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.

PostPosted: Fri Jul 01, 2005 3:35 am
by scope
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

PostPosted: Fri Jul 01, 2005 4:06 am
by devine
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

PostPosted: Fri Jul 01, 2005 6:02 am
by devine
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.

PostPosted: Fri Jul 01, 2005 6:27 am
by Dutch
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

PostPosted: Fri Jul 01, 2005 7:01 am
by devine
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.

PostPosted: Fri Jul 01, 2005 7:14 am
by scope
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

PostPosted: Sun Jul 03, 2005 9:53 am
by devine
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

PostPosted: Sun Jul 03, 2005 10:41 am
by King_Ice_Flash
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!

Can't Get Fake Authenication to work

PostPosted: Sat Jul 09, 2005 12:31 am
by 2marshall8
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

PostPosted: Sat Jul 09, 2005 2:57 am
by grcore
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

PostPosted: Sat Jul 09, 2005 11:26 am
by devine
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.