सुरक्षा सप्ताह 28: स्मार्ट घर को हैक करना

"स्मार्ट होम" सिस्टम स्थापित करते समय हम क्या जोखिम लेते हैं? वह जो स्थानीय नेटवर्क के अंदर और दूर स्मार्टफोन पर एप्लिकेशन से प्रकाश बल्ब और एक केतली चलाता है। यदि सुरक्षा और लॉक प्रबंधन एक स्मार्ट सिस्टम से जुड़ा हुआ है (जैसा कि अमेज़न की के मामले में), तो यह स्पष्ट है कि कौन से हैं। यदि नहीं, तो सैद्धांतिक रूप से बाद की आग के साथ कॉफी मशीन के सॉफ़्टवेयर विफलता के खतरे की कल्पना करना संभव है। लेकिन यह कल्पना करने के लिए बेहतर नहीं है, लेकिन निश्चित रूप से जानने के लिए।

कास्परस्की लैब के आईसीएस सीईआरटी टीम के विशेषज्ञों ने कंपनी के कर्मचारियों ( समाचार , ब्लॉग पोस्ट , तकनीकी लेख ) में से एक के स्मार्ट होम पर एक फील्ड परीक्षण करने का फैसला किया। हैकिंग सफल रही: कॉफी निर्माता को नुकसान नहीं हुआ, लेकिन प्रयोग के दौरान कुछ (काफी यथार्थवादी) मान्यताओं के साथ, सिस्टम का नियंत्रण हासिल करना संभव था। इस हमले के अप्रिय परिणामों में से एक व्यक्तिगत डेटा का रिसाव था: घर के निर्देशांक और, सबसे दुख की बात है, स्मार्टफोन का जियोलोकेशन। हालांकि, एक सकारात्मक नोट पर प्रयोग समाप्त हो गया: स्मार्ट होम सिस्टम के निर्माता ने कमजोरियों को सफलतापूर्वक बंद कर दिया।

हैकिंग के परिणामों की कलात्मक व्याख्या

एक तकनीकी लेख में, काफी जगह अपेक्षाकृत उबाऊ, लेकिन महत्वपूर्ण बिंदुओं के लिए समर्पित है: हैकिंग में क्या सफल नहीं हुआ, और संभावित कमजोरियों के लिए स्मार्ट होम सिस्टम का विश्लेषण कैसे हुआ। प्रयोग शुरू करने से पहले, शोधकर्ताओं को सिस्टम के निर्माता को पहले से ही पता था। यह फिबरो निकला , जो आधुनिक स्मार्ट होम के लिए अपने स्वयं के उपकरणों का एक वर्गीकरण बनाता है, साथ ही साथ तीसरे पक्ष के उपकरणों के साथ एकीकरण प्रदान करता है। इसके अलावा, मालिक ने एक महत्वपूर्ण सुराग दिया - व्यवस्थापक पैनल में प्रवेश करने के लिए एक स्थायी आईपी। वैसे, फ़िबरो खुद आईपी के माध्यम से नियंत्रक तक पहुंचने की सिफारिश नहीं करता है - केवल क्लाउड सिस्टम के माध्यम से। इस प्रयोग में, मालिक द्वारा जानबूझकर छोड़ी गई इस खामियों ने एक भूमिका निभाई।


सैद्धांतिक रूप से, इस तरह की प्रणाली को तीन मुख्य दिशाओं में हमला किया जा सकता है: एक या दूसरे तरीके से नियंत्रण डिवाइस को हैक करने की कोशिश करें, सेवा के क्लाउड भाग में कमजोरियों की तलाश करें, या स्वयं नियंत्रक से जुड़े IoT उपकरणों पर हमला करें। उत्तरार्द्ध मामले में, उनके पास निकटता में होना आवश्यक है, इसलिए पहले दो विकल्प अधिक आशाजनक दिखते हैं।

अगला कदम डिवाइस फर्मवेयर और वेबएपीआई का विश्लेषण करना है। आमतौर पर, इस तरह के विश्लेषण पर, सब कुछ समाप्त हो जाता है, और समाचार शैली में निकलता है "डिवाइस में एक वायर्ड पासवर्ड का पता लगाया जाता है।" लेकिन फाइब्रो के मामले में, कोई स्पष्ट सुरक्षा छेद नहीं थे। लेकिन PHP में नियंत्रण तर्क के भाग के कार्यान्वयन के बारे में उपयोगी जानकारी प्राप्त हुई थी। प्राधिकरण के बिना, नियंत्रक केवल डिवाइस का सीरियल नंबर देता है, और लोहे के टुकड़े को हैक करने के लिए यह जानकारी बेकार है। लेकिन, जैसा कि यह निकला, यह आपको सेवा के क्लाउड भाग को हैक करने की अनुमति देता है।


क्लाउड तक पहुंच, बदले में, आपको बिना किसी प्राधिकरण के सभी डिवाइस सेटिंग्स वाले SQLite डेटाबेस बैकअप प्राप्त करने और अपना खुद का अपलोड करने की अनुमति देता है। सैद्धांतिक रूप से, प्राधिकरण को दरकिनार कर क्लाउड सिस्टम के सभी उपयोगकर्ताओं की बैकअप प्रतियां डाउनलोड करने के लिए (भेद्यता को ठीक करने से पहले) संभव बना दिया। हमला किए गए डिवाइस के वास्तविक आधार का विश्लेषण निजी जानकारी तक पहुंच प्रदान करता है, जिसमें घर के निर्देशांक और स्मार्टफोन जिस पर नियंत्रण एप्लिकेशन इंस्टॉल किया गया है। यह पहले से ही एक गंभीर समस्या है, क्योंकि (कुछ सीमाओं के साथ) यह आपको यह निर्धारित करने की अनुमति देता है कि सिस्टम का मालिक घर पर नहीं है।

इसके अलावा, डेटाबेस में कनेक्ट किए गए IoT उपकरणों के बारे में पूरी जानकारी थी, साथ ही सेटिंग्स तक पहुंचने के लिए एक पासवर्ड भी था, लेकिन "नमक" के अतिरिक्त के साथ हैशेड था। फर्मवेयर के विश्लेषण से पता चला कि "नमक" यादृच्छिक नहीं है, लेकिन डिवाइस में दृढ़ता से सिल दिया जाता है। सैद्धांतिक रूप से, एक बहुत ही सरल पासवर्ड को क्रैक किया जा सकता है, लेकिन इस मामले में यह काम नहीं करता था। SQLite बेस में नेटवर्क के भीतर अन्य उपकरणों से कनेक्ट करने के लिए खुले पासवर्ड भी थे: यदि ये पासवर्ड मुख्य एक के साथ मेल खाते हैं, तो नियंत्रक को भी आसानी से क्रैक किया जा सकता है।

लेकिन फिर से यह काम नहीं किया: सिस्टम मालिक बुनियादी सुरक्षा सिफारिशों से परिचित था और उसने विभिन्न उपकरणों के लिए एक ही पासवर्ड का उपयोग नहीं किया था। इसलिए, मुझे सोशल इंजीनियरिंग लागू करना पड़ा। क्लाउड सिस्टम में एक भेद्यता जो प्राधिकरण के बिना कई कार्यों को करने की अनुमति देती है, केवल डिवाइस की सीरियल संख्या (जो "मुफ्त में" दी गई है, अगर बाहर से व्यवस्थापक पैनल तक पहुंच है) को जानने के बाद, निम्नलिखित परिदृश्य को संभव बनाता है। डिवाइस का एक तैयार बैकअप जिसमें दुर्भावनापूर्ण स्क्रिप्ट को एम्बेड किया गया था, उसे "क्लाउड" पर अपलोड किया गया था। क्लाउड सिस्टम की नियमित क्षमताओं के माध्यम से डिवाइस को "अपडेट" करने की आवश्यकता के बारे में एक संदेश स्वामी (ईमेल और एसएमएस के माध्यम से) को भेजा गया था।

चूंकि सिस्टम के मालिक को प्रयोग के बारे में पता था, उन्होंने तुरंत महसूस किया कि यह वास्तविक पैच नहीं था। लेकिन सामान्य तौर पर, यह एक बहुत ही वास्तविक परिदृश्य है, जब उपयोगकर्ता को सामान्य संचार चैनल के माध्यम से एक प्रशंसनीय संदेश मिलता है, इसलिए बैकअप स्थापित किया गया था। दुर्भावनापूर्ण कोड को PHP कोड में बैश स्क्रिप्ट को निष्पादित करने के कारण सिस्टम अधिकारों के साथ निष्पादित किया गया था:


यहां, उपयोगकर्ता द्वारा निर्धारित पैरामीटर (सामान्य परिस्थितियों में, यहां तक ​​कि सिस्टम व्यवस्थापक के पास डिवाइस पर सुपरसुसर विशेषाधिकार नहीं हैं) कमांड लाइन के लिए तर्क में मिलता है। तर्कों के अपर्याप्त सत्यापन ने हमें रूट विशेषाधिकारों के साथ मनमाने कोड को निष्पादित करने और अंत में डिवाइस पर पूर्ण नियंत्रण प्राप्त करने की अनुमति दी। समानांतर में, SQL इंजेक्शन की संभावना पाई गई, लेकिन इसका उपयोग नहीं किया गया:


शोधकर्ताओं ने एक वास्तविक घर में एक कॉफी निर्माता को क्रैक करने की योजना नहीं बनाई, इसलिए उन्होंने अलार्म घड़ी के माधुर्य को "हैलो" के रूप में बदल दिया। क्लाउड सिस्टम और कंट्रोलर कोड में उल्लिखित भेद्यताएं बंद कर दी गईं। स्पष्ट कारणों के लिए, सुरक्षा के परिधि के विशिष्ट तरीकों का खुलासा एक तकनीकी लेख में नहीं किया गया है - ताकि उन उपकरणों पर वास्तविक हमलावरों द्वारा उनका उपयोग न करने के लिए जो अभी तक अपडेट नहीं किए गए हैं। लेकिन इस प्रयोग में, आमतौर पर सुर्खियों के बाहर जो कुछ बचा है वह इस प्रयोग में अच्छी तरह से दिखाया गया है: डिवाइस सुरक्षा की जांच करने के कई तरीके हैं, जिनमें से अधिकांश कुछ भी नहीं है। वास्तविक अनुभव में, डिवाइस निर्माता और उसके मालिक दोनों सरलतम सुरक्षा त्रुटियों से बचने में सक्षम थे, जैसे कि एम्बेडेड और पुन: प्रयोज्य पासवर्ड। फिर भी, पर्याप्त संख्या में समस्याओं की पहचान की गई जो कम से कम निजी डेटा का रिसाव हो सकता है, और सबसे खराब स्थिति में, सुरक्षा प्रणालियों को बायपास करने के लिए।

डिस्क्लेमर: इस डाइजेस्ट में व्यक्त की गई राय हमेशा कास्परस्की लैब की आधिकारिक स्थिति से मेल नहीं खा सकती है। प्रिय संपादकों आमतौर पर स्वस्थ संदेह के साथ किसी भी राय का इलाज करने की सलाह देते हैं।