Nginx उपनाम ट्रैवर्सल अभी भी कई परियोजनाओं के लिए एक गंभीर समस्या है
हाल ही में खबर है कि तोड़ दिया कुछ nginx सर्वर अभी भी असुरक्षित हैं तकनीक "Nginx उपनाम ट्रैवर्सल», जिसे 2018 में ब्लैकहैट सम्मेलन में प्रस्तावित किया गया था और उपनाम निर्देश में निर्दिष्ट रूट निर्देशिका के बाहर स्थित फ़ाइलों और निर्देशिकाओं तक पहुंच की अनुमति देता है।
समस्या का सार अर्थात ब्लॉक के लिए फ़ाइलें उपनाम निर्देश के साथ अनुरोधित पथ संलग्न करके प्रदान किया जाता है, इसे स्थान निर्देश के मास्क से मिलान करने और इस मास्क में निर्दिष्ट पथ के हिस्से को काटने के बाद।
समस्या सामने आती है केवल "उपनाम" निर्देश वाले कॉन्फ़िगरेशन में, जैसे कि Nginx कॉन्फ़िगरेशन में, 'स्थान' नामक एक निर्देश होता है जो यह बता सकता है कि किसी विशेष यूआरएल तक पहुंच को कैसे नियंत्रित किया जाना चाहिए, और अक्सर सर्वर पर फ़ाइलों को यूआरएल निर्दिष्ट करने के लिए उपयोग किया जाता है।
उपनाम के साथ संयोजन में इस स्थान का उपयोग करने वाले पैटर्न में, यह महत्वपूर्ण है जब 'स्थान द्वारा निर्दिष्ट यूआरएल के अंत में एक स्लैश न डालें' और 'निर्दिष्ट पथ के अंत में एक स्लैश डालें' की दो शर्तें उपनाम से मिलते हैं। उपनाम से मिलते हैं। कहा जाता है कि भेद्यता उत्पन्न होती है।
ब्लैकहैट 2018 सम्मेलन में, ऑरेंज त्साई ने यूआरएल पार्सर्स को तोड़ने पर अपना शोध प्रस्तुत किया। अन्य प्रभावशाली खोजों के बीच, उन्होंने 2016 एचसीटीएफ सीटीएफ चुनौती में खोजी गई एक तकनीक का प्रदर्शन किया, जो @iaklis द्वारा बनाई गई थी।
तकनीक लागू होने के लिए, निम्नलिखित शर्तों को पूरा करना होगा:
स्थान निर्देश के पथ में कोई फॉरवर्ड स्लैश नहीं होना चाहिए;
एक उपनाम निर्देश स्थान संदर्भ में मौजूद होना चाहिए और फॉरवर्ड स्लैश के साथ समाप्त होना चाहिए।
ऊपर दिखाए गए एक कमजोर कॉन्फ़िगरेशन के उदाहरण के लिए, एक हमलावर "/img../test.txt" फ़ाइल का अनुरोध कर सकता है और यह अनुरोध स्थान "/img" में निर्दिष्ट मास्क से मेल खाएगा, जिसके बाद कतार शेष रहेगी। ./test.txt" को उपनाम निर्देश पथ "/var/images/" में जोड़ा जाएगा और परिणामस्वरूप फ़ाइल "/var/images/../test.txt" का अनुरोध किया जाएगा।
इसलिए, हमलावर "/var" निर्देशिका में किसी भी फ़ाइल तक पहुंच सकते हैं, न कि केवल "/var/images/" की फ़ाइलों तक, उदाहरण के लिए, nginx लॉग डाउनलोड करने के लिए, आप अनुरोध भेज सकते हैं "/img ../log/nginx /एक्सेस.लॉग"।
एक विश्लेषण GitHub पर रिपॉजिटरी से पता चला कि समस्या का कारण बनने वाले nginx कॉन्फ़िगरेशन में त्रुटियाँ अभी भी वास्तविक परियोजनाओं में हैं.
उदाहरण के लिए, बिटवर्डन पासवर्ड मैनेजर बैकएंड में एक समस्या पाई गई थी और इसका उपयोग वहां संग्रहीत डेटाबेस सहित /etc/bitwarden निर्देशिका (/अटैचमेंट के लिए अनुरोध /etc/bitwarden/ अटैचमेंट/ से जारी किए गए थे) में सभी फ़ाइलों तक पहुंचने के लिए किया जा सकता था। पासवर्ड "vault.db", प्रमाणपत्र और लॉग के साथ, जिसके लिए "vault.db", "identity.pfx", "api.log", आदि अनुरोध भेजने के लिए पर्याप्त था।
यह उल्लेख है कि परियोजना के आधार पर इस भेद्यता की गंभीरता में काफी उतार-चढ़ाव हो सकता है, नगण्य प्रभाव से गंभीर प्रभाव तक। इसके प्रभाव की सीमा मुख्य रूप से इस बात से निर्धारित होती है कि क्या उजागर निर्देशिका में संवेदनशील डेटा है जो आगे के हमलों को सुविधाजनक बना सकता है या निजी जानकारी के प्रकटीकरण का परिणाम हो सकता है।
इस भेद्यता की खोज में शुरुआती बिंदु के रूप में, हमने लोकप्रिय GitHub रिपॉजिटरी का पता लगाना चुना जो इस मुद्दे को दिखा रहे थे। स्रोत कोड तक पहुंच वाले वातावरण में इस विशिष्ट भेद्यता की पहचान करना काफी अधिक संभव हो जाता है, मुख्यतः दो मुख्य कारकों के कारण:
पता लगाना - सरल कोड विश्लेषण उपकरण, जैसे कि रेगुलर एक्सप्रेशन खोज, का उपयोग करने से हमें इन परियोजनाओं के भीतर संभावित रूप से कमजोर Nginx कॉन्फ़िगरेशन फ़ाइलों की प्रभावी ढंग से पहचान करने की अनुमति मिलती है।
शोषण: सटीक लक्ष्य निर्देशिका जिसे उपनाम दिया गया है उसे जानने से हमें एक स्थानीय उदाहरण स्थापित करने, स्थानीय शेल का उपयोग करके उपनाम वाली निर्देशिकाओं की जांच करने और यह निर्धारित करने की अनुमति मिलती है कि भेद्यता के माध्यम से कौन सी फ़ाइलों तक पहुंचा जा सकता है।
उल्लेखनीय है कि यह विधि Google HPC टूलकिट के साथ भी काम करती थी, जहां निजी कुंजी और क्रेडेंशियल के साथ डेटाबेस प्राप्त करने के लिए अनुरोधों को रुचि की निर्देशिका पर पुनर्निर्देशित किया जाता था, एक हमलावर "secret_key" और "db.sqlite3" क्वेरी भेज सकता था।
अंत में, यदि आप इसके बारे में अधिक जानने में रुचि रखते हैं, तो आप विवरण देख सकते हैं निम्नलिखित लिंक में