Kemparaj Praneeth 4-way hand shake, 4-way handshake, OWE KEY Generation, OWE MIC, OWE MIC Generation, OWE MIC verify

Opportunistic Wireless Encryption – Packet Injection – Replay Attack

Go through the below link to understand the working of OWE.

Opportunistic Wireless Encryption

This post is about doing the replay attack on the OWE AP and observe how the AP behaves.

Below are the two test scenarios that I have done.

  1. Doing a Replay Association Request with OWE Public Data.
  2. Inject the Association Request Public Data with JUNK data [All Zeros].

Test Scenario 1 : Doing a Association Request Replay

Here we will capture the successful Association Request frame and then we will do the replay the same Association Request again, and we will check the behavior. Observe the below Association Request Frame from a successful OWE handshake. Now we will replay the same Association Request again.

This image has an empty alt attribute; its file name is image-51.png
Figure 1 : Association Request From Successful Handshake

Now what we do is , we have captured the Association Request frame , and now we will inject the same packet again from an attacker client, lets see what we will see in the sniffer captures.

Observe the Replayed Association Request Frame, you can differentiate real and replayed frame based on the Frame number from the Figure 1 and Figure 2.

Figure 2 : Replayed Association Request Frame

When the Association Request is replayed , AP gives the response back with the Association Response with the public Info. After the public key exchange is over, both the AP and Client will generate the PMK.

Here in the replayed frame Attacker client replayed the previous Successful Association Request frame and client will not be able to connect to the AP. Because the AP will generate the different Private keys every time client connects. So, the different PMK every time. So, the Connection to the AP fail.

So where does AP knows that Client should not be given Access?

We can guess this , because it is going to be in the EAPOL handshake, At the Message 2/4. Because the Generated PMK is different in both the AP and Client. So that we will see the failure at the 2/4 Message. MIC fails here , so the M2 Message will be failed.

Check the below sniffer capture to check for this behavior. It fails at the Handshake Message 2/4.

Figure 3 : OWE Replay Attack at the Sniffer Capture

Observe the below DeAuthentication Frame that is sent by the AP after multiple EAPOL 2/4 handshake failure.

Figure 4 : Deauthentication Sent by AP after multiple EAPOL 2/4 Failures

Test Scenario 2 : Inject the Association Request Public Data with all Zeros.

Here, we will check whether AP is Accepting if we send all Zeros in the public data, I just changed the Public data that is being sent in the Client with all the Zeros. AP seem to be replying it with the Association Response.

Observe the below sniffer capture to check the Association Request frame with all Zeros.

Figure 5 : Association Request with Public Data all Zeros

Here also, we see that EAPOL Handshake failure , because I have changed the packet that is being sent in the air. So, the AP and Client will generate the different PMK. And the AP finally sends the Deauthentication to the client after multiple handshake failures.

Observe the below Sniffer capture for this.

Figure 6 : Packet Capture for JUNK Association Request

Observe the below Deauthentication Frame that AP has sent after EAPOL failures.

Figure 7 : Deauthentication Frame from AP to client

This post is just know the behavior of the OWE AP, when attacker sends the manipulated data.