MACROSCOP में कमजोरता (संस्करण 1.9.72 के बाद से तय)

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

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

खोजा गया भेद्यता एक अनिर्दिष्ट सुपरयुजर खाते के लिए एक कमजोर उपयोगकर्ता नाम और पासवर्ड का उपयोग है, साथ ही इस खाते का उपयोग करके कुछ सर्वर अनुरोधों को करने की क्षमता है। MACROSCOP का परीक्षण करते समय, यह जांचने की आवश्यकता थी कि कैमरों और प्रोग्राम के लिए खातों को सुरक्षित रूप से कैसे संग्रहीत किया जाता है, और परिणामस्वरूप, "Current.CnnConf" कॉन्फ़िगरेशन फ़ाइल ने मेरा ध्यान आकर्षित किया। जैसा कि यह पता चला है, कैमरों के लिए पासवर्ड स्पष्ट पाठ में संग्रहीत किए जाते हैं, और प्रोग्राम खातों के पासवर्ड md5 हैश के रूप में होते हैं, और इसके अलावा, सबसे अधिक संभावना है, एक उलट एन्क्रिप्टेड रूप में। कॉन्फ़िगरेशन फ़ाइल का अध्ययन करते समय, मैं सुपरयूज़र और सुपरपास लाइनों के साथ-साथ दो लगातार लाइनों को दूरस्थ रूप से एक हैश के रूप में देखता था। क्लाइंट एप्लिकेशन और कॉन्फ़िगरेशन का उपयोग करके प्राधिकरण के लिए इस जोड़ी का उपयोग करने का प्रयास वांछित परिणाम नहीं लाया, लेकिन मैंने यह नहीं सोचा कि यह कुछ के लिए आवश्यक था और कहीं काम करना चाहिए। इस खाते के बारे में उपयोगकर्ता के दस्तावेज़ में एक शब्द नहीं था, इसलिए मैंने बाहरी मॉड्यूल विकसित करने के लिए MACROSCOP SDK का उपयोग करने पर प्रलेखन का अध्ययन करने का निर्णय लिया, जहां मुझे कोई जानकारी भी नहीं मिली, लेकिन मुझे प्रोग्राम से डेटा स्ट्रीम प्राप्त करने के लिए HTTP इंटरफ़ेस का उपयोग करने के विवरण में रुचि थी। मेरे आश्चर्य की कल्पना कीजिए जब मैंने इस जोड़ी के उपयोग को एक क्वेरी के लिए जाँचने की कोशिश की जैसे:

server:8080/video?channel=""&login=superuser&password=superpass

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

server:8080/configex?login=superuser&password=superpass

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

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

 Random random = new Random(); byte[] buffer = new byte[21]; byte[] buffer2 = new byte[21]; random.NextBytes(buffer); random.NextBytes(buffer2); this.SuperUser = SDKCommon.MD5Hash(Encoding.UTF8.GetString(buffer)); this.SuperPass = SDKCommon.MD5Hash(Encoding.UTF8.GetString(buffer2)); 

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

MACROSCOP में भेद्यता का मूल कारण मानक .NET वर्ग रैंडम का सही उपयोग है, जो उस खाते की पीढ़ी की ओर जाता है जिसे उचित समय में उठाया जा सकता है। तथ्य यह है कि यह वर्ग एक 32-बिट मूल्य का उपयोग करता है जिसे गेटिकाउंट सिस्टम फ़ंक्शन को कॉल करने के लिए प्राप्त किया गया है, जो कि छद्म आयामी संख्याओं की एक सरणी को आरंभ करने के लिए है: कंप्यूटर चालू होने के बाद से मिलीसेकंड की संख्या। इस प्रकार, इस संख्या के आधार पर, उपयोगकर्ता नाम और पासवर्ड की एक जोड़ी बनती है। इस जोड़े को उस समय के सभी संभावित मूल्यों की गणना करके पता लगाया जा सकता है जब पहले कॉन्फ़िगरेशन लागू होने तक कंप्यूटर को चालू किया गया था। समस्या को इस तथ्य से भी जटिल किया जाता है कि ज्यादातर मामलों में पहले कॉन्फ़िगरेशन लागू होने तक कंप्यूटर को चालू करने से बहुत कम समय बीत सकता है। उदाहरण के लिए, यदि कंप्यूटर को चालू करने के एक घंटे बाद पहला कॉन्फ़िगरेशन लागू किया गया था, तो आपको केवल 3.6 मिलियन संयोजनों (1 एच * 60 मिनट * 60 एस * 1000 एमएस) की जांच करने की आवश्यकता है। यहां तक ​​कि अगर कंप्यूटर को बहुत लंबे समय तक चालू किया गया था, तो यह क्रूर बल के साथ हमले को बहुत जटिल नहीं करेगा, जैसा कि चूंकि रैंडम वर्ग 32-बिट हस्ताक्षरित संख्या के मापांक के मूल्य को आरंभ करने के लिए उपयोग करता है, इसलिए इनपुट मानों की संख्या अंततः 31-बिट संख्या तक सीमित है। इस प्रकार, गणना के लिए संयोजनों की अधिकतम संख्या 2 ^ 31 (2147483648) मान है, जो उस समय से कंप्यूटर चालू है जब तक कि पहला कॉन्फ़िगरेशन लागू नहीं किया जाता है लगभग 25 दिन, जिसके बाद शुरू से उलटी गिनती शुरू होती है। चैनल नाम, उनके पहचानकर्ता और सेटिंग्स प्राप्त करने के लिए पहले से संकेतित अनुरोध का उपयोग करके भी खोज की जाती है। आदर्श परिस्थितियों (कम से कम 50 एमबीपीएस, मल्टी-कोर प्रोसेसर, कम प्रोसेसर लोड) के आउटगोइंग सर्वर चैनल की गति के तहत, खोज की गति प्रति सेकंड लगभग 5000 खातों तक पहुंच सकती है। इसका मतलब यह है कि अगर कंप्यूटर को चालू करने के एक घंटे बाद पहला कॉन्फ़िगरेशन लागू किया गया था, तो खाता गणना समय 12 मिनट से अधिक नहीं होगा। खोज समय को कम करना भी संभव है जब अनुमानित समय को ध्यान में रखते हुए कंप्यूटर को व्यावसायिक घंटों के दौरान चालू किया गया था, उदाहरण के लिए, यदि कंप्यूटर को व्यवसाय के दिनों और घंटों के दौरान चालू किया जा सकता है, तो खोज समय को 3.7 गुना तक कम किया जा सकता है।

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

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

डेवलपर्स को MACROSCOP में भेद्यता के बारे में सूचित किया गया था, और 2 सप्ताह (12 मार्च, 2014) के बाद उन्होंने इसे प्रोग्राम संस्करण 1.9.72 की रिलीज के साथ बंद कर दिया। अब बिल्ट-इन अकाउंट जेनरेशन कोड इस तरह दिखता है:

 byte[] data = new byte[21]; byte[] buffer2 = new byte[21]; try { RNGCryptoServiceProvider provider = new RNGCryptoServiceProvider(); provider.GetBytes(data); provider.GetBytes(buffer2); } catch (Exception exception) { b1x.a(exception, "dsfimdfsmsdfdkfskfds"); Random random = new Random(Guid.NewGuid().GetHashCode()); random.NextBytes(data); random.NextBytes(buffer2); } Buffer.BlockCopy(Guid.NewGuid().ToByteArray(), 0, data, 0, 8); Buffer.BlockCopy(Guid.NewGuid().ToByteArray(), 0, buffer2, 0, 8); this.SuperUser = SDKCommon.MD5Hash(Encoding.UTF8.GetString(data)); this.SuperPass = SDKCommon.MD5Hash(Encoding.UTF8.GetString(buffer2)); 

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

- MacroscopServer सेवा बंद करें या कंप्यूटर पर स्टैंडअलोन संस्करण बंद करें;
- हेक्साडेसिमल संपादक में कॉन्फ़िगरेशन फ़ाइल "Current.CmnConf" खोलें, प्रोग्राम फ़ोल्डर में स्थित है (पहले फ़ाइल की बैकअप प्रतिलिपि बनाना बेहतर है);
- हम फ़ाइल "लाइन Alarus.Config.SystemEditions", अर्थात् प्रविष्टि के दूसरे परिणाम में पाते हैं;
- खोज परिणाम के तुरंत नीचे दो लाइनें 32 वर्ण लंबी होंगी - यह अंतर्निहित खाते का डेटा है;
- हम स्ट्रिंग्स की लंबाई को बदले बिना, सेट "0123456789ABCDEF" से मान्य वर्णों को ध्यान में रखते हुए, स्ट्रिंग्स की सामग्री को मनमाने ढंग से बदलते हैं;
- कॉन्फ़िगरेशन को बचाएं;
- कार्यक्रम की सेवा या स्टैंडअलोन संस्करण चलाएं;
- मल्टी-सर्वर कॉन्फ़िगरेशन का उपयोग करने के मामले में, हम एक ही कार्य करते हैं, केवल पहले से संपादित मानों को स्ट्रिंग्स के रूप में उपयोग करते हैं या केवल कॉन्फ़िगरेशन को सही से बदल देते हैं।

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