WPA attack: details
Based on a hacked WPA topic.
Let us try to figure out what happened and how it might threaten us. Since cryptographic attacks are a thing that requires a lot of specific knowledge to be understood, the article can be considered to be somewhat familiar with the security of Wi-Fi networks.
Well, for starters, you will have to walk a bit on the theory of Wi-Fi encryption protocols. Although impatient and those who are not interested in all this scientific casuistry, it is not forbidden to immediately proceed to the conclusion.
WEP is currently considered obsolete, not recommended for use at all in favor of WPA and WPA2. Still would! Its vulnerabilities are so serious that they allow you to break the key and connect to a secure network in a matter of minutes. How many of these same minutes will be needed depends on the intensity of traffic on the network; the average loaded network breaks down in one or two minutes (referring to this article to the article and to the home page of the main hacker tool for wi-fi aircrack-ng ). WPA / WPA2 themselves are to some extent add-ins over WEP, in the sense that the basic packet format and encryption algorithm (for WPA) have not changed, thus there was no need to change the equipment, in most cases it was enough to update the firmware (it’s more correct to talk not about WPA / WPA2, but about the IEEE 802.11i standard; WPA is part of it, including the TKIP key management and encryption protocol, WPA2 fully implements the standard, including CCMP protocol with AES encryption).
Since the packet formats for all protocols have a lot in common, let's start with the WEP package as the simplest:
')
We are in this package are most interested in the transmitted data (Network Data)
Here IV is the Initialization Vector, the salt needed to create the per-packet key. Data is the actual transmitted data generated by the upstream protocols in the OSI stack (for example, data can be an IP packet). IC (hereinafter we will call this field ICV - Integrity Check Value) is a CRC32 check-sum from Data that serves to check the integrity of data. Data + ICV is encrypted with the RC4 algorithm with the key IV + WEP_key, i.e. obtained by simple IV concatenation and WEP password. The size of IV is 24 bits, the RC4 cipher uses keys of length 64 or 128 bits. This explains why WEP passwords are 5 or 13 characters long (i.e. 40 or 104 bits).
The main WEP vulnerabilities are related to the small length IV, the primitive algorithm for obtaining the per-packet key, the vulnerabilities of the RC4 algorithm itself and its streaming nature.
So, in this picture, what I used to call Network Data comes after the MAC Header (the FCS check sum is not shown here, as in the WEP picture; it doesn’t interest us, since its processing is done at the lower level of the OSI model ). IV is the same 24-bit WEP Initialization Vector, only its meaning is somewhat different, the data structure of the same package has become much more complicated. In order to understand what the presented fields mean, we will briefly review (and there is no time to fully consider the forces and time, and I’m afraid to get bored :-)) the TKIP protocol, which I have already mentioned:
The main session key PTK (Pairwise Transient Key) is a set of 4 128-bit keys used for TKIP to encrypt individual packets in the periods between key changes. Note that PTK is not a WEP password and neither it nor its generation mechanism is part of the TKIP.
The PTK includes 4 keys: one to encrypt data in TKIP (let's call it TK), one to calculate the MIC (and its MTK), and two more so-called EAPOL keys, which I will not touch on. The keys are generated using a WPA password (finally, a password has appeared!), Known to both parties, in the process of a four-step “handshake” ( picture , there is a rather detailed article in English about WPA).
Returning to the previous figure with the structure of the WPA package, we see that everything between the MAC Header and Data is essentially a TSC counter, plus some service fields that serve to protect against weak keys and say that Extended IV is used. TSC is set to zero at the beginning of the session and monotonously increases with each packet transmitted by this device, the 48-bit capacity is enough for ~ 250 trillion packets, which can be considered sufficient considering periodic re-initialization of session keys (as opposed to 24-bit IV in WEP). A unique key for encrypting a packet is calculated from TK, TA (Transmittor Address - MAC address of the transmitter) and TSC using a specific two-phase hash mechanism, which yields a 104-bit string to which WEP IV is added (yes, that very 24-bit Iv) to get a 128-bit key (in fact, the figure about key formation is visual, but inaccurate, meticulous ones can take a look at this one ).
Uff ... What do we have left? Oh yeah, MIC.
It is designed primarily to combat fordating packages. The code is calculated from the data of the entire message (plus the addresses of the transmitter and receiver) even before fragmentation and possible reordering of packets using an algorithm called MICHAEL, which generates a 64-bit signature. The algorithm, in addition to data, uses the key, namely, the aforementioned MTK. Importantly, the algorithm is in a certain sense reversible, i.e. Knowing the data and the MIC signature, you can calculate the MTK key.
The Access Point counterfeit struggle, in fact, as follows: if a packet came with an incorrect MIC (while it is valid for the rest of the signs, that is, it has a valid TSC value and the ICV amount passed the test), a notification is sent to the sender and, if There is a possibility, this event is recorded in the log as an attempt to hack. If within 60 seconds another packet arrives with the wrong MIC, the access point initializes rekeying with this sender. So fake packages with impunity (relatively) can be sent no more than once a minute.
From the impressive list of attacks to which WEP is vulnerable, consider the so-called Chop-Chop attack (from the English chop, a loose translation - “cut a slice”). This attack allows you to learn plaintext messages (ie, these messages before encryption), and hence the RC4 keystream package (plaintext + keystream = ciphertext => keystream = ciphertext + plaintext). The attack uses the fact that the CRC32 check-sum does not go through the requirements of the cryptographic hash function.
In the WEP packet, the last bytes of data (Network Data) are encrypted ICV, i.e. CRC from the message. Let's forget about encryption for a while and consider what happens if we remove the last byte, which we denote as R, from the packet. Let Q be a packet without the last byte, then Q is unlikely to have the necessary remainder (ie, CRC). But it turns out that a certain polynomial M can be added to Q so as to correct the CRC. Substituting first S O = Q * X 8 + R , and then S 1 = Q + M in (2) , it is easy to find that
M = (X 32 ) -1 * (1 + (X 8 ) -1 ) * (P zero + L f ) + (X 8 ) -1 * R
If we go through all the bytes R from 0 to 255 and send them to the network to the access point, we will eventually stumble upon the correct one. To understand that we hit the byte in reality is also not difficult: packages with incorrect ICV are silently dropped as transmitted with an error; if the CRC is correct, we can expect a response packet, for example, in the case of WPA, it will usually be a packet informing about the wrong MIC. But more on that later.
What about encryption? It turns out that the fact that the packet is encrypted does not matter, because RC4 encryption by the algorithm is reduced to XOR data with keystream, but adding M is the same XOR, and since the XOR operation is commutative and associative, it doesn’t matter if you add M to the original data and then encrypt it, or to encrypted data.
The described process can be repeated further, “biting off” a message byte, and theoretically it is possible to decipher a WEP packet of arbitrary length.
Let us turn, finally, to the subject of the article.
So, what happens if you try to apply a Chop-Chop attack to a network with WPA protection?
TKIP basically has 2 tools to protect against such attacks:
The first point is partially on the attacker's hand, because lets you understand when he guessed the next byte. The second is more difficult: indeed, even if we caught an ARP packet sent by one of the devices on the network, Access Point caught it, sending this packet to her again is meaningless, because the TSC is already incremented, plus the first device may have sent more packets, increasing the counter even more. The authors of the attack found a way out in the IEEE 802.11e specification, defining improvements in QoS for Wi-Fi networks. The dry residue here is this: Wi-Fi devices support several bursts of packets (I called them channels above; I don’t say that they really relate to real radio channels), according to one author, Eric Tusa, 4 channels were supposed to be used , in the standard of 8, in reality, the authors found up to 16. Channels are usually not used simultaneously, saving bandwidth for important packets. In an unloaded network, all traffic often goes to one channel, so we will most likely catch the packet on a channel with a high TSC counter, but it is possible to resend it by switching to a less loaded channel. It is important that, again referring to the authors, when sending a message about the wrong MIC channel counter does not increase, so further channels can not switch.
If the network does not support QoS extensions, the attack, in principle, is also feasible if it is possible to prevent the selected packet from decrypting the AP and disconnect the device that sent it from the network.
It is clear that trying to decrypt any long packets by byte per minute is pretty hopeless - the standard Wi-Fi packet has a size of ~ 2300 bytes, i.e. it will take about one and a half days, and during this time either the TSC counter will increase, or the keys will be replaced, or the access point will be scraped, or you will be “fired”. Moreover, having one device, you can break only one package.
Well, the sniffer will not work, let's see what the decryption of short packets, for example, ARP, which can be easily identified by their length (14 bytes) can give us. Actually, the attacker knows most of the contents of the APR packet, namely, the headers and MAC addresses. If you can also make some assumptions about the IP structure of the network being hacked (in a network created from under Windows, for example, you can expect that the IP addresses will look like 192.168.0.x), then there is nothing to guess at all. That is, having guessed 12 bytes of ICV + MIC, the rest can be simply selected using the ICV sum. Hence the figure mentioned in the press in 12 minutes to break.
What next? Having decrypted one packet, the attacker recognizes the RC4-keystream packet (it can only be used until the TSC has changed) and, more importantly, the session MTK - I mentioned that the MIC is reversible, and the key can be set by data and signature. The latter means that before the next key exchange, there is no need to guess the MIC anymore, and, for example, it will take 4-5 minutes to crack the next ARP packet (with the same assumptions about the network structure). Depending on the number of QoS channels, it is possible to use decrypted data to send forged packets from 7 to 15 times (less if the traffic goes through more than one channel), then you will have to “chop-chop” another packet.
If you recall the press reports before the Tuse report, for example:
it is obvious that the colors are "slightly" thickened - in reality it is impossible to read traffic from the AP to the client, and somehow it is not clear that the authors have done such a "mathematical breakthrough" because the chop-chop attack has been known since 2004 ...
Despite the fact that there were allegations of breaking encryption, WPA passwords themselves and even temporary session keys (not counting the MIC key) are completely safe. The attack allows deciphering individual short packets that are being worked on, spending at best 4-5 minutes per packet, and using the results of the decryption, inject a very limited number of equally short packets back into the network. Yes, this seems to be the first serious attack that demonstrated the vulnerability of the TKIP protocol, but the absolute majority are not worried about this. According to Tewez, “if you used encryption only to protect your Internet channel from being used by random people, you are completely safe.” The attack cannot be used either to connect to your home or corporate network, or to track traffic in them.
Nevertheless, theoretically, it’s possible to do minor dirty tricks, such as: “poisoning” ARP (maybe DNS) cache, reading a certain amount of private traffic, Tuse also indicates the possibility to trick some firewalls.
What methods can be dealt with this type of attacks?
Well, first, of course, you can simply switch to WPA2 with AES encryption. The authors also advise to reduce the time of key regeneration by the access point (up to 2-3 minutes, which makes it impossible in principle for the procedures described above) and disable the automatic sending of messages about the wrong MIC in the received packet. Unfortunately, it is unclear whether modern access points provide such subtle settings (I personally have no idea if someone met, it would be interesting to know).
Well, you can hardly say that WPA is hacked. Moreover, I think that while there’s nothing to worry about. However, quoting one of the sources, "now that these two (Beck and Hughes) have opened the door, WPA will surely attract the close attention of thousands of researchers: white, gray and black."
Materials and links
Battered, but not broken (popular and accessible article about the attack)
Article Beck and Tjuza
WPA article
Prezashka (I used a couple of pictures in the article)
aircrack-ng
A good article about CRC and the theory of its hacking.
Article on how to quickly crack WEP and FMS attack in wikredia
Disclaimer
I ask you not to judge strictly, I am not an expert in information security and wireless protocols, or even an amateur, I’m more likely to be interested in :-) And I apologize in advance if I overloaded the article with theory and details.
Let us try to figure out what happened and how it might threaten us. Since cryptographic attacks are a thing that requires a lot of specific knowledge to be understood, the article can be considered to be somewhat familiar with the security of Wi-Fi networks.
Well, for starters, you will have to walk a bit on the theory of Wi-Fi encryption protocols. Although impatient and those who are not interested in all this scientific casuistry, it is not forbidden to immediately proceed to the conclusion.
WEP
WEP is currently considered obsolete, not recommended for use at all in favor of WPA and WPA2. Still would! Its vulnerabilities are so serious that they allow you to break the key and connect to a secure network in a matter of minutes. How many of these same minutes will be needed depends on the intensity of traffic on the network; the average loaded network breaks down in one or two minutes (referring to this article to the article and to the home page of the main hacker tool for wi-fi aircrack-ng ). WPA / WPA2 themselves are to some extent add-ins over WEP, in the sense that the basic packet format and encryption algorithm (for WPA) have not changed, thus there was no need to change the equipment, in most cases it was enough to update the firmware (it’s more correct to talk not about WPA / WPA2, but about the IEEE 802.11i standard; WPA is part of it, including the TKIP key management and encryption protocol, WPA2 fully implements the standard, including CCMP protocol with AES encryption).
Since the packet formats for all protocols have a lot in common, let's start with the WEP package as the simplest:
')
We are in this package are most interested in the transmitted data (Network Data)
Here IV is the Initialization Vector, the salt needed to create the per-packet key. Data is the actual transmitted data generated by the upstream protocols in the OSI stack (for example, data can be an IP packet). IC (hereinafter we will call this field ICV - Integrity Check Value) is a CRC32 check-sum from Data that serves to check the integrity of data. Data + ICV is encrypted with the RC4 algorithm with the key IV + WEP_key, i.e. obtained by simple IV concatenation and WEP password. The size of IV is 24 bits, the RC4 cipher uses keys of length 64 or 128 bits. This explains why WEP passwords are 5 or 13 characters long (i.e. 40 or 104 bits).
RC4 is a stream cipher. Initialized with a key, then produces a sequence of pseudo-random bits with a uniform distribution, called keystream. This sequence can be used to encrypt data (traditionally called plaintext) by XOR operation, the resulting sequence is usually called ciphertext.
The main WEP vulnerabilities are related to the small length IV, the primitive algorithm for obtaining the per-packet key, the vulnerabilities of the RC4 algorithm itself and its streaming nature.
WPA
So, in this picture, what I used to call Network Data comes after the MAC Header (the FCS check sum is not shown here, as in the WEP picture; it doesn’t interest us, since its processing is done at the lower level of the OSI model ). IV is the same 24-bit WEP Initialization Vector, only its meaning is somewhat different, the data structure of the same package has become much more complicated. In order to understand what the presented fields mean, we will briefly review (and there is no time to fully consider the forces and time, and I’m afraid to get bored :-)) the TKIP protocol, which I have already mentioned:
TKIP (Temporal Key Integrity Protocol) implements three approaches to improving the security of the IEEE 802.11 family of radio protocols. First, it is the key mixing function, which combines the secret master key PTK (see below) with the initialization vector before passing it as a key to the RC4 algorithm. Secondly, this is a serial counter (TSC - TKIP Sequence Counter) of 48-bit length, the value of which grows with each transmitted packet. Packets received in the wrong order will be rejected (that is, packets with an earlier TSC will be rejected), which allows you to defend against so-called replay attacks. Finally, this is the 64-bit Message Integrity Code (MIC) security code.
TKIP also implements a rekeying mechanism for changing session keys and ensures that each packet is transmitted with a unique RC4 key.
The main session key PTK (Pairwise Transient Key) is a set of 4 128-bit keys used for TKIP to encrypt individual packets in the periods between key changes. Note that PTK is not a WEP password and neither it nor its generation mechanism is part of the TKIP.
The PTK includes 4 keys: one to encrypt data in TKIP (let's call it TK), one to calculate the MIC (and its MTK), and two more so-called EAPOL keys, which I will not touch on. The keys are generated using a WPA password (finally, a password has appeared!), Known to both parties, in the process of a four-step “handshake” ( picture , there is a rather detailed article in English about WPA).
Returning to the previous figure with the structure of the WPA package, we see that everything between the MAC Header and Data is essentially a TSC counter, plus some service fields that serve to protect against weak keys and say that Extended IV is used. TSC is set to zero at the beginning of the session and monotonously increases with each packet transmitted by this device, the 48-bit capacity is enough for ~ 250 trillion packets, which can be considered sufficient considering periodic re-initialization of session keys (as opposed to 24-bit IV in WEP). A unique key for encrypting a packet is calculated from TK, TA (Transmittor Address - MAC address of the transmitter) and TSC using a specific two-phase hash mechanism, which yields a 104-bit string to which WEP IV is added (yes, that very 24-bit Iv) to get a 128-bit key (in fact, the figure about key formation is visual, but inaccurate, meticulous ones can take a look at this one ).
Uff ... What do we have left? Oh yeah, MIC.
It is designed primarily to combat fordating packages. The code is calculated from the data of the entire message (plus the addresses of the transmitter and receiver) even before fragmentation and possible reordering of packets using an algorithm called MICHAEL, which generates a 64-bit signature. The algorithm, in addition to data, uses the key, namely, the aforementioned MTK. Importantly, the algorithm is in a certain sense reversible, i.e. Knowing the data and the MIC signature, you can calculate the MTK key.
The Access Point counterfeit struggle, in fact, as follows: if a packet came with an incorrect MIC (while it is valid for the rest of the signs, that is, it has a valid TSC value and the ICV amount passed the test), a notification is sent to the sender and, if There is a possibility, this event is recorded in the log as an attempt to hack. If within 60 seconds another packet arrives with the wrong MIC, the access point initializes rekeying with this sender. So fake packages with impunity (relatively) can be sent no more than once a minute.
Chop-chop attack
From the impressive list of attacks to which WEP is vulnerable, consider the so-called Chop-Chop attack (from the English chop, a loose translation - “cut a slice”). This attack allows you to learn plaintext messages (ie, these messages before encryption), and hence the RC4 keystream package (plaintext + keystream = ciphertext => keystream = ciphertext + plaintext). The attack uses the fact that the CRC32 check-sum does not go through the requirements of the cryptographic hash function.
Let me remind you that ideologically CRC is the remainder of dividing the original string S, represented as a polynomial (from X) with coefficients equal to the corresponding bits in its binary record, to the predetermined polynomial P CRC (X), and arithmetic operations are performed in the GF field (2 ) (for more details, for example, on Wikipedia ). However, in this form, the CRC is insensitive to zeroes at the beginning and end of the original line, so in practice special lines are added to the beginning and end (lengths equal to the number of CRC digits), which we denote as L i (start) and L f (end) . Usually both of them consist of 32 binary units. Thus, for CRC32:
CRC = (X 32 * S + L i * X n + 32 + L f ) mod P CRC (1)
where n is the length of S in bits.
It is noteworthy that if we assign the CRC to the right S line, then the CRC from the received line will be constant and equal to the empty CRC line, which we denote as P zero (it is very easy to prove; it’s enough to remember that in GF (2), addition and subtraction are the same and the same operation - XOR), or as a formula
(X 32 * (X 32 * S + CRC) + L i * X n + 64 + L f ) mod P CRC = P zero (2)
In the WEP packet, the last bytes of data (Network Data) are encrypted ICV, i.e. CRC from the message. Let's forget about encryption for a while and consider what happens if we remove the last byte, which we denote as R, from the packet. Let Q be a packet without the last byte, then Q is unlikely to have the necessary remainder (ie, CRC). But it turns out that a certain polynomial M can be added to Q so as to correct the CRC. Substituting first S O = Q * X 8 + R , and then S 1 = Q + M in (2) , it is easy to find that
M = (X 32 ) -1 * (1 + (X 8 ) -1 ) * (P zero + L f ) + (X 8 ) -1 * R
To build a polynomial P in degree 1 means to find such a polynomial P 'that P * P' = 1 mod P CRC , which is always possible, since P CRC is irreducible and polynomials with modulo P CRC operations form a field. By the way, the degree of M does not exceed 32, since M is enough to take modulo P CRC .
If we go through all the bytes R from 0 to 255 and send them to the network to the access point, we will eventually stumble upon the correct one. To understand that we hit the byte in reality is also not difficult: packages with incorrect ICV are silently dropped as transmitted with an error; if the CRC is correct, we can expect a response packet, for example, in the case of WPA, it will usually be a packet informing about the wrong MIC. But more on that later.
What about encryption? It turns out that the fact that the packet is encrypted does not matter, because RC4 encryption by the algorithm is reduced to XOR data with keystream, but adding M is the same XOR, and since the XOR operation is commutative and associative, it doesn’t matter if you add M to the original data and then encrypt it, or to encrypted data.
The described process can be repeated further, “biting off” a message byte, and theoretically it is possible to decipher a WEP packet of arbitrary length.
WPA attack
Let us turn, finally, to the subject of the article.
So, what happens if you try to apply a Chop-Chop attack to a network with WPA protection?
TKIP basically has 2 tools to protect against such attacks:
- Packages with invalid ICV, as I mentioned, are discarded. If the ICV is guessed, but the MIC code is incorrect, the attacker must wait a minute in order not to provoke a key change
- If a packet is received, the TSC counter for this channel (TSC counters exist separately for each channel to which the device can send packets; about channels — a little later) is increased by 1. Packets with a lower or equal TSC are discarded (not sent again). quite accurate: in fact, there is a small window of TSC values, within which packets are accepted, but not the essence)
The first point is partially on the attacker's hand, because lets you understand when he guessed the next byte. The second is more difficult: indeed, even if we caught an ARP packet sent by one of the devices on the network, Access Point caught it, sending this packet to her again is meaningless, because the TSC is already incremented, plus the first device may have sent more packets, increasing the counter even more. The authors of the attack found a way out in the IEEE 802.11e specification, defining improvements in QoS for Wi-Fi networks. The dry residue here is this: Wi-Fi devices support several bursts of packets (I called them channels above; I don’t say that they really relate to real radio channels), according to one author, Eric Tusa, 4 channels were supposed to be used , in the standard of 8, in reality, the authors found up to 16. Channels are usually not used simultaneously, saving bandwidth for important packets. In an unloaded network, all traffic often goes to one channel, so we will most likely catch the packet on a channel with a high TSC counter, but it is possible to resend it by switching to a less loaded channel. It is important that, again referring to the authors, when sending a message about the wrong MIC channel counter does not increase, so further channels can not switch.
If the network does not support QoS extensions, the attack, in principle, is also feasible if it is possible to prevent the selected packet from decrypting the AP and disconnect the device that sent it from the network.
It is clear that trying to decrypt any long packets by byte per minute is pretty hopeless - the standard Wi-Fi packet has a size of ~ 2300 bytes, i.e. it will take about one and a half days, and during this time either the TSC counter will increase, or the keys will be replaced, or the access point will be scraped, or you will be “fired”. Moreover, having one device, you can break only one package.
Well, the sniffer will not work, let's see what the decryption of short packets, for example, ARP, which can be easily identified by their length (14 bytes) can give us. Actually, the attacker knows most of the contents of the APR packet, namely, the headers and MAC addresses. If you can also make some assumptions about the IP structure of the network being hacked (in a network created from under Windows, for example, you can expect that the IP addresses will look like 192.168.0.x), then there is nothing to guess at all. That is, having guessed 12 bytes of ICV + MIC, the rest can be simply selected using the ICV sum. Hence the figure mentioned in the press in 12 minutes to break.
What next? Having decrypted one packet, the attacker recognizes the RC4-keystream packet (it can only be used until the TSC has changed) and, more importantly, the session MTK - I mentioned that the MIC is reversible, and the key can be set by data and signature. The latter means that before the next key exchange, there is no need to guess the MIC anymore, and, for example, it will take 4-5 minutes to crack the next ARP packet (with the same assumptions about the network structure). Depending on the number of QoS channels, it is possible to use decrypted data to send forged packets from 7 to 15 times (less if the traffic goes through more than one channel), then you will have to “chop-chop” another packet.
Conclusion: degree of threat and protection measures
If you recall the press reports before the Tuse report, for example:
There is no need for any additional information.
The researchers were trying to find out how to get them. It makes it a little bit more fun to make it.
www.pcworld.com
it is obvious that the colors are "slightly" thickened - in reality it is impossible to read traffic from the AP to the client, and somehow it is not clear that the authors have done such a "mathematical breakthrough" because the chop-chop attack has been known since 2004 ...
Despite the fact that there were allegations of breaking encryption, WPA passwords themselves and even temporary session keys (not counting the MIC key) are completely safe. The attack allows deciphering individual short packets that are being worked on, spending at best 4-5 minutes per packet, and using the results of the decryption, inject a very limited number of equally short packets back into the network. Yes, this seems to be the first serious attack that demonstrated the vulnerability of the TKIP protocol, but the absolute majority are not worried about this. According to Tewez, “if you used encryption only to protect your Internet channel from being used by random people, you are completely safe.” The attack cannot be used either to connect to your home or corporate network, or to track traffic in them.
Nevertheless, theoretically, it’s possible to do minor dirty tricks, such as: “poisoning” ARP (maybe DNS) cache, reading a certain amount of private traffic, Tuse also indicates the possibility to trick some firewalls.
What methods can be dealt with this type of attacks?
Well, first, of course, you can simply switch to WPA2 with AES encryption. The authors also advise to reduce the time of key regeneration by the access point (up to 2-3 minutes, which makes it impossible in principle for the procedures described above) and disable the automatic sending of messages about the wrong MIC in the received packet. Unfortunately, it is unclear whether modern access points provide such subtle settings (I personally have no idea if someone met, it would be interesting to know).
Well, you can hardly say that WPA is hacked. Moreover, I think that while there’s nothing to worry about. However, quoting one of the sources, "now that these two (Beck and Hughes) have opened the door, WPA will surely attract the close attention of thousands of researchers: white, gray and black."
Materials and links
Battered, but not broken (popular and accessible article about the attack)
Article Beck and Tjuza
WPA article
Prezashka (I used a couple of pictures in the article)
aircrack-ng
A good article about CRC and the theory of its hacking.
Article on how to quickly crack WEP and FMS attack in wikredia
Disclaimer
I ask you not to judge strictly, I am not an expert in information security and wireless protocols, or even an amateur, I’m more likely to be interested in :-) And I apologize in advance if I overloaded the article with theory and details.
Source: https://habr.com/ru/post/44496/
All Articles