WPA2 Decryption doesn't always work - sample attached

[Joseph Beshay]

Hi Matias,

Thanks for your quick response to the issue with saving eapol packets last week. I pulled the latest updates and they have resolved the problem. It seems I am running into another bug unfortunately :(

I have a pcap file I saved using wireshark for a client authenticating to a WPA2 network then pinging a host on the network. I managed to use wireshark to decrypt the icmp packets. My goal is to save a decrypted capture file. I am trying to use a File Sniffer in libtins to read and decrypt the packets and write them to a new pcap file. Unfortunately, this doesn't seem to be working.

I have successfully used libtins to decrypt traces from another access point but it doesn't seem to work with this one for some reason. To try to debug this, I made a copy of the crypto.c file from libtins and modified it to write all the packets that hit the decrypt function to another pcap file. Wireshark is still able to decrypt that pcap file so the library doesn't seem to be having problems reading or writing the packets. It seems there is something wrong with the packet decryption code but I could be wrong.

Please find attached the code to replicate the issue; a short program to read the packets and try to decrypt them (DecryptCaptureIssue.cpp), my modified crypto.cpp, the original wireshark capture (wireshark_dslab4213c.pcap), the one written by libtins before decryption(preDecryption_dslab4213c.pcap) and the empty pcap file that is supposed to have the decrypted packets (postDecryption_dslab4213c.pcap).

Thank you,

Joseph

[Matias Fontanini]

Thank you very much for such a detailed bug report. By looking at the pcap file, I can see that there are no beacons captured before the EAPOL key exchange. This is an issue for the WPA2 decrypter.

In order to use the WPA decryption feature, you configure SSID and PSK tuples, and the WPA2Decrypter will examine beacons in order to see which BSSIDs use that SSID. Once it knows that an access point uses that SSID, it will try to decrypt conversations between clients and the AP. However, since there are no beacons in the capture, it can't know that the access point uses that SSID, and therefore it will ignore the EAPOL packets.

If this is the problem, then you should be able to fix it by calling the other overload of WPA2Decrypter::add_ap_data, the one that takes a BSSID as its third argument. So you'd do something like:

// 00:18:e7:f0:61:bf is the BSSID, as reported by wireshark

wpa_decrypt_proxy.decrypter().add_ap_data(PSK, "dslab4213c", "00:18:e7:f0:61:bf");

Could you try that and see if it works? 

Thanks!

[Joseph D. Beshay]

ok. It looks a bit better now however only the packets from the client to the AP are being decrypted. Wireshark manages to decrypt more packets than that (reverse traffic and some ARP messages). The pre and post decryption pcap files are attached for your reference.

Joseph

--
You received this message because you are subscribed to a topic in the Google Groups "libtins" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/libtins/8Ml21-jB7JU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to libtins+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matias Fontanini]

I think the traffic that's missing is probably encrypted using the GTK (Group Temporal Key), which is not supported by the decryption mechanism. I think there should be some changes needed if this was supported (which I think it should), since the GTK has to be updated frequently, so we should be looking for the relevant 802.11 frames. 

To unsubscribe from this group and all its topics, send an email to libtins+unsubscribe@googlegroups.com.

[Joseph Beshay]

I am not an expert on 802.11 authentication/encryption but I doubt this is the case since the wireshark capture doesn't contain any other 802.11 non-data frames. The capture only has the EAPOL handshake followed by data packets and that seems to be enough for wireshark to decrypt all of them. Is the GTK negotiated over separate frames or is it just embedded in the data frames?

To unsubscribe from this group and all its topics, send an email to libtins+u...@googlegroups.com.

[Joseph Beshay]

It took me a few days to learn how exactly WPA works but I have finally managed to fix this issue, a one liner. So here is a summary of what was happening and the solution:
- TKIP packets from the AP to the client were not being decrypted. Wireshark was able to decrypt the exact same packets using only the EAPOL handshake information. No additional packets were captured.
- CCMP and WEP are not affected. Packets are decrypted in both directions.
- The issue is in line 348 of crypto.cpp "const Dot11::address_type addr = get_bssid(dot11);"

The fix is to use dot11.addr2() for the address. The dst hw address is what should be used to generate the key not the bssid. This explains why it could only decrypt packets from the client to the AP but not the reverse direction.

I have created a fork of the library and committed this change here:  https://github.com/joerango/libtins/blob/master/src/crypto.cpp

I found the following book very helpful in the process of understanding the whole WiFi decryption process. Might help someone else later on :)
http://www.amazon.com/Real-802-11-Security-Protected-802-11i/dp/0321136209

Best regards,
Joseph

[Matias Fontanini]

Great! Thank you very much! I used that book to figure out how 80.11 encryption works, too bad I got the address extraction wrong. Sorry you had to figure it out yourself.

Could you make a pull request so I can add those changes to the repository? Thanks!

You received this message because you are subscribed to the Google Groups "libtins" group.
To unsubscribe from this group and stop receiving emails from it, send an email to libtins+u...@googlegroups.com.