In response to recent reports a vulnerability in some popular WiFi chips can be leveraged to partially decrypt user communication and expose data in wireless network packets, cybersecurity experts offer perspective.
In response to recent reports a vulnerability in some popular WiFi chips can be leveraged to partially decrypt user communication and expose data in wireless network packets, cybersecurity experts offer perspective.
Information Security Buzz (aka ISBuzz News) is an independent resource that provides the experts comments, analysis and opinion on the latest Information Security news and topics
Researchers from ESET have identified yet another widespread privacy concern related to faulty WPA2 implementations this time in chips from Broadcom and Cypress. This attack has some similarity to the KRACK attack which took the infosec community by surprise in 2017. Both attacks can potentially allow nearby attackers to gain access to information which should have only been sent after being securely encrypted. In the case of Kr00k, the researchers found that the affected wireless NIC implementations would insecurely send queued data after being disassociated from the network.
At the end of the day though, although this is a very interesting attack, it is not something to lose sleep over. As shown in the Kr00k publication, most of the sensitive data attackers are likely to obtain is going to additionally be encrypted by TLS as it should be. Vulnerabilities like KRACK, Kr00k, or Dragonblood are all excellent reminders of why HTTPS Everywhere is important.
I\’m normally a skeptic on most announced vulnerabilities. Most are too over hyped. This one isn\’t. This one is serious and I\’m glad it was discovered and responsibly disclosed. Anytime you have an encryption key set to all zeros it\’s not a good thing. In this case, \”leftover\” data that was waiting to be retransmitted after a premature disconnect event accidentally gets re-transmitted using essentially no encryption key. It\’s a case of putting the horse before the cart. The designers didn\’t appropriately take into account what happens during a disconnect event when there is still data waiting to be re-transmitted. What they should have done is wait until the new connection and associated encryption key is established before re-transmitting the waiting data. Instead, they accidentally allowed the re-transmit to happen while the key was zero\’d out waiting for the new association and encryption key to be established. It\’s literally a case of 2 being in front of 1. Luckily, whitehat researchers found it and responsibly notified the vendors. We, of course, will likely never know if any malicious groups knew about it and abuse it. But it\’s strange and specific enough that it might have escaped earlier, private, malicious detection. If not, even though the bug is a big limited and specific…it\’s limited to packets waiting for re-transmission after a disconnect, malicious actors could have easily created a tool that artificially forced that condition over and over, and the end-user would have likely not noticed or only thought their data connection was being slow…which is something that happens all the time, not due to malicious causes. So, if malicious attacker software took advantage of the flaw it could have been used to accomplish malicious data interception. One big offsetting mitigation is that most Internet connections containing confidential information (e.g. browser sessions, logons, emails, etc.) are now encrypted by HTTPS by default, so even if the packets were eavesdropped on the data-portion of those packets would have likely been encrypted anyway. All the attackers would get is the meta-data around the data packet, like header information, domain names, IP addresses, etc. And that\’s huge built-in mitigation. But at the same time that inherent mitigation often isn\’t perfect. Not all data is encrypted and protected by default, so there would likely be edge cases where confidential data and information would be leaked and if someone malicious was involved, could be something to worry about. This is a small, specific, but a serious flaw that I\’m glad the guy guys found and responsibly reported.
Multi-Channel MITM attacks against consumer-grade Wi-Fi equipment limited protections and most do not have the commercial available safety features of enterprise business. The attacks are easy for Kali Linux newbie or software from hacking sites to gain access. For example, anyone can purchase a book such as the latest copy of Kali Linux Wireless Penetration Testing Beginner\’s Guide. This is a step-by-step instruction guide to get the kcrackattacks-script tools installed and working. Written in the fashion of “Windows for dummies”. Guards against these kinds of attacks, such as unKRACK, are very easy to utilize and bypass. Vendors rarely update their firmware fast enough and the “hackers” are continuously updating their methods and finding the latest possible advantage to expose a weakness. Consumers left to the capabilities of mobile device management administrators or vendors, will rarely update smartphones, tablets, or IoT devices. They solely rely on these updates. Yet, the typical user is oblivious to the threats posed to such devices. Turn on auto-update from you software mobile phone to get these updates as they are distributed.
Kr00k, as was KRACK, is another nail in the coffin for WPA2 and all of its previous versions. WPA3 has proven to not be ready to handle the sophisticated threats that are being developed by bad actors. Organizations that demand network-layer security are left again at the whimsy of the threat communities and trusted insiders. Attack detection capabilities must now start to link devices to people. Every IoT device must have a responsible owner who knows the limitations of patching measures and other defenses for each device under his or her use. When security operations see consumer grade devices they can easily view or access sit and create undesirable actions to people with the device. This can only be stopped by disallowing personal or consumer-type devices on their wifi or LAN networks.