4

This thread is to continue my previous one, where I was talking about the TCPDump command.

There is still something I don't get. According to this website (and some others), and according to my tests, one of the goals of TCPDump is exactly to intercept and display the communications of another user or computer. So basically it can sniff everything on the network, and when data are not encrypted we should be able to read them.

Please tell me if I am right about the following:

Let's talk about a wireless network where devices A, B, and C are connected to a WiFi access point. A, B, and C are all on the same network, let say 10.11.204.__ where A is 10, B is 20, and C is 30 for example.

Situation 1) In normal times if A wants to communicate with B, it will send out a packet with the IP Address of B in the header. So if the third device, C, is on the same network it will receive the packet addressed to B, but will see that the IP address is different that its own and will drop the packet.

Situation 2) When using TCPDump in the exact same situation (A sends a packet to B, with B IP in the header), C will receive the packet and will see that it is not addressed to him but will not drop it. And we will be able to read any part of the packet that is not encrypted. (So usually it is only the header).

Does it work like that? If it does, I don't understand why I can not read packets on my computer when I surf the web with my iPhone. I have also some issues with certain Android devices, for these devices I can only read "Echo" requests and "Echo" responses.

It is blurred in my mind, I like networking and I would like to understand that point. Thank you.

8

A standard TCPDump, without any modifications to the mode of the Wireless NIC, will not display ALL frames traversing the wireless network. It will only display frames directed at (and capable of being received by) your station. TCPDump is just grabbing the information that is specifically delivered to your station, decrypted, and presented to the OS at the normal Ethernet/IP level.

To listen to ALL frames reaching your station on the wireless network, you'll need have a NIC capable of running in Monitor mode, and then put your NIC into Monitor mode. While in Monitor mode, you won't be able to send traffic, only to observe all frames on the channel. This is done similarly to the following:

iw phy phy0 interface add wlan2 type monitor
iw dev wlan2 set freq 2412
ifconfig wlan2 up

tcpdump -i wlan2

Read the documentation on iw for more information, and also, see this page for some good information on using iw for monitoring, with an example.

As noted by @ylearn in the comments, your station will only be able to capture frames under specific circumstances (Some more obvious than others):

  1. Be in range of the sending station (duh)
  2. Be of the same type as the sending station (single vs multiple spacial streams for example)
  3. Be listening to the same channel/frequency as the sending station (listening to 2.4 GHz channels won't help you capture 5Ghz traffic, etc)

And there are more conditions, but the bottom line is that wireless networks are wireless, so there's no guarantee of delivery of traffic and therefore no guarantee of receipt on your Monitoring station. :)


Now with all of that said, you may have all the frames that are being transmitted, but you would still need to decrypt the frames. This a large topic in and of itself, however the basics are this: the frames that any 802.11 station sends into the air are sent encrypted so that not just anyone can sniff all connections.

Wireshark has a nice intro page on Decyrypting 802.11. I recommend reading that, understanding it, and moving on from there.


Edit to respond to your comments, @phenetas:

First, as alluded to in my response, I was assuming your OS was Linux in my answer so I recommended using iw. If you're serious about learning more about penetrating 802.11 networks, I'd recommend looking into a linux distro such as Kali Linux, which is designed for exactly that purpose. (Use this power only for good please; with great power comes great responsibility, etc, etc.)

However, if you're insistent on using MAC OSX, you have other options as well to put the NIC into monitor mode (including just using Wireshark instead of TCPDump). Some Googling around for MAC OSX monitor mode should help you there.

Finally, I would look into reading more about IP Broadcasts and mDNS (Multicast DNS) as that is what you're seeing initially from the other devices. These are not "intercepted" packets, this IS traffic destined to your device, that is why TCPDump is displaying the packets.

| improve this answer | |
  • 1
    To make your answer more complete, you may want to include that just because a station is communicating to the AP doesn't mean the monitoring station will be able to capture/use the traffic depending on a number of factors including capabilities of the adapter (i.e. a single spatial stream client will not be able to capture a two spatial stream transmission, etc), locations of the devices in relation to each other, modulation/encoding in use, and so on. – YLearn Jul 8 '15 at 18:46
  • @YLearn see if that sounds better. You make a really good point that I didn't list because I considered it obvious, but then again, it isn't if you haven't had wireless exposure. – Brett Lykins Jul 8 '15 at 18:55
  • Thank you Brett it was a pretty clear explanation. It is pretty bad for me as it will be difficult to achieve what I want know. Do you know any other method that could help me ? (I can not turn my card into monitor mode unfortunately). Why can I, during my tests, intercept some messages from some devices while connecting to the access point, and not from some others ? Ex : I have an iPhone and an Android turned off, I turn them on, at this time I can intercept some packets from the iPhone and not from the Android. The packets I get are mDNS type, what is the phone doing then ? Thank you. – phenetas Jul 9 '15 at 1:06
  • @phenetas ahh, after reading your original question, you're on an Apple Mac device correct? They can be put into Monitor mode, just not with iw (that's for Linux). I would recommend that you look into the latest Wireshark development release for Mac OSX for captures instead of TCPDump. It has a GUI and can do much of the heavy lifting of understanding a packet-capture, as well as putting your NIC into monitor mode. – Brett Lykins Jul 9 '15 at 1:45
  • @phenatas, much like your last question, mDNS is multicast traffic. This traffic can be received by all hosts in the area and in 802.11, your client can decrypt it because multicast/broadcast is encrypted with a "shared" key. – YLearn Jul 9 '15 at 2:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.