Whatsapp Packet Capture

[Zulema Estabrooks]

iwork as a security specialist engineer at a moderate

enterprise.

recently my superiors have asked me to block whatsapp file transfer only(meaning chat would still work).

however i've tried anything using our Fw's but to no avail.

from what i have read on some forums and various sources, i need to url block

mmi.whatsapp

mms and mmv..

i tried doing that yet it didn't seem to help.

i can still upload/download files from both

whatsapp web and the desktop application.

On the firewall, the application description says,

WhatsApp has integrated the TextSecure encryption protocol, which enforces certificate pinning to its most recent update. Due to this we can longer decrypt this application, and it will be added to the SSL exclude list. Policies enforcing "whatsapp-base" will continue to function normally, but policies using "whatsapp-file-transfer" can no longer be enforced.

Hi Thomas,

SNI is the Server Name Identification field present in the Client Hello of SSL/TLS Handshake. It allows the client to indicate the hostname which it is trying to connect. For more information , you can refer to this link.

You will have to take network trace or packet capture to know this information.

We can find multiple videos on youtube on how to find the SNI from a packet capture. You can check this video.

There is a lot of work associated with blocking/allowing URLs, not only for this but for a wide variety of scenarios. It can be tricky sometimes.

My lab experience using the URL Filtering profiles allowed me to block Whatsapp upload of images & videos while allowing the messages to be sent. I am sharing it if it can help.

Also there is an application debug that have described in the discussion below, so if you want to play again outside working hours you can try "Other use case that I know is to see the application shift if there is an issue how the Palo Alto changes the matched application by enabling the "appid" debug. "

-If that is the case you could possibly do some layer7 rules around video and WhatsApp just by reading packet captures of where the individual data is going. In my experience video goes to a different end xx server then chat.

There are 3 AP points (OpenWRT 802.11r /19.7.7) i have installed SQM simple scripts and SQM Luci

There are VoIP SIP telephone and usual smartphones that use WatsUP for calling

How to set up SQM for prioritization VOiP trafic ? Like i dont need no speed limits all devices connect via WiFI but when somone speaking i want that voice streem be prioritized.

Try to find didnt find anything

Assuming you actually need/want/require prioritisation you need to use either simple.qos/fq_codel or layer_cake.qos/cake and then you need to make sure your VoIP packets are appropriately DSCP marked so that they end up in the desire priority tier/tin. I would probably recommend to use layer_cake.qos/cake and maybe even switch from the default diffserv3 DSCP-to-priority mapping to diffserv4.

Make sure you assign static leases (OpenWrt GUI -> Network -> DHCP and DNS -> static leases) to all your VoIP devices, so you can easily find them in packet captures and use iptables rules to mark them.

for incoming VoIP packets from the internet it is very unlikely that they arrive appropriately marked, so you will need tc filters or (maybe in a coming snapshot version of OpenWrt) the qosify application to selectively set the correct DSCPs for your policy.

Can some one tell me if this software is for capturing all the data that goes through my wireless router? If it is, where I could find the instructions to set it up or if it is not, what software could I use to accomplish this? We connect couples Ipads, an Iphone and note3, one laptop and a desktop. I want to be able to capture all the data(websites browsed, email content, facebook, whatsapp messages, etc... Thanks.

The simple answer is yes, Wireshark can capture the data going through a wireless router. If you are interested in capturing over the air (i.e., using a separate laptop/PC to capture WiFi packets) then please read the following Wiki:

I think Wireshark's role is better described as an analyzer of captured data. When it comes to actually capturing packets, usually the main challenge is in getting your system to 'see' the packets you're trying to capture (eg: for your wireless router, the challenge is to get all the packets the router sees in one place where you can perform a capture). Once you have a system that is receiving all the packets you want to capture, many tools (tcpdump, snoop, dumpcap) can do the actual capture itself. The power of Wireshark lies in its ability to help analyze the packets once they are captured.

So, for the task at hand I wouldn't start by asking about wireshark. Rather, start with what is fundamentally a network question (how do I get a system capable of capturing packets in a position in the network where it can receive all the packets that I want to capture).

There are many solutions for that task depending on the network. As mentioned if you have a Wifi router that supports native packet captures, that's one way. Another is "SPAN" ports, or "port mirroring", where a switch will forward all the packets it sees from one or more ports and forward them on to another port (as a "mirror" port) so that a system running Wireshark can capture the packets and analyze them.

So you want to know what that person who is always on their phone is up to? If you're on the same Wi-Fi network, it's as simple as opening Wireshark and configuring a few settings. We'll use the tool to decrypt WPA2 network traffic so we can spy on which applications a phone is running in real time.

While using an encrypted network is better than using an open one, the advantage disappears if the attacker is on the same network. If someone else knows the password to the Wi-Fi network you are using, it's easy to see what you're doing at that moment using Wireshark. It can allow an attacker to create a list of every app running on the device being targeted and zero in on apps that might be vulnerable.

When you use a Wi-Fi network that uses WPA2 encryption, the security of your session is based on two things. The first is the password that's used to generate a much longer number, a PSK or pre-shared key. The second is the actual handshake itself, which has to happen to establish a connection. If an attacker has the PSK to the Wi-Fi network and either observes you join the network or kicks you off for a moment, they can decrypt your Wi-Fi traffic to see what you're doing.

The content of HTTPS websites won't be able to be seen, but any plain HTTP websites you visit or any insecure HTTP requests apps on your phone makes are in plain view. This may not seem like a big deal, but in only 60 seconds, it's easy to learn a lot about the type of device we're monitoring and what exactly is running on it. Also, DNS requests to resolve the domains that apps need to talk to in order to work are easy to see, identifying which apps and services are active.

To pull off this attack, a few conditions need to be met. First, we need the password, we need to be in proximity to the victim so we can record traffic, and we need to be able to kick the targeted device off the network or wait for them to reconnect. We'll open Wireshark and access the menu to decrypt Wi-Fi packets, add the PSK to enable decryption, and wait for EAPOL packets from the targeted device connecting to the network.

To get a feeling for what the targeted device is up to, we'll be using capture filters to highlight DNS and HTTP packets we're looking for. To see a complete list of every domain the device has resolved, we can also look at a summary of resolved domains after the capture is complete. We can use this information to easily pick apart which services are running, even if they're only running in the background and the app hasn't been running in quite some time.

Next, you'll need an iOS or Android smartphone connected to the Wi-Fi network you're monitoring. You can practice this on an open Wi-Fi network to see what you're supposed to see, as sometimes decryption may not work the first time. You'll also need to know the password and network name of the Wi-Fi network you want to monitor. This will allow you to calculate the pre-shared key, allowing us to decrypt the traffic in realtime.

Download and install Wireshark if it's not already installed, and connect to the Wi-Fi network your target is on. If you plan to use a PSK rather than a network key, you should calculate it using the Wireshark tool before doing so, because you may not be able to access the internet during the capture, depending on your card.

Once you have Wireshark downloaded, open it, then take a look at your network interfaces. Before we start capturing, we'll need to set a few things up to make sure the card is capturing in the correct mode.

If you're not connected to the network your target is on, then you won't be able to see any packets because you might be on some other random channel. Wireshark can't actually change the channel that the wireless network adapter is on, so if you're not getting anything, that could be why.

Now that we have handshakes, we can decrypt the conversation from this point onwards. To do so, we'll need to add the network password or PSK. Go to the "Wireshark" drop-down menu and select the "Preferences" option. Once selected, click on "Protocols."

Once this is complete, click "OK" on the Preferences menu, and Wireshark should rescan all the captured packets and attempt to decrypt them. This may not work for a variety of reasons. I was able to get it to work most of the time by ensuring I had a good handshake (EAPOL) and switching back and forth between using a network password and a PSK. If it works, we can move on to the step of analyzing the traffic to pick out apps in use.

To see interesting packets, we'll start with DNS requests. DNS requests are how apps make sure the IP addresses they are supposed to connect to haven't changed. They'll be directed to domain names that usually have the name of the app in them, making it trivial to see which app is running on the iPhone or Android phone and making the requests.

3a8082e126