Follow by Email

Search This Blog

KRACK - a new attack that can decode / break any WiFi

What Is KRACK? KRACK stands for Key Reinstallation Attack. In short, it is an exploit that takes advantage of the WPA2 protocol - the protocol most internet users are currently utilising to encrypt the information they send when online.
Share it:
Key Reinstallation Attack
The 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.

The essence of the attack
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?
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 ;-)
Share it:


Post A Comment: