Wi-Fi Networks Security Under WFA Certification Restrictions
What Is This Paper About?
In the following paper, I’ll try to describe the major problem of Wi-Fi security protocols perception.
In addition, I’ll display a POC about what can be done about it and maybe a suggestion for how to do it.
Introduction & Why Is This Paper?
Back in 2004, Wi-Fi Alliance (WFA) published a draft of the WPA2 as part of the security certification programs. Wi-Fi Alliance let the vendors certified their products and to announce the industry that they are supporting this new great and important feature -WPA2.
Less than a year after the announcement the unbelievable has about to happen: A security breach! how supersizing. In the new “perfect” protocol updates (802.11i) some serious security breaches have been found.
The most important thing: This security breach will be fixed only 4 years (!!) after it has been published (2009). The point here is that: even if those protocol’s fixes could be released with hard-work/using- a-magic only 24 hours after the security breach has been announced — the required changes are irrelevant. Because, changes in the protocol -even if it’s just an easy patch-, should require a new version of the protocol (802.11w for example) or at least a new version of certification tests for the same protocol (as for example: R1, R2 and R3 certification version for WPA3 with different test plan but with the same title — WPA3).
Vendors as Intel, QUALCOMM, Texas Instruments and others that certified their product and passed successfully all the plan test won’t recall or won’t release a service pack for their certified product to fix some security breach. The only option here is to convince the vendors to upgrade to the new certification version/Protocol and by this close the security breach according to the new Protocol’s “instruction” of WFA. Obviously, not all the vendors will do that gurney to the most protected version.
WFA is trying to deprecate old protocols, for example — WEP is no longer a valid protocol due to security breaches and cannot be certified anymore (WPA2 is on the same way).
Obviously, deprecation of old protocols doesn’t protect devices that already have been certified and are already embedded in Wi-Fi products over the world.
Also if the Vendors that have certified already are committing to the Wi-Fi Alliance not to change the Firmware (lower layer 2) after the WFA has certified their products. In our case, fixing bugs, security breaches or even adding new features later - could be very problematic (and when I’m saying problematic I mean there is basically almost no way to do so).
In the next few sections, I’ll try to demonstrate what is so problematic in the “certification” method. I’ll focus on one of the earliest WPA2 security breaches that have been found and announced.
Deauthentication Attack and Its Implication
Among the long list of security breaches I want to focus on the simplest one but at the same time one of the most important breaches in the Wi-Fi protocol: the Deauthentication attack (published by Joshoua wright back in May 2005).
Deauthentication attack as a security breach, which, believe it or not, was fixed only 4 years after it has been published — in 2009 (as part of the “PMF” -Protected Management Frames-) protocol (IEEE_802.11w-2009).
That means that for 4 years this security breach was embedded into Wi-Fi chips by definition. Vendors couldn’t even think of trying to add protections against this attack because the standard is forcing the chips (through the certification tests that must be passed obviously) to “listen” to the attack (=by “listen” I mean hear the foreign Deauthentication packet and do as it says — to disconnect from the network ).
We all agree that 4 years is too much for a security breach to be announced without the appropriate treatment.
This famous attack only disconnects the Station(s)/AP from the network and by this act, it acutely forces the connection to go through the 4 way handshake all over again — and here’s the party begins.
Just for the sake of understanding here is a part of a long list of WPA2 security breaches starting with a “Deauthentication attack”:
Brute force attack
Evil Twin attack
PMKID attack
KRACK attack
What I’m trying to say here is that even a serious security breach could be unpatched by the WFA for years(!) and even if it has been patched (as the PMF protocol does) it is not so easy to change to cause the Vendors to update existing Wi-Fi chips.
Is There a Solution?
The short answer is: Yes.
But the long answer is:
Technologically? — Yes. Will someone buy it? — I’m not so sure.
I want to present an interesting idea and assumption to deal with it: the need to respond quickly to Wi-Fi threats and to provide to the devices live protection — mostly in important areas (Banks, Companies, Public areas) in a matter of hours/days instead of years.
What Is the Proposal?
Signing, Detection, and Alert Wi-Fi Threats
The idea is to use an external Wi-Fi adapter that was set into “monitor mode” handled by python scripts (I used Scapy), and use it as a “Front guard position”.
The product also is able to make an update over the air for new signed threats (other relevant options except a sniffer will be detailed later in this paper).
The Wi-Fi adapter and his software will do 2 main things:
Detected pre-set (using cloud updates) signed Wi-Fi attacks according to known attack flows
Alert the host/cloud about the specific detected threat and all the details about it as (if possible): attack details, event number, attack name, attacker MAC address, is DBM make sense? time of the attack? and recommendation.
Deauthentication Attack, Detection, and Alert Example:
- Deauthentication attack:
2. Deauth attack detection and alert
Evil Twin Attack, Detection, and Alert Example:
- The attacker performs the attack:
2. Victim fall in the Evil twin trap:
3. The attacker catches user name and “hint” for the password (will be cracked using “asleap”):
4. Runs offline brute-force based on all alphabet (uppercase and lowercase):
5. Evil Twin attack detection and alert:
How is an External Tool Able to Detect Threats?
First of all, I think that concept could work also as an internal tool but this requires the Wi-Fi chips Vendors to let an external code run inside their product, I cant see how this is possible. The real-Time embedded concept is about the perspective of the whole system together.
Giving an external code to run on top of my Firmware Cortex (or any other processor) sounds like bad practice.
I’m not saying this isn’t possible, but probably harder to implement and can’t be implemented without collaboration with some Wi-Fi chips vendor (as TI, Intel, etc).
How to Do It?
If I had to build a perfect solution and not only a POC as I did, I would:
Step 1
List all Wi-Fi possible threats (not only Protocol’s threats but also miss-configuration issues and more).
For example (only for WPA2/3):
- Deauth Attack — Personal & Enterprise, (WPA2/3)
- Brute force attack — Personal, (WPA2)
- Evil Twin attack — Personal & Enterprise, (WPA2/3)
- PMKID attack — Personal, (WPA2)
- KRACK Attack — Personal & Enterprise, (WPA2/3)
- DDOS attack — Personal & Enterprise, (WPA2/3)
- Man in the Middle — Personal & Enterprise, (WPA2/3)
- MAC Spoofing — Personal & Enterprise, (WPA2/3)
- Firmware updates (specific per vendor, could be alerted) — Personal & Enterprise, (WPA2/3)
- Weak password — located in external password dictionaries as Rockyou.txt — Personal, (WPA2)
- Admin router default passwords — Personal & Enterprise, (WPA2/3)
- New attacks that probably will be reported — Personal & Enterprise, (WPA3)
Step 2
Analyze the behavior of each one of the threats.
Just for example — I’ll focus again in our Deauthentication attack.
Let say that we have a Station and an AP with a valid connection. Suddenly a Deauthentication attack has been performed, we will see (more or less) something like this:
Now, let's focus on the situation for each side of the parties:
The Station (on the right side of the graph) will receive the Deauthentication packet and will close the connection (by definition of the protocol he has to), deleting the session keys (PTK & GTK), and maybe will try to reconnect to the Router (using PMKID maybe?)
The interesting thing goes here:
The Wi-Fi Router (on the left) that allegedly has sent deauthentication request to the Station doesn’t know that the connection has been closed (because the disconnect request wasn’t sent from him but from the attacker).
Maybe, we can observe the packets after the disconnection request has been sent, and look for some encrypted massage from the side (Wi-Fi router) who allegedly sent the disconnected request (e.g. Deauthentication).
If that was an attack we would see some encrypted packets (there could be a more complicated situation but for the example, that is good enough),
Otherwise — the tool can wait for some time-out and if nothing encrypted comes up mark the deauth as legitimate disconnection.
Step 3
Embedded the logic from step 2 inside your tool and mark it as a rule for Deauth attack.
Step 4
Let the tool have some “learning time” when turn on for learning the environment, the network, the BSSID, the behavior of who sending data? how often? in what hours? how big is the sent data? what is the average DBM for each station? (for example, if some attacker will foreign a packet it is probably will be out of rational range of the last packets from this MAC address (depends on distance and PHY configuration etc)
Step 5
Aggregate those indications and Rank the events as Threads, Risk, or legitimate events.
Step 6
Inform the host about the events.
End Of Story
Long story short, when a network manager at a Bank, Hospital or some intelligent army unit, wants to use the Wi-Fi protocol they are exposed to a big number and painful known security breaches.
These security breaches are not only known to everybody due to the published articles, they are also commonly embedded into hacker’s tools (as Aircrack-ng, Reaver, asleap, etc) and anyone can use it without even pre Wi-Fi knowledge.
What stops me or anyone else from going to the bank, opens a Kali with some Evil twin and steal Bank’s employee credentials? (as in the example above).
Maybe a fast updated sniffer with known attacks flow and detection system will be able to help here.
Of course, this problem of being restricted by the certification, also affect: BLE, Bluetooth, ZigBee, and any other over-the-air protocols.
Currently, If I were a network manager in a Bank company or an autonomous car company, I would check all my options before I would go into the Wi-Fi solution.
Email: Yedivach@gmail.com
Linkedin: https://www.linkedin.com/in/yedidya-vachnish-448032140/
