themalwareguardian/cve-2021-27289CVE-2021-27289: Playback Protection Bypass on Ksix Zigbee devices
Hi everyone,
I guess the professional thing to do was just to title this repository exactly as it is – clear, descriptive, and to the point. But when I was putting it together, a few other titles came to my mind, like:
Anyway, here's the story.
While I was getting ready to disclose a new vulnerability, I remembered something I had worked on years ago - a bug I found during my final degree project while researching IoT protocols like Thread and Zigbee. At the time, I sent a report to MITRE but never heard back, so I figured it had just been ignored.
Out of curiosity, I logged back into the old Gmail account I used for the submission... and to my surprise, in 2023 - three years later - I saw that a CVE had actually been assigned.
CVE-2021-27289, linked to the vulnerability I reported as a student.
Why did it take so long? When I first contacted the vendor, they said they didn't have enough staff to fix it and kept repeating that excuse. I told MITRE that no one seemed to be doing anything about it, so I guess they waited - probably because the issue was never going to get patched anyway.
The bug affected several Zigbee-based IoT devices made by Ksix. The core issue was that the replay protection mechanism, defined in the Zigbee specification and enforced through the frame counter, wasn't properly implemented.
Because the devices didn't check the frame counter correctly, an attacker could communicate with the network and spoof packets simply by increasing the sequence number to a value higher than the last one seen by the device. This made it possible to replay captured messages and have them accepted as valid - effectively resulting in an authentication bypass.
This repo includes everything I worked on during my final project:
Ksix Zigbee IoT devices are affected by a replay attack vulnerability caused by improper implementation of Zigbee's replay protection mechanisms.
The following versions were tested and found to be vulnerable. I didn't test later versions, so they may also be affected.
These products are no longer available on the vendor's website or on platforms like Amazon, and appear to have been discontinued.
The Zigbee stack in the affected devices does not properly enforce the replay protection mechanism, which relies on the frame counter field defined in the Zigbee specification. This field is meant to ensure that received messages are fresh and haven't been replayed.
However, in this implementation, the frame counter is ignored or not correctly validated. As a result, an attacker can capture a legitimate Zigbee packet, increase its sequence number to a higher value (e.g., 250), and replay it to the network.
Since the devices only check the sequence number, they accept the message as new - allowing spoofed communication and unauthorized actions without any authentication or encryption being broken.
Depending on the type of device and how it's integrated into the environment, this may cause false alerts or fake sensor states to appear in the app the user originally used to set up the network (e.g., motion detected, door opened) - even though nothing actually happened. In more complex setups, it could even destabilize automation workflows or trigger unintended actions based on spoofed data.
These devices are typically configured using apps like Tuya Smart or similar platforms, which notify users in real time when a sensor is triggered - for example, when a door opens or motion is detected. This is what makes the following attacks particularly effective, even if the physical events never happen.
