Imagine there is a wireless network using WPA2, and an attacker has come along with his wireless card in monitor mode. What will the packets from that network look like? Is any information disclosed i.e Destination/Source IPs/Ports? Or is it all just encrypted? The attacker is not connected to the network.
2 Answers
It doesn't ultimately matter whether the attacker is connected to the WPA2-PSK network or not: if an attacker can capture the 4-way handshake and knows the pre-shared key, it's possible to decrypt all traffic.
Theory
That said, if you just look at individual 802.11 datagrams without analysing their flow any further, they are link layer (L2) datagrams containing link layer information: four MAC addresses.
Those addresses represents the transmitter (TA), receiver (RA), source (SA) and destination (DA) addresses, but their meaning and placement in the header depends on the values of the To DS
and the From DS
bits in the header, as described in the document IEEE 802.11-05/0710r0:
Note that Address 1 always holds the receiver address of the intended receiver (or, in the case of multicast frames, receivers), and that Address 2 always holds the address of the station that is transmitting the frame.
WPA2 a.k.a. IEEE 802.11i-2004 doesn't encrypt these L2 headers, but all the information in the frame body, i.e. everything from network layer (L3) up to application layer (L7).
To address your concerns:
- IP addresses are network layer (L3) information → encrypted.
- TCP/UDP ports are transport layer (L4) information → encrypted.
On the other hand, there's still some information disclosed:
- MAC addresses may reveal the manufacturer of the devices, which could be used for finding possibly vulnerable access points or e.g. IoT devices.
- IPv4 & IPv6 multicast can be detected: although the IP headers including the multicast addresses are encrypted, the destination MAC addresses are standard and known (
01-00-5E-
,33-33-
). - The BSSID associates the datagram to a certain pair of AP & SSID, as an AP as a transmitter and as a receiver is distinguished solely based on the BSSID, and the SSID is typically broadcasted in the IEEE 802.11 Beacon frame. Therefore, the amount of data every device is transmitting can be associated to the network they are using, as well as the timing. E.g. if someone had an IoT washing machine we could identify, we could guess their laundry day.
- Although the SSID might not be broadcasted with the beacon frames, devices connecting to the network will reveal the SSID in probe request frames. Also, computers trying to connect to saved networks will leak this information periodically even when they are not near any access points of this network. E.g. from my home I can guess several companies my neighbours are working for.
To be more exact, the data is encrypted and authenticated, but the 802.11 headers are only authenticated in both CCMP (AES) and TKIP. That is summarized in these two diagrams from 802.11i Overview, IEEE 802.11-04/0123r1:
CCMP MPDU Format
TKIP Design (1) – MPDU Format s
Practice
If you concretely want to see yourself how it looks like in detail, you could e.g.
Monitor a wireless adapter using
airmon-ng
. No need to connect to the network.Capture some packets using
airodump-ng
.Investigate the capture file (
.cap
) using Wireshark.Configure Wireshark for decrypting the WPA2 and inspect the capture again.
Go to Preferences > Protocols > IEEE 802.11,
[x] Enable decryption
and add the PSK key for decryption.Open the (
.cap
) again and let Wireshark decrypt it.
- 16,100
- 5
- 50
- 55
-
Really useful answer. I tried the practice you suggested and after adding the PSK to wireshark I'm able to see all the traffic, but @Pedro mentions that the packets are "encrypted with unique keys per client". How come I am able to see the traffic in plain text? – RandyAnon May 27 '20 at 11:58
-
1That's because you have been able to capture the 4-way handshake, too. The PSK can be used to decrypt the handshake and get the keys from it. That's explained in the first paragraph of my answer. – Esa Jokinen May 27 '20 at 12:03
What will the packets from that network look like?
Lots of 802.11 frames not specific to a particular network, since if you're not joined you cannot tell them apart per packet (you could filter by base station vs list of clients).
Is any information disclosed i.e Destination/Source IPs/Ports?
MAC addresses of the client and base stations, possibly SSIDs (can be forced to be revealed)... I don't think anything else is visible. Certainly no IP addresses or any identifiable network traffic in cleartext.
Or is it all just encrypted?
Yes. Encrypted with unique keys per client. Even if using WPA2-PSK.
- 3,911
- 11
- 25
-
2It's possible to determine the network from the BSSID of the packet, although the possition of the BSSID on the IEEE 802.11 datagram isn't fixed (could be in address 1, 2 or 3), and bind the BSSID(s) to the correct SSID based on the IEEE 802.11 Beacon frame. – Esa Jokinen May 26 '20 at 12:12
-
You can tell that a client is connected to a particular base station. But it could be associated to any of the SSIDs handled by that made station. Which eventually you can list given a bit of time a d a tiny bit of luck. – Pedro May 26 '20 at 14:30
-
Also @esajokinen I would never claim I know the theory in such depth re 802.11 Vs my answer which reflects practical experience. Thanks for that primer. – Pedro May 26 '20 at 14:44
-
1What you suggest would mean that every 802.11 datagram had information on the SSID, which it doesn't: the AP as a *transmitter* and as a *receiver* is distinguished solely based on the BSSID. Therefore: 1) every AP with the same SSID has a unique BSSID and 2) every SSID on a single AP has a unique BSSID, too. In other words, the BSSID associates the datagram both with the AP and with the SSID. – Esa Jokinen May 26 '20 at 14:53
-
Sorry I didn't mean that. SSIDs are uncovered on 4-way handshakes and on broadcasts if enabled. And of course you are right about the unique BSSIDs, I saw it earlier today and didn't notice then. – Pedro May 26 '20 at 16:31
-
No problem – having this discussion gave me some ideas, and I was able to improve my answer with some examples. So actually: thank you, Pedro! – Esa Jokinen May 26 '20 at 16:52