5 Minutes on the WPA2 KRACK Vulnerability


The WPA2 KRACK vulnerability can be boiled down to one main aspect – forced nonce-reuse resulting in an attacker's ability to decrypt messages and 'manipulate' data through man-in-the-middle attacks on Wi-Fi access points.

How Wi-Fi Works

WPA2 is the general protocol adopted for Wi-Fi networks where a four-way handshake is used to identify and establish a connection between the supplicant (the user connecting to Wi-Fi) and the authenticator (the Wi-Fi access point they are connecting to). This four-way handshake is encrypted using (AES)-CCMP.

When a user tries to connect to a Wi-Fi access point, the 'password' they use to authenticate their access is known as the Pairwise Master Key (PMK). This establishes a symmetric protocol where both the authenticator and the supplicant know the value of the PMK.

The communications protocol between the supplicant and the authenticator is as follows in the simplified Four-Way Handshake as depicted in Figure 1.


Figure 1


Four-Way Handshake Break Down

1. The Wi-Fi Access point sends the supplicant, 'r' with an 'Authenticator Nonce' (ANonce). This is the authenticator initialising the four-way handshake with the supplicant.

2. The supplicant, upon receiving the message, sends back 'r' along with a 'Supplicant Nonce' (SNonce). 

3. The authenticator increments the 'r' to demonstrate that the authenticator and the supplicant are communicating within the same message thread and also sends a Group Temporal Key (GTK) which was pre-installed in the session and used to encrypt the data frames.

4. The supplicant now has enough information to generate a 'PTK' also known as a 'Pairwise Transient Key' which a collection of operational symmetric keys used to encrypt the session in the following Wi-Fi session between the supplicant and the authenticator. The PTK is made up of:
  • PTK = (PMK, ANonce, SNonce, AP MAC, S MAC)
The keys within the PTK are:
  • Key Confirmation Key – used to prove the possession of the PMK
  • Key Encryption Key – for distributing the Group Transient Key (GTK)
  • Temporal Keys - Used for encryption
5. Upon installation of the PTK – the supplicant sends the authenticator an acknowledgement to demonstrate they've received the last message and thus, begins the session.


The Vulnerability

In Figure 2 below, we can see that each time a PTK is installed, each time the supplicant sends the Wi-Fi access point data – the data frame is encrypted using the established PTK with a nonce starting a '1'. This is because, in the WPA2 protocol, for each session – the nonce will increment from 0 to 247.

Figure 2


The KRACK attack exists because of the following two weaknesses in the protocol:
  • Every time message 3 of the four-way handshake gets sent to the supplicant, the supplicant will reinstall the PTK
  • Every time a new PTK is installed, the nonce that's used in the encrypted session will return to 0
To elaborate on the second bullet point – the encryption method used in WPA2 is AES-CCMP. AES is the encryption algorithm and CCMP is the mode of operation. CCMP stands for Counter-Mode CBC-MAC Protocol and the primary weakness in this mode is that it operates in a similar fashion to a stream cipher where nonce reuse allows an attacker to derive the encryption key – breaking the encrypted protocol. Nonce reuse turns this mode of operation into a form similar to ECB encryption, where the same input f(x) will yield the same resulting y.




How the Attack Works

In Figure 3 below, assuming the attacker has physical proximity to the access point and is man-in-the-middling access point connections the attacker will:
  • Not forward the supplicant's acknowledgement of the (r+1, GTK) to the authenticator, which forces the authenticator to send 'Message 3' or (r+2, GTK) again
  • This forces the supplicant to reinstall the PTK which resets the nonce back to 0
  • The attacker then forwards the acknowledgements from the supplicant – establishing the session
  • The attacker waits for the supplicant to send another encrypted data frame
  • The attacker now has two encrypted data frames using the same nonce
Figure 3

For more resources regarding this, please have a read of Mathy Vanhoef's paper.


Comments

Post a Comment

Popular posts from this blog

Forensic Analysis of AnyDesk Logs

Image
Most threat actors during ransomware incidents utilise some type of remote access tools - one of them being AnyDesk. This is a free remote access tool that threat actors download onto hosts to access them easily and also for bidirectional file transfer.  There are two locations for where AnyDesk logs are stored on the Windows file system: %programdata%\AnyDesk\ad_svc.trace %appdata%\Anydesk\ad.trace The AnyDesk logs can be found under the appdata located within each users' directory where the tool has been installed. Forensic analysis of these logs reveal interesting pieces of information inside the "ad.trace" log: Remote IP where the actor connected from File transfer activity Locating the Remote IP Connecting to AnyDesk Inside the "ad.trace" log you can grep for the following term "External address" and this should reveal the following line pasted below. I have redacted the IP for privacy's sake: info 2021-02-04 23:25:10.500       lsvc   9988  
Read more

Successful 4624 Anonymous Logons to Windows Server from External IPs?

Image
If you see successful 4624 event logs that look a little something like this in your Event Viewer showing an ANONYMOUS LOGON, an external IP (usually from Russia, Asia, USA, Ukraine) with an authentication package of NTLM, NTLMSSP, don't be alarmed - this is not an indication of a successful logon+access of your system even though it's logged as a 4624. If your server has RDP or SMB open publicly to the internet you may see a suite of these logs on your server's event viewer. Although these are showing up as Event ID 4624 (which generally correlates to successful logon events), these are NOT successful access to the system without a correlating Event ID 4624 showing up with an Account Name \\domain\username and a type 10 logon code for RDP or a type 3 for SMB. You can double check this by looking at 4625 events for a failure, within a similar time range to the logon event for confirmation. The reason for this is because when a user initiates an RDP or SMB c
Read more

How to Reverse Engineer and Patch an iOS Application for Beginners: Part I

Image
So you want to reverse and patch an iOS application? I got you >_< If you’ve missed the blogs in the series, check them out below ^_^ Part 1: How to Reverse Engineer and Patch an iOS Application for Beginners Part 2: Guide to Reversing and Exploiting iOS binaries: ARM64 ROP Chains Part 3: Heap Overflows on iOS ARM64: Heap Spraying, Use-After-Free  This blog is focused on reversing an iOS application I built for the purpose of showing beginners how to reverse and patch an iOS app. No fancy tools are required (IDA O.o), it's just you, me & a debugger <3 The app is a simple, unencrypted Objective-C application that just takes in a password and the goal of this is to bypass the password mechanism and get the success code. This blog post will focus on reversing/debugging the application and will not cover aspects of static analysis. The reason I wanted to write this is because I realised this topic is confusing for a lot of people and I wanted to try and write a blog that a
Read more