पुराने UPnP भेद्यता एक नए तरीके से

सब कुछ नया एक अच्छी तरह से भूल गया पुराना (या बेहतर, एक बहुत अच्छी तरह से भूल गया पुराना) है। बेशक, नई कमजोरियों की निगरानी करना सही है, लेकिन आपको पुराने के बारे में नहीं भूलना चाहिए। खासकर जब निर्माता खुद को उन्हें "भूल" करने की अनुमति देता है। किसी को याद करना होगा। अन्यथा, हम एक ही रेक पर बार-बार कदम रखेंगे।

लेख एक पुराने पर ध्यान केंद्रित करेगा, लेकिन जैसा कि यह निकला, आज तक इसकी प्रासंगिकता कभी नहीं खोई है, यूपीएनपी छेद।



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

पीपीएस सभी घटनाएं 2018 के अंत में हुईं। नायक काल्पनिक होते हैं, और वास्तविक व्यक्तित्व वाले संयोग यादृच्छिक होते हैं।


भेद्यता का पहला उल्लेख 2014 में वापस आ गया था: tyk
निर्माता से संपर्क करने के प्रयासों में बहुत सफलता नहीं मिली और भेद्यता प्रकाशित हुई। केवल प्रतिवाद सिफारिश थी:

"... सेवा के साथ बातचीत को प्रतिबंधित करना ... केवल क्लाइंट और सर्वर जिनके पास कानूनी प्रक्रियात्मक संबंध हैं ... को इसके साथ संवाद करने में सक्षम होना चाहिए।"

मिनीगैड SOAP सेवा में एक दोष मौजूद है। सिस्टम कॉल करने से पहले उपयोगकर्ता डेटा साफ़ करने में असमर्थता के कारण समस्या NewInternalClient अनुरोधों को संसाधित कर रही है। एक हमलावर इस भेद्यता का उपयोग रूट विशेषाधिकारों के साथ कोड निष्पादित करने के लिए कर सकता है।

यानी UPnP संस्करण 1.0 वाले सभी राउटर पर, आप मनमाने ढंग से रिमोट कोड निष्पादित कर सकते हैं।
बिना प्राधिकरण के। जड़ से। महान, सही?

कोई भी गितुब पर मेटासप्लिट के लिए एक तैयार-निर्मित प्लगइन पा सकता है, जिसके प्रदर्शन का परीक्षण हमारे कर्तव्य इंजीनियरों की जली हुई कुर्सियों द्वारा किया गया था।
यह अप्रत्याशित था और बिल्कुल भी मजेदार नहीं था।

उस दिन की घटनाओं का संक्षिप्त कालक्रम:

14:00 तकनीकी सहायता में, ग्राहकों को खराब तरीके से काम करने वाले इंटरनेट पर कॉल प्राप्त होने लगते हैं।

• ग्राहक पक्ष पर लक्षण: "यह धीरे-धीरे काम करता है, रिबूट के बाद यह थोड़ी देर के लिए ठीक काम करता है, फिर धीरे-धीरे।"
• उपकरण के हिस्से पर लक्षण: ट्रैफ़िक में एक छोटा उछाल और सीपीयू लोड उस लोड पर लिखा गया जिसे क्लाइंट जेनरेट करता है।

एकल एप्लिकेशन को पंजीकृत करने के लिए लाइन की जाँच करने के लिए या इंस्टॉलर के प्रस्थान के लिए पंजीकृत किया जाता है। कार्रवाई के लिए कोई सामान्य टेम्पलेट नहीं है। कुछ भी स्पष्ट नहीं है।

15:00 अस्पताल में औसत तापमान को पार करने के लिए आवेदनों की संख्या शुरू होती है और "एक्सेप्ट" के प्रकार के साथ अधिक अनुप्रयोगों के लिए एकल अनुप्रयोग शुरू होते हैं। नेटवर्क सेगमेंट को सत्यापित करने के लिए वरिष्ठ प्रशासकों को आवेदन प्रस्तुत किए जाते हैं।

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

15:30 फिर से ग्राहकों से आवेदनों की आमद, फिर से एक बड़े हादसे का पंजीकरण और प्रवेशकों को स्थानांतरण। इस समय, यह स्पष्ट हो जाता है कि कुछ वास्तव में गलत है और कुछ किया जाना चाहिए (जिसने ग्राहक सेवा के साथ काम किया है वह समझ जाएगा कि यह करना कभी-कभी कितना मुश्किल होता है। ग्राहक हमेशा झूठ बोलते हैं, और कभी-कभी पहली पंक्ति आगे काम को आगे बढ़ाने के लिए निहित होती है) ।

15:35 ड्यूटी पर इंजीनियर ग्राहक सेवा के साथ एक समस्या के लिए अनुरोध प्राप्त करता है। सभी क्लाइंट, उनके कनेक्शन प्रकार और डिवाइस मॉडल की एक सूची प्राप्त करता है। और फिर थोड़ा जादू शुरू होता है।




15:40 इंजीनियर ग्राहक सूची को सभी डायग्नोस्टिक्स के माध्यम से चलाता है, प्रत्येक राउटर को सभी मानक मैट्रिक्स के अनुसार जांचा गया और ... कुछ भी नहीं मिला। राउटर एक राउटर की तरह होता है। हां, सीपीयू बढ़ गया है, लेकिन संकेतक महत्वपूर्ण नहीं हैं, लेकिन यह कहीं न कहीं यातायात डालता है, जिसका अर्थ है कि यह काम करता है।

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

16:00 केवल अब हमें पता चला है कि कुछ समस्याएं हैं। ड्यूटी पर इंजीनियर अपने पर्यवेक्षक को रिपोर्ट करता है, और पर्यवेक्षक हमें पोर्ट 52869 के बारे में अपने अनुमानों के बारे में फोन करता है और मदद मांगता है।

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

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

हम आगे इंतजार करते हैं, हम स्क्रीन को देखते हैं।

भाड़े पहले से ही इस तरह से पकड़े गए थे - काफी कुशलता से और इसलिए आदतों को नहीं बदलने का फैसला किया।

16:10 जबकि तारों की सरसराहट, Google में एक भेद्यता CVE-2014-8361 है जिसके बारे में इंजीनियरों को बताया गया है। इंजीनियर, बिना सुने, एक निर्णय करता है (और, सैद्धांतिक रूप से, तार्किक) - सीमा पर इस बंदरगाह का फ़िल्टर। जल्दी से नहीं कहा।


16:25 हमें बताया गया है कि सभी रीमेक शिट मिशा ने काम नहीं किया। और हम पहले से ही जानते थे कि काम नहीं करेगा। उस समय तक, वे पहले से ही परीक्षण राउटर पर दस्तक दे चुके थे, रिवर्स को दूसरे पोर्ट पर ले गए और डीडीओएस-1900 के माध्यम से इसका उपयोग करना शुरू कर दिया () पोर्ट एक और भेद्यता का उपयोग कर रहा था। भगवान, एक टपका हुआ कचरा क्या कर सकता है


सबसे दिलचस्प बात यह है कि डिवाइस पर फ़ायरवॉल नियम बदल दिए गए हैं और अब नैम्प बाहर से खुले पोर्ट नहीं दिखाते हैं। केवल एक यातायात डंप में इन बंदरगाहों पर अनुरोधों का पता लगाना संभव था। यानी हैकिंग के बाद एक हमलावर ने शेष तक पहुंच को अवरुद्ध कर दिया। हाई-टेक अप्रोच नहीं, लेकिन ब्रावो वैसे भी।

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

16:40 सारांशित करने के लिए : डिवाइसेस हैक किए गए हैं, ddos ​​में न्यूनतम भाग लेते हैं और एन्क्रिप्ट किए गए चैनल पर कहीं न कहीं संचारित करते हैं। (सभी अलग-अलग बंदरगाहों पर)। अंदर जाना संभव नहीं है, विक्रेता ने डिवाइस के लिए ssh के माध्यम से पूर्ण पहुंच से इनकार कर दिया और देखें कि वहां पहुंचना असंभव था। कंसोल पासवर्ड से सुरक्षित है।

17:00 के करीब कहीं, डिवाइस को सबसे तेज़ तरीके से सीवे करने का निर्णय लिया गया था। चमकती और रिबूट करने के बाद, सब कुछ सामान्य हो गया।

बजाय योग के

दुर्भाग्य से, हम इस समस्या को पूरी तरह से हल नहीं कर सके।

"निर्णय" से मेरा मतलब है कि हैकिंग की पूरी जानकारी प्राप्त करना और भविष्य में इसका मुकाबला करने के लिए हमारी नीतियों को अपडेट करना। हां, सभी कार्य सफलतापूर्वक हल नहीं होते हैं और जैसा हम चाहते हैं। यह सामान्य है। हालांकि अपमानजनक है।

अगर शोडान पर खोज करना अच्छा है,
आप अपने आप को कुछ पा सकते हैं
प्रयोगों के लिए:
एक तरीका या दूसरा
लेकिन मैंने आपको यह नहीं बताया।