Check out the original Atomic Data Security Advisory here.
Welcome to the first video blog in the Atomic Data video blog series. My name is Andrew von Nagy, and I'm an Enterprise Architect. Today, I'd like to discuss with you the recent WiFi vulnerability that was announced this week known as KRACK, or the Key Reinsertion Attack.
I'd like to provide a high-level overview of the attack and what it's impacts are, and what remediation steps you can take. At the end of this video, I'll have additional technical information for those who are interested in knowing what actually is involved in the attack. Look forward to future video blogs from the Atomic Data series.
The WiFi exploit that was announced earlier this week is known as KRACK, or the Key Reinsertion Attack. This attack leverages a flaw in the WiFi-protected access or WPA2, which is the security protocol that WiFi uses to encrypt and secure communications between a client and the access point. The net result of this attack is that there is a possibility that the attacker can decrypt a very few frames at the beginning of a WiFi client's association to the network. This means that they can potentially try to leverage this flaw to attack client sessions that leverage other vulnerabilities, such as TCPs ... session hijacking, or things like that.
It's important to understand that this attack does not result in the attacker being able to fully decrypt WiFi traffic, reveal any WiFi network passwords, or allow the attacker to gain your User credentials on your network. It's a very limited attack, so the attacker can only really gain access to a few frames early on in the WiFi client session.
The other thing to know is that Android and Linux have a particular vulnerability that is unique to those client systems with this attack whereby the attacker could potentially gain access to all client traffic on the network from those devices. Pay particular attention to which devices you have on your network. If it's Android or Linux devices that are on your network, you may want to pay particular attention to how to remediate those or work around those issues.
Remediation from this attack and those vulnerability really requires patching of the client systems and the access points. There actually 10 related vulnerabilities in this, in the research, that was released. Nine of those are patched by a patching client systems. One is specific to wireless access points. There are some work arounds, and those involve AP patching on the infrastructure side, which can help mitigate those client issues when they're connected to your network. But, it's not a complete work around. It will only help when those clients are on your network. If they go to other networks, they could still be vulnerable.
Known impacts? I talked a little bit about Android already. Android and Linux systems use an open-source software package called WPA Supplicant, which is the library that implements the encryption key handling for those clients. These clients are especially vulnerable because they don't handle the attack very well, and actually install all zeros encryption key, which means essentially there's no encryption coming from the client to the access point when they start sending traffic for that session that has been attacked. You want to pay particular attention to patching and working around Android and Linux clients on your network, if you have any.
Second, Apple iOS, macOS, and tvOS, have been patched already in beta releases of those codes, and those operating systems, so look for public patching to be released for those systems in the coming weeks. Microsoft systems are also a patch. They were patched on the October Patch Tuesday, on October 10th. This vulnerability was released on October 16th, so the patches actually came out prior to the public disclosure of the vulnerability.
A large amount of thanks and credit should be given to the security researcher who responsibly disclosed this vulnerability to the manufactures back in July, allowing us to have patches, day one, of this disclosure. Remediation steps are patching those clients. The work arounds that you should be thinking about patching your APs right away.
Several access point manufacturers, the large ones in the Enterprise space, Cisco, Aruba, Aerohive, Ubiquity. They have all patched their systems already, and those patches are available, so go look at those release notes for the fixed code versions. Get those scheduled to be installed during your next maintenance window, if possible.
Some other work arounds that you can look at. This is a good time to review security and compliance within your organization from a process and procedural level up in total. Since this doesn't allow an attacker to fully decrypt traffic, except for the Android and Linux clients, what you really looking at is this attack being leveraged as a jumping point to start looking for other vulnerabilities in those client sessions. So, review your application architecture. What sensitive applications are running on those devices and how do those applications communicate? Are they using secure protocols, like https, or TLS, or some other application layer of security with encryption? If they are, you're likely okay. It's not a huge threat to your environment. If your clients are using unsecured protocols for Enterprise applications, that may be another story, and you may want to look at other work arounds.
Review your network defenses. Wireless intrusion prevention systems can easily detect this attack. It leverages identifying the attackers access point that may be spoofing your own access point in a honey pot or evil twin scenario. Those are very easily detected, and very easily mitigated by most wireless network infrastructures and wireless IPS systems.
Also, look at your network firewalls, your network segmentation, to see what access these devices have on your network, and whether or not you can restrict or limit their access on your network.
Also, review your security and compliance procedures in general. How do you handle incident response? What policies do you have in place for use of these devices on your network? Do you enforce those policies through systems in your network? Do you provide any awareness training to your users on this attack or on security in general? How to handle personal devices or BYOD devices on your network?
This is something that Atomic Data can help with. We provide consulting in this area for customers to mature their security policies and enforcement, and provide awareness to their users. If you need help in this area, definitely reach out to Atomic Engineers. We're available 24/7 to help mitigate this issue. Also, from a more strategic standpoint, to help consult with you on security practices in general.
With that, I'd like to turn over to a little bit more technical content on how this attack is actually exploited. I mentioned earlier that it relies on a vulnerability in WiFi-protected access or WPA2. What happens when an attacker uses ... leverages this vulnerability is they're sitting as man in the middle between the client and the access point. What they try to do then is once the user has authenticated the network, or if they're using a pre-shared key, either way, after that kind of data is established, they try to negotiate a unique encryption session between the access point and the client. The attacker sits in the middle of this conversation, and actually disrupts the conversation and tries to force the client to reinsert the encryption key that was negotiated, and reset a packet number, or a packet counter.
What this does is even though both sides of the conversation have the same encryption key, they'll actually rely on a packet number that increments with every packet sent over the network so that the key stream that's actually used to encrypt the data is different for every frame. This is very important encrypt ... cryptographic term, so that no two frames are encrypted with the exact same key stream. When they are encrypted with the same key stream, it can become trivial if you have two frames with different content with the same key stream to try to reverse engineer what the content of those frames are.
That's how an attacker can really decrypt very specific frames at the start of a conversation, where a client thinks that a key has been fully installed, start sending traffic across the network, but the AP does not have awareness that that key has been fully installed by the client because the attacker in the middle has blocked that part of the communication. So, what happens is the access point tries to re-install, re-message the client to install that key. The client has already started sending data. They get that response from the AP, and they actually reinsert the key, and start that packet number counter again. They've had multiple different data frames then that could be sent with the same packet number at the very beginning of an application session.
This really most likely impacts very well-known frames, like DHCP, address resolution protocol, or TCP send packets to set up application sessions. These are really the well-known, guessable content and frames that could be used to reverse engineer and decrypt those frames. Then, the attacker would be looking to leverage the data in those frames to hijack application sessions through other vulnerabilities.
The mitigation to this actually is when we patch the clients and the access points, we're actually patching the state machine in the WiFi driver so that they actually don't try to reinstall those keys. Therefore, we protect the integrity of those key streams by never sending frames with duplicate packet numbers in the same key stream.
This has been video blog one, the Atomic Data series. I hope it's been useful for you. Stay tuned for future videos in this series. Thank you