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

Problems with capturing other device WLAN traffic

0

Hey,

I know this question gets asked a lot but im lost and I need it for a presentation tomorrow so I have to ask.
Im trying to capture the traffic of my phone on my laptop which runs Linux Mint, both are in the WLAN network.
I've already have monitor mode enabled, according to the wiki page: I ran sudo airmon-ng start wlan0 which worked (it showed a table with the message "monitor mode enabled on mon0"). I've also entered my WLAN key (mykey-myssid) in the IEEE preferences field as a WPA2-PWD key. Then I started to capture mon0. It didn't work, I filtered "http" and nothing showed up when I browsed the net with my phone. I also started wireshark with sudo.

Help is really appreciated, thanks for your time! I hope this question wasnt too dumb

asked 17 Jan '16, 10:11

Nakroma's gravatar image

Nakroma
11●1●2●5
accept rate: 0%

  • Have you captured any packets at all?
  • Have you used http as capture filter or as display filter?
  • Have you restarted the phone (or logged it off the WiFi and on again) before starting the capture?
(17 Jan '16, 10:21) sindy

sindy Yes, I capture a lot of packets. I used as a display filter (the one above the packet list). And I just relogged the phone into the wifi and tried again, but no http packets are being captured.

(17 Jan '16, 10:25) Nakroma

In that case, either something is wrong with the way you've configured the WPA password in Wireshark, or the web page you've visited from the phone was not plain http but https, so there was double encryption, one for the wireless transmission (between the phone and the AP) and one for the phone to web server transmission. Can you see any packets if you apply a display filter tcp.dstport == 443 instead of http on the capture?

If you want more help, you have to post your capture file somewhere, provide a link to it here, and give the WPA password here as well. To do so, you'll probably prefer to change the WPA password before capturing, so that you wouldn't publish the one you use normally.

(17 Jan '16, 10:40) sindy

sindy That could be possible. Nothing shows up with tcp.dstport either. The site I visited is not https (just checked). Here the capture file: www.filedropper.com/capture_6 My WPA password is YJHGBQXC and my SSID is UPC2323467

(17 Jan '16, 10:54) Nakroma

Are you really sure you have logged off and on the WiFi network from the Samsung phone after starting the capture? The easiest and most reliable way to do so is to disable the WiFi completely and then enable it again. As @Christian_R has pointed out, the EAPOL handshake (which happens when the phone is logging in to the WiFi) is missing in your capture.

(17 Jan '16, 11:12) sindy

Ah I misread, I restarted it before the capture. I tried it again, going into the wifi after starting the capture. I checked, the EAPOL packets are there, but still no WiFi/TCP.dstport stuff. Heres the new capture file: www.filedropper.com/capture_7

(17 Jan '16, 11:20) Nakroma

This time it works for me... have you added the PASSWORD:KEY as wpa-psk or wpa-pwd type to the IEEE80211 key list? wpa-pwd is correct, with contents YJHGBQXC:UPC2323467. If you did it wrong, don't forget to remove the previous item, and better save the capture file, exit Wireshark and open the capture file again. The key list is saved automatically between Wireshark runs, to the profile, no need to care about it.

(17 Jan '16, 11:40) sindy

It works for you? Thats weird. Heres a screenshot of my key list: http://epvpimg.com/0D6Ae.png

(17 Jan '16, 11:52) Nakroma

Lol never mind, I missed the enable decryption field. I feel retarded. It actually works now! Thanks a lot :)

(17 Jan '16, 11:55) Nakroma

Could you please check "enable decryption" in the window from which you open the key list (seen at your screenshot above the key list window).

(17 Jan '16, 11:55) sindy

Yeah I just noticed it too lol. Thank you very much, works perfectly

(17 Jan '16, 12:05) Nakroma

Yes, that was it. However, what I don't like are two points:

  • while the packets from the Samsung to the Technicolor (UPC) box are just fine and now as you've enabled the decryption, you can see the http requests and other stuff in that direction, the packets from the Technicolor box to the Samsung have a wrong Frame Check Sequence and so Wireshark does not decode them. I assume the phone was normally showing the web pages, so either the FCS is actually correct and Wireshark doesn't calculate it properly, or the Samsung (and all of your other equipment connected to the AP) ignores the wrong FCS. Worse than that for the moment, no combination of Assume packets have FCS and Validate the FCS checksum if possible protocol preferences makes Wireshark decrypt those packets.

Therefore I hereby ask whether I may use the capture & the password:ssid information to file a bug at Wireshark? Because it is hard to believe that this error would be outside Wireshark.

  • the password and SSID you've given seem to be the default ones from the sticker on the box. If this is your usual setting, then any of your neighbours can use your internet connection, because someone has published a software enabling to determine the password from the SSID for these Technicolor boxes which use UPCddddddd (seven digits) as default SSID.
(17 Jan '16, 12:14) sindy

Yeah you can. And thanks for making me aware of that security leak

(17 Jan '16, 12:16) Nakroma

Done... and my apologies, I really wrote you should restart the WiFi connection before starting the capture in my very first comment, which was of course wrong. The reason why it is necessary to capture the EAPOL handshake is that the WPA password is not used to encrypt the complete traffic but only to encrypt the EAPOL handshake, which is an exchange of the actual session keys which are randomly generated for each new session.

(17 Jan '16, 13:30) sindy

Hey sindy, I researched a bit about the UPC thing. Are you sure theres actually a whole program to do that? Any article I found said you'd have to brutforce the password

(18 Jan '16, 09:02) Nakroma

I hope I won't get a ban for life for posting such a thing here, but the source code of that SSID->default password converter was still available at http://haxx.in/upc_keys.c five minutes ago (and called "password recovery tool").

Up to the local (Czech) online media, which have drawn my attention to the issue, two device types are affected: TC7200 (Technicolor) and UbeeEVW3226. The MAC address prefix in your capture indicates that yours is Technicolor, but not necessarily a 7200.

If you call trying out which of the 8 generated passwords is the correct one a "brute force attack", then OK, you need brute force :)

(18 Jan '16, 13:44) sindy

Someone has even taken the effort to make it a web application...

https://upc.michalspacek.cz/UPC2323467

And OK, it is not 8 candidate passwords - depending on the frequency band you've activated at the AP, it is 18 passwords to try for 2.4 GHz and 27 for 5 GHz, because it seems that the manufacturing series (which the attacker cannot find from the SSID) also plays a role.

(19 Jan '16, 06:08) sindy

Alright, thanks for your help :)

(19 Jan '16, 07:28) Nakroma

Coming back for details about your laptop, because the core developer of the wlan dissector says that it looks as if the packets from the router were really corrupt. As the phone obviously liked them, the only place other than Wireshark itself where they could be corrupt is the wireless card and its driver used in monitoring mode.

So can you please state what vendor and model it is, and if you know that, what wireless adapter it uses and what driver for the wireless adapter you have used?

(10 Feb '16, 15:11) sindy

Sure! Its a Samsung NP300E5C. The network adapter is Qualcomm Atheros AR9485. No idea what my driver is tho, it only shows my graphics driver in the manager.

(10 Feb '16, 15:48) Nakroma
showing 5 of 20 show 15 more comments

2 Answers:

1

To lift the plain answer up from the chain of comments:

It is not enough to configure the table of decryption keys properly and to capture also the EAPOL handshake, it is also necessary to make sure that the "enable decryption" checkbox in the IEEE 802.11 protocol settings is ticked.

answered 19 Jan '16, 06:39

sindy's gravatar image

sindy
6.0k●4●8●51
accept rate: 24%

1

You have to capture the four EAPOL packets, before you can decrypt the WLAN traffic.

As it is described here: https://wiki.wireshark.org/HowToDecrypt802.11

WPA and WPA2 use keys derived from an EAPOL handshake, which occurs when a machine joins a Wi-Fi network, to encrypt traffic. Unless all four handshake packets are present for the session you're trying to decrypt, Wireshark won't be able to decrypt the traffic. You can use the display filter eapol to locate EAPOL packets in your capture.

In order to capture the handshake for a machine, you will need to force the machine to (re-)join the network while the capture is in progress. One way to do this is to put the machine to sleep (for smartphones and tablets, "turning off" the machine puts it to sleep) before you start the capture, start the capture, and then wake the machine up. You will need to do this for all machines whose traffic you want to see.

answered 17 Jan ‘16, 11:03

Christian_R's gravatar image

Christian_R
1.8k●2●6●25
accept rate: 16%

edited 17 Jan ‘16, 11:07