Problem with MAC filtering

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Enable mac filtering at the AP
2. The Wifite don't accossiate and crack fails
3.

What is the expected output? What do you see instead?
I would expect to see wifite change the mac address of the wlan0 with the mac 
address of the connected client and finish the task!

What version of the product are you using? On what operating system?
Backtrack 4 RC1 and Alfa network 0036h

Please provide any additional information below.

Original issue reported on code.google.com by macris.a...@gmail.com on 27 Sep 2010 at 12:16

[GoogleCodeExporter]

By default, wifite does not change the mac address of the wireless card during 
WEP attacks.  You can enable this feature using the -mac switch -- it's also 
available on the GUI; the "[ ] change mac" checkbox.

Did you enable wifite to change mac addresses? If not, try it with mac changing 
enabled.  If the attack is still unsuccessful, post a comment here (or a new 
issue).

Original comment by der...@gmail.com on 27 Sep 2010 at 3:06

[GoogleCodeExporter]

Whoops, I done goofed.

I tried testing this and wifite did not change my MAC address -- just as you 
said.

This was a bug; pretty sure it's fixed in revision 38.

Also, mac address changing is now default (-mac option is no longer needed).  
If you want to disable mac address changing, use "-keepmac" or "--keep-mac" 
switches, or deselect "change mac" in the GUI.

If this bug still gives you problems, leave a comment and I'll re-open the 
issue.

Original comment by der...@gmail.com on 27 Sep 2010 at 9:11

• Changed state: Fixed

[GoogleCodeExporter]

i tried R39 today and no success and i explain my self...

Usually with MAC filtering you need at least 1 connected client to the AP so 
you can "spoof" his MAC address and therefor perform the ARP replay attack. I 
imagine more or less this is the idea..

The WiFite while tries to authenticate with the access point, it reports that 
wasn't able to authenticate and therefor exists..

I have used in past GRIM Wepa and you could see the targets and if any client 
was connected and while also there mac address wasn't able to be changed auto, 
with the macchanger you could perform the attack...

Original comment by macris.a...@gmail.com on 27 Sep 2010 at 2:06

[GoogleCodeExporter]

ok i think i found the problem...

When you set to search for all targets, there is a timer of 30secs for targets 
to appear...At this mode, the WiFite doesn't detect connected clients (maybe 
you need more time?) so attack fails.

When you set the GUI to select from list you can see that it detects clients, 
and after sometime, it does change the mac address. i will report later if the 
attack works or not.

Original comment by macris.a...@gmail.com on 27 Sep 2010 at 2:16

[GoogleCodeExporter]

attack seem to fail since no IVs are being produced...

Original comment by macris.a...@gmail.com on 27 Sep 2010 at 2:22

[GoogleCodeExporter]

I just tested wifite on my router with MAC filtering enabled; it detected a 
client, changed the MAC, generated IVs, and cracked it within 5 minutes.  
However, I tested it using a *fixed channel*.  When I tested using "*all 
channels*", wifite was unable to detect associated clients, tried to fake auth, 
and failed.

It is difficult to detect clients when scanning in channel-hopping mode.  This 
is because the wireless card is constantly switching channels, so it misses a 
lot of beacons.  You can test this yourself by running airodump-ng both on a 
fixed channel (e.g. "-c 6") and without a fixed channel; the difference is 
huge.  Clients appear much slower and the clients take longer to detect the AP 
MAC address when scanning all channels.

This isn't a bug in wifite or aircrack-ng, but a hardware limitation.

If you are attacking a specific network, you should select the channel you want 
to attack.  I think 30 seconds is a reasonable amount of time to wait for APs 
and clients.  In fixed-channel mode, the wait is reduced to 20 seconds, and 
that is generous.

If you want to listen for more APs/clients, you can use the "select targets 
from list" option and let it run as long as you want -- just like you mentioned 
in Comment 4.

I *would* add an option to select amount of time to listen but the GUI is 
already very crowded and the option list is getting a little long.  I think a 
'wait time' option would be mostly ignored.

--------------------------------------------

In Comment 5, you said no IVs are being produced.  I need more information.

Is this after wifite has changed the MAC address? What attacks did you try? 
What kind of router are you testing on?

Are you able to generate IVs *without* Wifite? Try to manually crack the router 
using command-line tools (airodump-ng and aireplay-ng) to see if you can 
generate IVs without using Wifite.  If you can, what steps/commands did you use 
to generate IVs?

Original comment by der...@gmail.com on 27 Sep 2010 at 6:22

• Changed state: Accepted

[GoogleCodeExporter]

update...

The Wifite seems to have some problem after changing mac address, it doesn't 
generate any traffic or at least doesn't increase IVs. I use the default 
methods taht Wifite has build-in.

With GRIM WEPA i was able to generate traffic and work out the crack and no 
issues at all.

Original comment by macris.a...@gmail.com on 29 Sep 2010 at 10:46

[GoogleCodeExporter]

Can you generate IVs without GRIM WEPA or Wifite, using only the macchanger, 
airodump-ng, aireplay-ng, and packetforge-ng?

If you can not, then this a problem with your wireless card / router.

If you can, what commands do you use exactly?

Original comment by der...@gmail.com on 30 Sep 2010 at 1:40

[GoogleCodeExporter]

yes you should test packet injection is supported for your card

Original comment by illskills1982 on 25 May 2011 at 8:32