गलत उपनाम ब्लॉक सेटिंग्स के साथ Nginx कॉन्फ़िगरेशन भेद्यता

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

समस्या का सार यह है कि उपनाम निर्देश वाले ब्लॉकों के लिए फ़ाइलें अनुरोधित पथ को संलग्न करके, स्थान निर्देश से मास्क के साथ मिलान करने और इस मास्क में निर्दिष्ट पथ के हिस्से को काटने के बाद दी जाती हैं। ऊपर दिखाए गए कमजोर कॉन्फ़िगरेशन के उदाहरण के लिए, एक हमलावर "/img../test.txt" फ़ाइल का अनुरोध कर सकता है और यह अनुरोध स्थान "/img" में निर्दिष्ट मास्क से मेल खाएगा, जिसके बाद शेष पूंछ "../ test.txt" उपनाम निर्देश "/var/images/" से पथ से जुड़ा होगा और परिणामस्वरूप फ़ाइल "/var/images/../test.txt" का अनुरोध किया जाएगा। इस प्रकार, हमलावर "/var" निर्देशिका में किसी भी फ़ाइल तक पहुंच सकते हैं, न कि केवल "/var/images/" में फ़ाइलें, उदाहरण के लिए, nginx लॉग डाउनलोड करने के लिए, आप अनुरोध भेज सकते हैं "/img../log/ nginx/ access.log"।

उन कॉन्फ़िगरेशन में जिनमें उपनाम निर्देश का मान "/" वर्ण के साथ समाप्त नहीं होता है (उदाहरण के लिए, "उपनाम /var/images;"), हमलावर मूल निर्देशिका में नहीं बदल सकता है, लेकिन /var में किसी अन्य निर्देशिका का अनुरोध कर सकता है जिसका नाम कॉन्फ़िगरेशन में निर्दिष्ट से शुरू होता है। उदाहरण के लिए, "/img.old/test.txt" का अनुरोध करके आप निर्देशिका "var/images.old/test.txt" तक पहुंच सकते हैं।

GitHub पर रिपॉजिटरी के विश्लेषण से पता चला कि nginx कॉन्फ़िगरेशन में त्रुटियाँ जो समस्या का कारण बनती हैं, अभी भी वास्तविक परियोजनाओं में पाई जाती हैं। उदाहरण के लिए, बिटवर्डन पासवर्ड मैनेजर के बैकएंड में एक समस्या की उपस्थिति का पता लगाया गया था और इसका उपयोग /etc/bitwarden निर्देशिका में सभी फ़ाइलों तक पहुंचने के लिए किया जा सकता था (/अटैचमेंट के लिए अनुरोध /etc/bitwarden/attachments/ से जारी किए गए थे), पासवर्ड "vault. db", प्रमाणपत्र और लॉग के साथ वहां संग्रहीत डेटाबेस शामिल है, जिसके लिए यह अनुरोध भेजने के लिए पर्याप्त था "/attachments../vault.db", "/attachments../identity.pfx", "/attachments ../logs/api.log", आदि .पी.

यह विधि Google HPC टूलकिट के साथ भी काम करती है, जहां /static अनुरोधों को "../hpc-toolkit/community/front-end/website/static/" निर्देशिका पर पुनर्निर्देशित किया गया था। निजी कुंजी और क्रेडेंशियल के साथ डेटाबेस प्राप्त करने के लिए, एक हमलावर "/static../.secret_key" और "/static../db.sqlite3" प्रश्न भेज सकता है।

स्रोत: opennet.ru