Jump to content

Wpa Handshake Confusion.


dingo_boy
 Share

Recommended Posts

I have a WPA network.

I connect to it with my Asus 036H. No problems. Let's say the MAC is 00:C0:CA:02:DC:3F.

I then change the MAC to 00:C0:CA:04:AC:2D. The OUI is the same. Now I cannot connect.

There is no MAC filtering.

I used Wireshark to inspect the four way handshake. In each case:

a) AP to client

b) Client to AP.

c) AP to client.

d) Client to AP.

In each case:

a) Replay counter 1.

b) Replay counter 1.

c) Replay counter 2.

d) Replay counter 2.

However, the difference was with the nonce values.

The genuine MAC showed that the nonce for packets 1 and 3 was the same.

The spoofed MAC showed that the nonce for packets 2 and 4 was the same but the nonce for packets 1 and 3 was different.

My understanding (http://www.aircrack-...?id=wpa_capture) is that the values for 1 and 3 must be the same for the handshake to complete.

What I do not understand is why spoofing the MAC modifies the handshake? When I remove the ASUS then plug it in (thereby removing the spoofed MAC) and try to connect it immediately works.

It appears that spoofing the MAC changes the identical nonce values to 2 and 4 (which does not work).

Why is this happening? Thanks!

Edited by dingo_boy
Link to comment
Share on other sites

Do you receive any error messages, when associating or authenticating to the access point?

Edited by Infiltrator
Link to comment
Share on other sites

Do you have WPS enabled on the router, and have you ever used it to setup the PC that connects to it, or did you manually set up the NIC and the password configuration for WPA?

Link to comment
Share on other sites

I have WPS set up but I have never used it. I manually set-up the WPA.

I'm not entirely sure what you mean by error messages.

Dmesg showed "reason code 15" which is (according to the IEEE) signfies a "4-Way Handshake timeout".

This would make sense as I was never able to connect and Wireshark shows multiple attempts. However, what I do not understand is why changing the MAC would cause this handshake error?

Link to comment
Share on other sites

Its possible your DHCP lease is still in use on the router for the same IP it tries to connect back with, and as its trying to reconnect the router barfs because it thinks that IP belongs to a different MAC address. Try and disable DHCP on the local workstation, and set a static IP up with your real mac, then connect normally. If that works, then move on to the next test.

Now, disconnect, change your mac on the workstation, but also change static IP to a new IP not in use, like increment by one, and then try with the new mac. That should then work, if it was a DHCP lease issue.

The router may see you trying to connect to the same IP via DHCP, and shutting you out because it thinks the lease is still in use, because the PC you connect from still holds onto the lease data, even though the router should have just issued you a new IP, one or the other might have not released the lease. But this is just a theory. Only way to know for sure, try it. make sure the mac address you fake, is of valid range though. 0-9 and a-f only, hexadecimal, or that will make it fail as well. I know what your first post showed, and that was totally valid, just make sure when testing that they always are.

Also, if the router does workstation name lookups, it might also block for two workstations with the same name and different mac addresses, so might need to spoof your workstation or netbios name as well, depending on the router and what it retrieves for its arp table and IP cache data. I know on some routers, when someone connects via DHCP, I can see their actual workstation name in the routers lan display, so that might be a firewall feature of the router, which in actuality, is a good thing for it to protect against duplicate names that have different mac addresses. if it was the same name and mac, it would of just re-leased the same IP, or released the old one and gave you a new one, possibly with a new IP.

Link to comment
Share on other sites

Thanks for your advice - I have done some more experimentation.

Its possible your DHCP lease is still in use on the router for the same IP it tries to connect back with, and as its trying to reconnect the router barfs because it thinks that IP belongs to a different MAC address. Try and disable DHCP on the local workstation, and set a static IP up with your real mac, then connect normally. If that works, then move on to the next test.

I don't understand this. If I disconnect, change the MAC, then re-connect, surely I am now a 'new' computer so why would the DHCP try to re-allocate me the same IP then get concerned because the MAC is different?

Here is what I tried

I went to my friend's WPA router which I have never connected to before.

I first spoofed the MAC (like in post 1) and I was unable to connect.

I then spoofed the MAC for wlan0 (my laptop's NIC) and I was unable to connect.

I then removed the spoofed MAC for wlan1 and was able to connect.

I then removed the spoofed MAC for wlan0 and was able to connect.

Now, I have no idea why I cannot connect with a spoofed MAC but I do know that Wireshark shows different information for when I am successful compared to when I fail to connect.

This relates to the four-way WPA handshake.

I base my experiences on this page written about the handshake by the aircrack-ng team: http://www.aircrack-...ckets_8_9_10_11

Successful:

Replay counter can start at (for example) 4. So the first set is 4 and 4 then 5 and 5 (then it connects).

The nonce values for 1 and 3 are the same.

The nonce values for 2 and 4 are not the same.

The nonce value for 4 is 0000000000000000000000000000000000000000000000000000

Failure:

The replay counter always starts at 0.

So I might see 0 and 0 then 1 and 1 then 2 and 2 then 3 and 3 and so on (because there is never a connection).

The nonce values for 1 and 3 are the same (as above).

The nonce values for 2 and 4 are the same (different).

The nonce value for 4 is therefore not a string of zeros (different).

What I do not know is why these differences are happening merely because I spoofed the MAC. This happens, as I said, for wlan1 and wlan0.

The only thing I can think of is that the way in which I am spoofing the MAC causes the problem.

Here is what I do under Ubuntu 10.04:

sudo ifconfig wlan1 down hw ether 00:C0:CA:04:AC:2D

sudo ifconfig wlan1 up

The check the change has been made with ifconfig.

I really have no idea what is going on.

All suggestions greatefully appreciated!

Edited by dingo_boy
Link to comment
Share on other sites

My only thoughts on the DHCP part, was some times the OS will cache the DNS info and DCHP lease info, and even though you we're spoofing the mac(not sure what you used to do this) is possible the OS sent the request for the same IP lease, but by default, it should take orders from the router on what address is uses, ie: DORA, or discover, offer, request and acknowledge which is the process of DHCP in a nutshell. If the router sees a different mac trying to use the same IP, it will say its in use already, which is what I was theorizing was happening, and that the OS was actually the one requesting to renew the lease with he same IP, which if we could somehow prove one way or the other, might explain why the router drops the connection. Could also be the router itself somehow doing checks, not sure. Using Wireshark though, you should be able to see everything, not just the 4 way, but also the DNS requests and the DHCP requests, which may shed some light on the situation and why its not working.

By the way, on linux, when using thing sliek dhclient and dhclient3, it creates a semi permanent file with key info in them like DNS servers, IP address to try reusing. I forget the path of where they are, but that more than likely could be the cause. I run into this on BackTrack a lot! Look in /var/lib/dhcp/dhcpd I beleive. I think there are multiple files it could be in depending on what you use, dhclient, dhclient3, or the GUI connection programs.

Edited by digip
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...