This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

802.11 decryption doesn’t always work, even with the full EAPOL handshake

0

This is a complex question and I don't expect an answer, but I thought I'd throw it out there for ideas.

I live in a fairly dense wifi area (7-12 APs visible). I'm using a TP-Link TL-WN722N USB plug in monitor mode. I am using a capture-filter on only my BSSID which reduces the capture by more than an order of magnitude:

dumpcap -i $IF -f "(wlan addr1 $BSS_LQ63F && dir tods) || (wlan addr2 $BSS_LQ63F && dir fromds)" -w bssid.cap

This works fine and I hope to add to it for more filtering. Note that I do not filter frames with no tods/fromds bits (capture keyword "nods") because that increases the traffic considerably (probe, beacon, etc.) 802.11 is fairly noisy.

I'm testing WPA password recovery by injecting deauth packets (5 at a time) to a STA and collecting the 4-way EAPOL handshake. I do this until the entire EAPOL handshake is captured. After this I can decode the STA-AP session (using the WPA PSK.) Usually.

But sometimes when I capture the entire handshake, I cannot decode the session. I compare the frames with a successful decode and there is no significant difference.

I notice this occurs generally at night when there's more streaming traffic so I suspect the card is dropping something. But if I capture all four messages in the EAPOL handshake and it looks similar to a handshake for a successful decode, it SHOULD decode. Is there something more?

asked 29 Apr '15, 09:48

dturvene's gravatar image

dturvene
5115
accept rate: 0%

edited 29 Apr '15, 18:52

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196

Is it possible to post a capture that you were unable to decrypt? Could you please post it to Google Drive or some other cloud service so others could download and view the file.

(29 Apr '15, 10:31) Amato_C

I just uploaded a capture that has the data decoded with my WPA2 key after the 4-way eapol, a capture that does not have data decoded after what appears to me the same 4-way eapol handshake, and a README.txt describing what MACs to look for.

I uploaded to google drive URL:

https://drive.google.com/open?id=0B-UqcU04ccFdfl80dlA5SHh3aDJSRzN3MEE2NkxLQUdTZ3RGWWNqZzRqMFNzbllEbW1Pc2M&authuser=0

(01 May '15, 13:47) dturvene
1

I can see only one diefference. There is a retransmitted frame in the EAPOL sequence. Maybe it is not allowed to have a retransmitted frame in EAPOL message, if you want to decrypt the traffic.

(01 May '15, 15:27) Christian_R

Excellent! It makes sense, sort of (I guess). Thanks so much for the answer.

(01 May '15, 16:40) dturvene

Now I'm wondering. Is the "no retransmission of eapol frames" a 802.1x requirement or a wireshark requirement? I don't see a specific passage in 802.1x. Frame retrans are alluded to in Clause 8. So I think it may be a wireshark constraint.

(01 May '15, 17:03) dturvene

Hi Christian and dturvene - the retransmitted EAPOL message is not the cause of the decryption problem. I have numerous captures that decrypt correctly when EAPOL messages are retransmitted. I have also been able to decrypt WiFi captures when the first EAPOL message is retransmitted one time - similar to the capture provided by Christian.

This appears to be a driver issue. You might want to update your driver and try again. I say that out of experience. I had a similar experience and updating the driver fixed the issue.

(01 May '15, 18:29) Amato_C
1

Then try this file. https://drive.google.com/file/d/0B80gG9wZvGF0Qm9vd09OXzUxVWs/view?usp=sharing

  1. In Wireshark, make sure you have the Wireless toolbar selected. View / Wireless Toolbar
  2. Download file from Google drive
  3. Open the file. Enter the display filter "eapol" - do not enter quotes. You should see EAP message #1 repeated. Also, the file should not be decrypted.
  4. In Wireshark, press the Decryption Keys button on the Wireless toolbar.
  5. Enter a new decryption key: Type = WPA-PWD SSID = D-Link_DIR-820L_5G Passphrase = nac-1234
  6. Press OK and then Apply
  7. If decryption does not occur, go to the Wireless toolbar. Look for the drop-down menu that says Wireshark. Change that to None. Change it back to Wireshark.
(02 May '15, 04:54) Amato_C

Forgot one step. After performing step #3 (eapol display filter), make sure you clear the filter field so you can see the entire capture again.

(02 May '15, 04:59) Amato_C

Amato you are right it worked fine.

(02 May '15, 23:27) Christian_R

@dturvene: What is the WPA passphrase for the posted capture files?

(03 May '15, 14:13) Kurt Knochner ♦

Ugg. I hate myself but I don't see a "Decryption Key button on the Wireless toolbar". I just built wireshark from source on my Ubuntu 14.04.2 LTS - See the about page below. I still have the same decode problem. I cross-verified that the good capture still decodes. I tried the Wireshark/None/Wireshark toggle. I searched for a way to modify the toolbars. I don't think I need libnl. I'm sure I'm missing something obvious.

Here's the wireshark about page:

Version 1.12.4 (Git Rev Unknown from unknown)

Copyright 1998-2015 Gerald Combs <[email protected]> and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with GTK+ 3.10.8, with Cairo 1.13.1, with Pango 1.36.3, with GLib 2.40.2, with libpcap, with libz 1.2.8, with POSIX capabilities (Linux), without libnl, without SMI, without c-ares, without ADNS, without Lua, without Python, with GnuTLS 2.12.23, with Gcrypt 1.5.3, with MIT Kerberos, without GeoIP, without PortAudio, with AirPcap.

Running on Linux 3.13.0-49-generic, with locale en_US.UTF-8, with libpcap version 1.5.3, with libz 1.2.8, GnuTLS 2.12.23, Gcrypt 1.5.3, without AirPcap. Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz

Built using gcc 4.8.2.

(03 May ‘15, 15:38) dturvene

The “Decryption Key button on the Wireless toolbar” is an AirPcap-only, and thus Windows-specific, feature. On UN*Xes, you would enter the keys as a preference for the 802.11 protocol, as per the “How to decrypt 802.11” page in the Wireshark Wiki.

(03 May ‘15, 15:49) Guy Harris ♦♦

@Christian_R - did you try the following in your capture that did not decrypt in Wireshark? 1. Clear all the previous saved decryption keys 2. Enter the SSID and passphrase for the file you would like to decrypt 3. Select Apply. 4. In the Wireless toolbar, look for the drop-down menu that says Wireshark. Change that to None. Change it back to Wireshark

(04 May ‘15, 05:50) Amato_C

@Amato_C Everything went fine with your description. See my comment above.

(04 May ‘15, 06:21) Christian_R

I successfully decoded Amato_C’s Decrypt.pcap file using the given wpa-pwd phrase. I can USUALLY do this with my captures but once in a while it just does not decode. I tried resetting my wpa-pwd, toggling the wireshark/none button, hand-building the latest wireshark.

Thanks for all the advice but I need to move on. I’m going to put this down as a driver issue for the TP-LINK TL-WN722n usb ath9k chipset I’m using.

(04 May ‘15, 11:11) dturvene

An additional point-of-interest. I’m doing large scale captures and using the same deauth/eapol mechanism to get the keys for the device-under-test. Sometimes (again, not always) the original capture file DOES NOT decode the stream to a device. BUT, the stream is always decoded if I do a post-processing display filter on either the device MAC (“wlan.addr eq $MAC_DUT”) or on the BSSID (“wlan.bssid eq $BSSID”).

So this seems to be a good work-around for me. It also suggest it is not a driver problem.

(06 May ‘15, 08:03) dturvene

@dturvene, as requested by @Kurt Kochner above, can you post the WPA passphrase and SSID for the files you posted above so that Wireshark devs can look at them and fix the issue you see?

(06 May ‘15, 08:23) grahamb ♦

The WPA passphrase is 0ctOpu$7PTN (“num 0” “c” “t” “cap-O” “p” “u” “$” “7” “cap-P” “cap-T” “cap-N”). The SSID is LQ63F.

(06 May ‘15, 09:23) dturvene
showing 5 of 18 show 13 more comments


3 Answers:

0

I downloaded both files that @dturvene posted on Google drive. When comparing the WPA Key Nonce field between EAP message #1 and EAP message #3, the following is observed:

  1. bssid-tofrom-good.cap = both WPA Key Nonce values are the same between EAPOL message #1 and message #3, as expected
  2. bssid-tofrom-nodecode.cap = the WPA Key Nonce values differ in the last byte between EAPOL message #1 and EAPOL message #3. In message #1, the last byte is b5, but in message #3 the last byte is b6.

Since the AP is acting as the Authenticator, the WPA Key Nonce is referred to as the Authenticator Nonce (ANonce for short) when the AP sends an EAPOL frame. For EAPOL message #1 and #3, the AP is sending these frames and the WPA Key Nonce is therefore referred to as ANonce. In IEEE-2012 specification, sections 11.6.6.2 and 11.6.6.4 provide the expected values of each field. The ANonce value must be the same between EAP message #1 and EAP message #3. Also the Nonce value is used to generate the encryption keys! Since the ANonce differs within the same capture, decryption fails.

Also, it is interesting to note that the ANonce is the same in message #1 for both files. This is highly unusually since the AP will generate a new Nonce value for each 4-Way Handshake instance.

answered 08 May '15, 10:16

Amato_C's gravatar image

Amato_C
1.1k142032
accept rate: 14%

1

To prove that the mismatching ANonce value between EAP message #1 and EAP message #3 was the cause of the decryption issue, the following was performed:

  1. Modified the ANonce value in EAP message #1 in the "bssid-tofrom-nodecode.cap". The last byte of the ANonce was changed from B5 to B6
  2. Performed Wireshark decryption

The file was properly decrypted.

Files:

Original file with No-Decryption = https://drive.google.com/file/d/0B80gG9wZvGF0ZHNRS1ozelhNaW8/view?usp=sharing

Modified file with Decryption = https://drive.google.com/file/d/0B80gG9wZvGF0T2VsN3pRRHcxZDg/view?usp=sharing

(08 May '15, 10:28) Amato_C

2

In the nodecode trace I can see a different WPA Key Nonce between EAPOL Message (1 of 4) and (3 of 4).

In the other traces I can see, that this information is always the same.

But I do not know if this information is important for this question.

answered 06 May '15, 15:32

Christian_R's gravatar image

Christian_R
1.8k2625
accept rate: 16%

Yes, that seems to be the smoking gun: last octet of the nonce are different. I would have never caught that. Additionally, tshark decodes only the first 24 octets of the 32 octet nonce so I wouldn't have seen it anyway (I prefer not to use the wireshark GUI.)

Having said that, I cannot recreate the inter-handshake nonce problem at this time. I think I need to wait until there's more traffic on my net. But I will more thoroughly set up injection tests for the AP and see how it handles the nonces.

@Amato_C: thanks for the clarification in your comment below! I suggest you move it to an "answer" and I will upgrade and add points.

(08 May '15, 08:20) dturvene

0

The problem was that the capture probably contained EAPOL messages from other WLAN's on the same channel. Wireshark will use the first EAP message to try to decode. So if the EAP message does not belong to the capture of interest, it will not decode.

answered 06 May '15, 08:22

Amato_C's gravatar image

Amato_C
1.1k142032
accept rate: 14%

I send a series of five deauth frames to the device MAC every minute until I see the auth handshake, associate handshake and the four-way eapol handshake. The auth handshake, association handshake and eapol handshake have the MAC of the router, MAC of the device and BSSID of the router.

(06 May '15, 09:44) dturvene

And another great catch by @Christian_R! I downloaded both files that @dturvene posted on Google drive. When comparing the WPA Key Nonce field between EAP message #1 and EAP message #3, the following is observed: 1) bssid_tofrom_good.cap = both WPA Key Nonce values are the same between EAPOL message #1 and message #3, as expected 2) bssid_tofrom_nodecode.cap = the WPA Key Nonce values differ in the last byte between EAPOL message #1 and EAPOL message #3. In message #1, the last byte is b5, but in message #3 the last byte is b6.

Since the AP is acting as the Authenticator, the WPA Key Nonce is referred to as the Authenticator Nonce (ANonce for short) when the AP sends an EAPOL frame. Since the AP is sending EAPOL message #1 and #3, the WPA Key Nonce is the ANonce. Referring to IEEE-2012 specification, section 11.6.6.2 and section 11.6.6.4 provide the expected values of each field. The ANonce value must be the same between EAP message #1 and EAP message #3. Also the Nonce value is used to generate the keys! Since the ANonce differs within the same capture, decryption fails.

Also, it is interesting the ANonce is the same in message #1 for both files. This is highly unusually since the AP will generate a new Nonce value for each 4-Way Handshake instance.

It appears to the ActionTec wireless router is using the same Nonce value between different 4-Way Handshake instances. But then changes that value in the middle of the handshake. Strange behavior from the AP.

(06 May '15, 16:10) Amato_C