KRACK – WiFi attack that can decode/break any WiFi

What does krack stand for? Key Reinstallation Attack
krack attack affects all modern WPA2 implementations, and is particularly dangerous on Android 6+/Linux – you can force a WiFi connection to use a session key consisting of zeroes alone … And that’s all because these platforms wanted to be more secure, but that’s a bit further.

Depending on the security model you use, you can: Decrypt the communication, spoof the communication (impersonate the sending packets), inject the packets.

What is krack vulnerability?

The vulnerability is called “KRACK”, also known as “Key Reinstallation Attack”. It exposes a basic vulnerability of WPA2, which is a common protocol used by most modern wireless networks. Attackers can use vulnerabilities to decipher network traffic from WPA2 devices, hijack links, and inject content into the traffic.

The attacker can obtain a master key through the vulnerability, and can access any WAP2 network without a password. Once you get the key, you can eavesdrop on network information.

What is the attack? First of all, on the appropriate replay of certain messages sent between the client and the AP, during the so-called. 4-way handshake, which is the process of communication between two parties, in which, among others, Prove that they know the shared key (which you set by securing the WiFi network) without revealing this key. The process also creates an additional key ( Temporal Key ) that encrypts the communication (ie secures it).

When you re-play one of the 4-way handshake messages, the once-set session key cannot be changed, but – and here’s a big problem – Nonce ( an arbitrary number that will only be used once ) used in communication encryption. Nonce – which is intended to be used only once, is now used the same (because it was reset to the initial value) – it does not look good and leads to the ability to decrypt the communication. In the original, the authors explain this:

As a result, the same encryption key is used with nonce values that have already been used in the past. In turn, this causes all encryption protocols of WPA2 to reuse keystream when encrypting packets. In case a message that reuses keystream has known content, it becomes trivial to derive the used keystream. This keystream can then be used to decrypt messages with the same nonce. When there is no known content, it is harder to decrypt packets, although still possible in several cases (e.g. English text can still be decrypted). In practice, finding packets with known content is not a problem, so it should be assumed that any packet can be decrypted.

Android and Linux – want to be safer – are less secure

Attentive readers may have noticed some contradiction in the paragraphs above, we write that “once the fixed session key cannot be changed”, and on the other hand that on Android or Linux managed to determine the key from the same zeros.
So the above systems, according to the recommendations in the WiFi standard – clean the session key from memory to its so-called. installation.

Vulnerability appears to be caused by a remark in the Wi-Fi standard that suggests to clear the encryption key from memory once it has been installed for the first time.

So at the moment of replaying a piece of communication with a 4-way handshake, the same key is taken (it was not changed!) – but now there are only zero in the memory! So are set to zero.
For the sake of honesty, it is worth noting that Linux or Android are not as user-friendly, but the WPA Supplicant component is often used.

Types of algorithms used and the effects of the attack

The least susceptible is the AES-CCMP mode – it can be “only” decrypted and played again (replay) encrypted communication before. In the case of WPA-TKIP and GCMP, you can also spoof packages on both sides.

against AES-CCMP an adversary can replay and decrypt (but not forge) packets. This makes it possible to hijack TCP streams and inject malicious data into them. Against WPA-TKIP and GCMP the impact is catastrophic: packets can be replayed, decrypted, and forged.

It is also worth mentioning that it failed to show an attack that will play the main shared key (the one that sets up the WiFi configuration).

What is susceptible?

Almost all (though on some systems the attacks are very limited) – such as Windows or iOS because they do not necessarily stick to the 802.11 standards :

Windows and iOS do not accept retransmissions of message 3 (see Table 1, column 2). This violates the 802.11 standard. As a result, these implementations are not vulnerable to our key reinstallation attack against the 4-way handshake. Unfortunately, from a perspective defender, both iOS and Windows are still vulnerable to our attack against the handshake group key (see Section 4).

are susceptible to another, less dangerous, variant (indicated above). Here you can probably only “replay” multicast and broadcast packets.
Summary table for various variants of attack / platform – below:

How to protect yourself from krack attack?

Fortunately, there is only a software update – which simplifies the replay of the 4-way handshake, and after updating our Access Point, unpaid customers can still connect successfully.

But is it enough to patch the AP? Not necessarily, and even more advisable is patching clients (the attack was just done with targeting in non-AP clients )!
Our main attack is against the 4-way handshake, and does not exploit access points, but instead targets clients. So it might be that your router does not require security updates. (…) For ordinary home users, your priority should be updating clients such as laptops and smartphones.

More APs are vulnerable if they are used in client mode (eg as repeaters) or using 802.11r, so once again, it’s better to patch a client (when you last installed updates on your Android?).
Have AP checked and an unpaid customer will help? In our opinion – after analysis of the source material – not necessarily, especially so early after announcing the details of the attack.

Last tasting
OpenBSD has released a “silent” patch much earlier than the co-ordinated disclosure that took place today (which was previously known to be vulnerable). The authors have suggested that during the future update, OpenBSD will receive much later information (closer to the disclosure time).
Mikrotik updated earlier (last week), but probably missed the researcher’s attention – on the other hand a week ago it’s not a tragedy yet 😉

How to use krack attack

From the beginning of the incident to the present, there has been no attack kits and utilization articles for krack vulnerability. Follow the steps. The process is very simple, and the researchers can understand it. It is not recommended for malicious attackers to use, so I do n’t write a fool tou-style tutorial lan. When the user has not updated, I still hope that this article is only used for research (the vulnerability is not so harmful)

Open the terminal:

apt-get update apt-get install libnl-3-dev libnl-genl-3-dev pkg-config libssl-dev net-tools git sysfsutils python-scapy python-pycryptodome

Download file setup and run commands:

git clone https://github.com/NoahhhRyan/krackattacks-test

cd krackattacks-test-research cd krackattacks

chmod 777 krack-ft-test.py

chmod 777 disable-hwcrypto.sh

./disable-hwcrypto.sh

python krack-ft-test.py

Set the network.conf file, in the directory, you need to change the “testnet” in it to the wifi name you want to attack, the password is arbitrary, and it is saved in the suite directory:

Finally execute the following command and try to connect to the target to start the attack and wait for the result.

sudo wpa_supplicant -D nl80211 -i wlan0 -c network.conf

Then you can also attack any wifi, just click connect in the wifi list, you can see the attacker continuously connect and disconnect in the hotspot bar on the Apple mobile phone, here we have tested a wifi, the effect can be the same.

Defense method

To summarize, provide a temporary solution, change the router’s default username, password, and SSID, turn on the firewall, turn off SSID broadcasting, set a separate SSID for your own users, and turn off DHCP completely.