1

As operator of an important AP, e.g. Stack Overflow developers' office building, can I:

  • Disconnect everybody.
  • Change the AP shared key through Ethernet media.
  • Securely distribute new key to wifi clients. *Monitor 802.11 AP for ANY ANY deauth messages. If I get any start at step 1.

Would that work?

  • 1
    I think you are missing the understanding of how the attack works. Why issue the PSK again? The attack doesn't care about the PSK and you could look for deauth messages but changing the PSK wouldn't achieve anything. If you are worried about having your insecure channel intercepted its better to ensure all clients use TLS or VPNs for as much of their communication as possible. At this stage there is no known practical attack so I think you may be over exaggerating your threats, when an attacker would likely take a different path. – ISMSDEV Oct 23 '17 at 14:49
  • @ISMSDEV If I change the psk new attacks have no way to get that unless they attack again my traffic is secure again. If I watch all my trafs and ensure nobody has deauthed since changing psk there is no way attacker can have new key into ciphertext. – Andyz Smith Oct 23 '17 at 14:57
  • 2
    The attacker doesn't care what your key is. He can still decipher the session of any wifi client connected with your Access Point without having knowledge of key. The attacker can use this method to decipher messages: security.stackexchange.com/a/89841/118310 – defalt Oct 23 '17 at 15:28
  • @defalt No I change the psk at the AP the nonce repetition used to clue into the ciphertext is obviously ineffective. Traf is secure until the attacker can force and intercept a 3/4 handshake and get some nonce repeats to clue to ciphertext. – Andyz Smith Oct 23 '17 at 15:40
  • 2
    Even if you keep on changing the PSK every hour, the attacker can still decipher the session of your wifi clients without knowing the session key. Android and Linux devices are more vulnerable because they start using zero encryption key when KRACK is initiated. – defalt Oct 23 '17 at 15:56
3

Changing the PSK has absolutely no effect on KRACK. KRACK doesn't give an attacker access to the PSK. KRACK is an attack on the process that exchanges the PTK/GTK between the client and the AP. A successful attack will allow the attacker to calculate the PTK much more easily (or in the case of very broken clients set the PTK to all 0's). This will happen no matter what the PSK happens to be and changing the PSK doesn't change this attack in any form.

If you believe a connection between client and AP is compromised, simply disconnecting the client and reconnecting is sufficient to generate a new PTK. Just make sure that connection isn't subsequently attacked and compromised as well.

If you want to protect your "high value targets," you should:

  1. Patch both the AP and the clients.
  2. Don't rely on a single layer of encryption, especially one that only protects from the client radio interface to the AP radio interface.
  3. Enable 802.11w to prevent deauth/disassoc attacks in the first place.
  • Ok i got it psk is not seeded into ptk. Is there someway i can go to the router and deny any new connections. So after a physical sweep of the premises allow new connections then once everybody i want is connected i tell them dont disconnect or im gonna do physical sweep again. And then i just turn off new connections, preventing any attacks on 3\4 handshake. – Andyz Smith Oct 24 '17 at 0:54
  • @AndyzSmith, no idea as we have no idea what equipment you are using, software version, how anything you have is configured or anything else about your environment. However wireless clients disconnect all the time for a variety of reasons (reboot/sleep/hibernate, some power save operations, roaming if you have more than one BSS in the ESS, etc) so your proposed process seems less than ideal and far too manual to be safe and efficient. It would be much simpler to patch, use VPN and/or use/configure equipment that enables the use of 802.11w. Then no downtime whenever anyone disconnects. – YLearn Oct 24 '17 at 1:20
  • Yeah i agree now i gotta go patch the bosses windows (tm) 95 point of sale merchant terminal. If i get lucky the hd will crash. – Andyz Smith Oct 24 '17 at 1:24
  • @AndyzSmith, hopefully that was tongue in cheek. After all, Windows 95 isn't safe period, whether you are exposed to KRACK or not. An OS with an end of support date over a decade and a half ago (and prior to 802.11i - WPA/WPA2) can't be considered secure in any shape, fashion or form. – YLearn Oct 24 '17 at 1:29
  • Ok that covers it. Do you get paid to do this? How do you know all this and are they upset you give freebies to stack? – Andyz Smith Oct 24 '17 at 1:46
1

Even if you actively monitor new handshakes, deauth frames and rogue AP in wireshark to identify the attack, you still can't prevent attacker to initiate KRACK on your clients.

Actually changing the PSK and ask your clients to disconnect once you identify the attack is helpful to the attacker and not for you because attacker is also monitoring the handshake and you are giving him an opportunity to block message 4 of the handshake.

Once message 4 is blocked, the AP will resend message 3 and nonce will be reset. In case of Android and Linux using wpa_supplicant v2.4/2.5 the Temporal Encryption Key also set to zero encryption key.

Changing PSK will automatically ask your clients to reauthenticate and now attacker can intrude in the handshake without making any efforts to deauthenticate your clients.

  • Yeah good info. I can however clear the physical plant which is expensive and disruptive but effective. Then i can set an automatic alarm on any disconnect , anybody drops their connection, i drop the whole network and freeze financial. Clear the plant, do a test connection, monitor for frame 3\4 interference and if all clean single attempt connections i start allowing plaintext CC#. – Andyz Smith Oct 24 '17 at 11:58
  • Ok let me stop you, just patch everybody. – Andyz Smith Oct 24 '17 at 12:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.