0

As I understand, in ARP spoofing (of any kind), there's a man in the middle that intercepts frames from a sender (Alice) by masquerading as a receiver (Bob) and passes this frame to the server by masquerading as the sender.

I also know that in a WLAN, the client device communicates with the access point using a unique pairwise key, therefore devices that capture this traffic cannot see the payload of the frame.

My question: If Alice and Bob are connected via a WLAN, then their traffic is encrypted. Hence, can a man in the middle that executes ARP spoofing read the packet headers somehow? If yes, what are the conditions for that? If no, why?

PS: I came across this tool: Princeton IoT inspector that uses ARP spoofing to captre and read the header information of packets in a WLAN. They claim to use ARP spoofing to capture the traffic and read the IP header info, which is encrypted in WLAN traffic

2

Hi and welcome to Network Engineering

As I understand, in ARP spoofing (of any kind), there's a man in the middle that intercepts frames from a sender (Alice) by masquerading as a receiver (Bob)

The "man in the middle" and "interception" bits are not quite true for the first step. However, a successful ARP spoofing attack and some source-IP faking can turn an ARP spoofer into a man-in-the-middle.

One does not need to man-in-the-middle style intercept (and alter) ARP packets for an ARP spoofing attack [1]. It is sufficient to send (a burst of) fake ARP response packets (or gratuitous ARPs) to a client that just tried to find another system's MAC address (usually the default gateway). If successful, the victim(s) will henceforth use the attacker's MAC address as DstMAC address in their frames which are to leave the local subnet.

By adding some sourceNAT (using either its own or unused IP addresses from the local subnet as srcIP) when sending these frames back out towards the real default gateway, the attacker can ensure that response packets are also sent towards his host. Alternatively: by sending another burst of fake-ARPs towards the default gateway or router, to trick it into accepting a a wrong MAC address for the victim's IP).

Since now both directions of traffic are seen by the attacker, the attacker becomes a man-in-the-middle, and this opens the path to all kinds of evil things, including intercepting and manipulating of upper layer traffic.

In a Wireless LAN, this is possible without decrypting any other station's Wireless traffic, just as long as the AccessPoint's or WLAN Controller's settings permit client-to-client traffic for the given SSID.

This is precisely one of the good reasons to block client-to-client traffic in a public hot spot.

[Addon1 after comment:]

But can the attacker read the information of the frames?

The above assumes that the attacker can successfuly join the Wifi SSID. Any client-to-client traffic in Wifi infrastructure mode (as opposed to ad hoc mode which is barely ever seen anymore) is always hairpinning through the access point.

In that, the pairwise session key is only of relevance to the AP and the given client (attacker or victim); so actually, the AP de/re-encrypts both the frames from/to victims (with key material negotiated with each individual victim) and from/to attacker (with key material negotiated with the attacker).

The attacker will see frames coming from the victims, but encrypted with AP/attacker's pairwise key - no extra effort needed to decrypt them.

Different story if the ethernet frames themselves carry encrypted traffic like IPsec or something with TLS/SSL - but that's further up the stack and out of scope of this question.

[/Addon 1]

[Addon 2]

A device claiming to be able to perform ARP spoofing an MitM attacks in a Wifi network must first be able to join that WiFi (by legitimate means or forced ones), and it must be able to disable/circumvent the SSIDs client isolation feature (if active). Else, there's little chance to play an active role in a WiFi network. Or it may be cabled on a LAN segment or VLAN which is bridged with that Wifi SSID, but then it's just ARP spoofing as if in a LAN, nothing specific to a WiFi.

[/Addon 2]


[1] of course, if the attacker sits in the network path between his victims (usually between end system and default gateway), ARP spoofing can be performed as well. But in that scenario, it is of no interest anymore - both directions of traffic are flowing across the attacker's host; packet interception and manipulation becomes straightforward.

| improve this answer | |
  • But can the attacker read the information of the frames? The tool in the link I provided claims to be able to do so. But if a client has already been in contact with the actual AP (hence set up a pairwise key) then although the attacker is successful in routing the traffic through it, it shouldn't be able to read the content (according to my understanding) – Nht_e0 Jul 29 '19 at 16:05

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.