2

On wireless network running under WPA2 protocol, the communication between a client and the AP is encrypted using a session key (calling it that way, but if there's a more exact term I'd be glad to edit it) that is exchanged between them during the 4-way Handshake (which checks if said client is in possession of the PSK).

This session key is unique for each client connected to the AP. I'm assuming that statement since when an attacker is sniffing a network, he needs to have the handshake of each client if he wishes to decrypt every clients communication with the AP. So even if you're connected to said network, you won't be able to decrypt someone elses communication with the AP, since your session key is a different one (unless you happen to capture the 4-way handshake of the other client).

During a MiTM attack using ARP spoofing, you are already connected to the AP, but you don't have the other clients session keys. Once you poison their ARP cache, they will start sending the packets meant to be sent to the AP to your machine. The question is, since they still believe they are talking to the AP, won't they encrypt the packets using the session key that they exchanged with the AP during connection?

I ask that because experimenting (on my own network) I didn't need the 4-way handshake to see the decrypted traffic on the attacking machine, which I believed I'd need. I was wondering if maybe the session key is attached to the MAC address, so once the victim starts talking to your MAC, even though it believes you're the gateway, it will not encrypt the traffic with the session key it was using before.

Grant Miller
  • 205
  • 2
  • 3
  • 11
murphsghost
  • 91
  • 6

3 Answers3

4

Firstly, in order to do ARP poisoning you have to be connected to the wireless network you're going to poison responses on. You may already know that, but your question doesn't indicate that you know that's a requirement, so I wanted to make sure that it was clear. As for your answer:

Simply put, ARP poisoning works because ARP works. The only thing that changes is that the value of the responses sent by the attacking machine are faked. ARP replies are implicitly trusted, and because they expire, they need to be refreshed periodically. Attackers leverage this implicit trust to send fake responses. If the details of the 4WHS were needed for ARP, no one (real or attacker) would be able to communicate ARP replies.

HashHazard
  • 5,105
  • 1
  • 17
  • 29
  • I edited the question to make it more clear. I understand how ARP poisoning works, but I'm a little confused on how during my experiments I could intercept unencrypted traffic (without needing the 4WHS) during the MiTM. Even though I'm already associated to the AP, wouldn't I need the *session key* shared between the victim and the AP to decrypt the traffic? Maybe I'm misunderstanding some concepts of the WPA2 protocol itself? – murphsghost Aug 22 '16 at 19:52
3

By way of ARP poisoning you may be able to route packets through your machine and place yourself in the middle. However, you need to capture a 4whs in order to be able to crack the PSK and actually decrypt said traffic. You are correct in stating that encryption happens at a lower portion of the layer. As a result, without a 4whs you will only be able to see encrypted traffic between the victim client and the AP.

In your scenario there are two possibilities.

Wait, making sure to periodically inject the spoofed ARP packets into the network in order to circumvent possible ARP cache time-outs in hopes of capturing another handshake when the victim eventually reconnects.

Force Deauthentication

Sending disassociate packets to the victim client in order to force another WPA handshake that you can potentially then capture.

Take a look at this entry in the aircrack docs.

aireplay-ng -0 [# of deauths] -a [AP MAC] -c [Client MAC] [interface]

This previous post is relevant to this discussion as well.

EDIT

After your rewrite of the question, your scenario is more clear to me.

Brute forcing a WPA session isn't confortable or trivial. However, there are tools that have modules to automate the cracking process(some possibly behind the scenes?). Besides the above mentioned authentication scheme, I am not aware of any other vulnerable components of WPA2 that you could've possibly exploited "in passing".

With the information available, the most likely explanation is an oversight on your end. That is, you indeed performed the attack and lost recollection, or you possibly mistook the session in question for another.

If you have the evidence to review the session and/or replicate, by all means get back to us.

I hope this helps.

Community
  • 1
dotproi
  • 346
  • 1
  • 5
  • I'm not sure how this answers the OP's question. He asked **how** ARP poisoning works without knowing the details of the 4WHS. The answer is that ARP poisoning works regardless of whether the details about the 4WHS are known or not. Your answer seems to be showcasing ways to obtain the handshake. – HashHazard Aug 22 '16 at 13:15
  • The question in essence is "why would you be able to perform a mitm attack without capturing a 4whs?". My answer is, you need to capture a 4whs in other to later be able to decrypt traffic and perform a complete mitm attack. I then suggested two methods. Hope this clarifies. – dotproi Aug 22 '16 at 13:24
  • Yes it does, and I see you amended your answer. Nice work, I removed the down vote. – HashHazard Aug 22 '16 at 17:38
  • Your answer seems to fit what I believed was a requirement during the MiTM through ARP poison attack. I believed you had to wait until you had a 4WHS (even if you're already associated with the AP) to decrypt the traffic being intercepted and forwarded. But I didn't seem to need it at all, which is what is making me confused! I understand how can I get a 4WHS but I don't understand how come I didn't even need it during my experiments. – murphsghost Aug 22 '16 at 19:55
  • @dotproi, I'm sorry, I don't recall the WPA session timeout setting. There was something different on the network though: both computers were connected to a WiFi Range Extender configured with WPA2, while the real gateway wasn't configured with WPA2 (only MAC filtering). But even that doesn't seem to explain the results, since in practice the WiFi Range Extender was behaving as the AP (different SSID and BSSID and further redirection to the real gateway) and I could capture the 4WHS form the attacking computer, which means WPA2 was the protocol used while connecting to the Range Extender. – murphsghost Aug 23 '16 at 06:49
  • I removed the previous comment so as to not introduce confusion by making a statement that requires way too much research/evidence to back it up in this format, that way we can at least ensure this post is not misleading to future readers. – dotproi Aug 23 '16 at 07:22
  • @dotproi, I found a PCAP file of one of the experiments and stated a few theories about what's going on in an answer. I'm choosing your answer as the accepted one though, since you took the effort to go a little further on trying to figure out what was happening and also because I'm not sure about my own answer being correct. Take a look at it and tell me what you think. Thanks! – murphsghost Aug 23 '16 at 19:19
0

This isn't a definite answer, but I believe it could be pointing in the right direction.

I found a PCAP file of one of my experiments, which I can't share because of the file size (over 40.000 packets) and presence of potential sensitive data. Along the things I noticed, the following seems really pertinent to the discussion:

Even though the capture starts from before I connected to the access point up to the end of the ARP spoofing attack, the only 4WHS present was my own. The victim didn't repeat the 4WHS during the whole attack. However the traffic was completely unencrypted.

The illustration below represents the attack scenario (ignoring the fact the AP is a WiFi Range Extender). The black lines are the normal traffic flow and the red lines are the result of the MiTM attack:

NetworkSketch

Once the HostA (attacker) connects to the AP it receives a Pairwise Transient Key (PKT1). The same happens when HostB (victim) connects (PTK2, which is a different key). Those keys are used to encrypt the traffic between HostA and the AP and HostB and the AP. I believe the PTK is associated with the MAC address, so HostA knows it needs to use PTK1 to encrypt data with the MAC CC:CC:CC:CC:CC:CC as destination and the AP knows it needs to use PTK1 to encrypt data with the MAC AA:AA:AA:AA:AA:AA as destination. Same applies to the HostB-AP communication (using PTK2).

Once the ARP table is poisoned the traffic from HostB to the "AP" doesn't go to the MAC CC:CC:CC:CC:CC:CC, so it doesn't use the PTK2 to encrypt it. The same happens with traffic coming from real AP to the attackers machine: Since the MAC isn't BB:BB:BB:BB:BB:BB the AP doesn't use the PTK2 to encrypt the messages.

This backtrack forum thread (ARP-Poisoning MIT on WPA2) also seems to point there is no need to have the WPA2 4WHS information to intercept the decrypted traffic on such an attack.

I plan on further reading the whole WPA2 RFC to see if I find some concrete information about this, but so far that's my theory on what's happening.

I'm choosing @dotproi answer as the accepted one, since he went a little further on trying to figure out what was going on.

If someone has a source that can confirm my theory (or confirm it's incorrect) please share it!

murphsghost
  • 91
  • 6