Nginx
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
अपने वेब ऐप्स, नेटवर्क और क्लाउड पर एक हैकर का दृष्टिकोण प्राप्त करें
महत्वपूर्ण, शोषण योग्य कमजोरियों को खोजें और रिपोर्ट करें जिनका वास्तविक व्यवसाय पर प्रभाव है। हमारे 20+ कस्टम टूल का उपयोग करके हमले की सतह का मानचित्रण करें, सुरक्षा मुद्दों को खोजें जो आपको विशेषाधिकार बढ़ाने की अनुमति देते हैं, और आवश्यक सबूत इकट्ठा करने के लिए स्वचालित शोषण का उपयोग करें, जिससे आपका कठिन काम प्रभावशाली रिपोर्टों में बदल जाए।
जब Nginx सर्वर को कॉन्फ़िगर करते समय, root directive एक महत्वपूर्ण भूमिका निभाता है क्योंकि यह उस मूल निर्देशिका को परिभाषित करता है जिससे फ़ाइलें सर्व की जाती हैं। नीचे दिए गए उदाहरण पर विचार करें:
इस कॉन्फ़िगरेशन में, /etc/nginx
को रूट निर्देशिका के रूप में निर्दिष्ट किया गया है। यह सेटअप निर्दिष्ट रूट निर्देशिका के भीतर फ़ाइलों तक पहुँच की अनुमति देता है, जैसे कि /hello.txt
। हालाँकि, यह ध्यान रखना महत्वपूर्ण है कि केवल एक विशिष्ट स्थान (/hello.txt
) को परिभाषित किया गया है। रूट स्थान (location / {...}
) के लिए कोई कॉन्फ़िगरेशन नहीं है। इस चूक का मतलब है कि रूट निर्देशिका वैश्विक रूप से लागू होती है, जिससे रूट पथ /
पर अनुरोधों को /etc/nginx
के तहत फ़ाइलों तक पहुँचने की अनुमति मिलती है।
इस कॉन्फ़िगरेशन से एक महत्वपूर्ण सुरक्षा विचार उत्पन्न होता है। एक साधारण GET
अनुरोध, जैसे GET /nginx.conf
, संवेदनशील जानकारी को उजागर कर सकता है क्योंकि यह /etc/nginx/nginx.conf
में स्थित Nginx कॉन्फ़िगरेशन फ़ाइल को सर्व करता है। रूट को कम संवेदनशील निर्देशिका, जैसे /etc
, पर सेट करना इस जोखिम को कम कर सकता है, फिर भी यह अन्य महत्वपूर्ण फ़ाइलों, जिसमें अन्य कॉन्फ़िगरेशन फ़ाइलें, एक्सेस लॉग, और यहां तक कि HTTP बेसिक प्रमाणीकरण के लिए उपयोग किए जाने वाले एन्क्रिप्टेड क्रेडेंशियल्स तक अनपेक्षित पहुँच की अनुमति दे सकता है।
Nginx के कॉन्फ़िगरेशन फ़ाइलों में, "location" निर्देशों के लिए एक करीबी निरीक्षण आवश्यक है। एक भेद्यता जिसे लोकल फ़ाइल समावेशन (LFI) के रूप में जाना जाता है, एक कॉन्फ़िगरेशन के माध्यम से अनजाने में पेश की जा सकती है जो निम्नलिखित के समान है:
यह कॉन्फ़िगरेशन LFI हमलों के प्रति संवेदनशील है क्योंकि सर्वर /imgs../flag.txt
जैसे अनुरोधों को लक्षित निर्देशिका के बाहर फ़ाइलों तक पहुँचने के प्रयास के रूप में व्याख्या करता है, जो प्रभावी रूप से /path/images/../flag.txt
में हल होता है। यह दोष हमलावरों को सर्वर की फ़ाइल प्रणाली से फ़ाइलें पुनः प्राप्त करने की अनुमति देता है जो वेब के माध्यम से सुलभ नहीं होनी चाहिए।
इस भेद्यता को कम करने के लिए, कॉन्फ़िगरेशन को इस प्रकार समायोजित किया जाना चाहिए:
अधिक जानकारी: https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/
Accunetix परीक्षण:
निम्नलिखित पृष्ठ पर जाएं यह जानने के लिए कि निर्देशों को कैसे बायपास करें जैसे:
कमजोर वेरिएबल $uri
और $document_uri
हैं और इसे $request_uri
के साथ बदलकर ठीक किया जा सकता है।
एक regex भी कमजोर हो सकता है जैसे:
location ~ /docs/([^/])? { … $1 … }
- कमजोर
location ~ /docs/([^/\s])? { … $1 … }
- कमजोर नहीं (स्पेस की जांच कर रहा है)
location ~ /docs/(.*)? { … $1 … }
- कमजोर नहीं
Nginx कॉन्फ़िगरेशन में एक कमजोरी नीचे दिए गए उदाहरण द्वारा प्रदर्शित की गई है:
HTTP अनुरोधों में \r (Carriage Return) और \n (Line Feed) नए लाइन वर्णों का संकेत देते हैं, और उनके URL-encoded रूप %0d%0a
के रूप में दर्शाए जाते हैं। एक गलत कॉन्फ़िगर किए गए सर्वर पर इन वर्णों को एक अनुरोध में शामिल करने (जैसे, http://localhost/%0d%0aDetectify:%20clrf
) से सर्वर एक नए हेडर का नाम Detectify
जारी करता है। यह इसलिए होता है क्योंकि $uri वेरिएबल URL-encoded नए लाइन वर्णों को डिकोड करता है, जिससे प्रतिक्रिया में एक अप्रत्याशित हेडर उत्पन्न होता है:
CRLF इंजेक्शन और प्रतिक्रिया विभाजन के जोखिमों के बारे में अधिक जानें https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/ पर।
यह तकनीक इस वार्ता में समझाई गई है जिसमें कुछ कमजोर उदाहरण और पहचान तंत्र हैं। उदाहरण के लिए, एक ब्लैकबॉक्स परिप्रेक्ष्य से इस गलत कॉन्फ़िगरेशन का पता लगाने के लिए आप ये अनुरोध कर सकते हैं:
https://example.com/%20X
- कोई भी HTTP कोड
https://example.com/%20H
- 400 खराब अनुरोध
यदि कमजोर है, तो पहला "X" के रूप में लौटेगा क्योंकि यह कोई भी HTTP विधि है और दूसरा एक त्रुटि लौटाएगा क्योंकि H एक मान्य विधि नहीं है। इसलिए सर्वर को कुछ इस तरह प्राप्त होगा: GET / H HTTP/1.1
और यह त्रुटि को ट्रिगर करेगा।
अन्य पहचान उदाहरण होंगे:
http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x
- कोई भी HTTP कोड
http://company.tld/%20HTTP/1.1%0D%0AHost:%20x
- 400 खराब अनुरोध
उस वार्ता में प्रस्तुत कुछ कमजोर कॉन्फ़िगरेशन थे:
ध्यान दें कि $uri
अंतिम URL में जैसा है वैसा ही सेट किया गया है
ध्यान दें कि फिर से $uri
URL में है (इस बार एक पैरामीटर के अंदर)
अब AWS S3 में
यह पाया गया कि उपयोगकर्ता-प्रदत्त डेटा कुछ परिस्थितियों में Nginx वेरिएबल के रूप में माना जा सकता है। इस व्यवहार का कारण कुछ हद तक अस्पष्ट है, फिर भी यह न तो दुर्लभ है और न ही सत्यापित करना सीधा है। इस विसंगति को HackerOne पर एक सुरक्षा रिपोर्ट में उजागर किया गया था, जिसे यहाँ देखा जा सकता है। त्रुटि संदेश की आगे की जांच ने Nginx के कोडबेस के SSI फ़िल्टर मॉड्यूल के भीतर इसकी उपस्थिति की पहचान की, जिससे सर्वर साइड इनक्लूड्स (SSI) को मूल कारण के रूप में इंगित किया गया।
इस गलत कॉन्फ़िगरेशन का पता लगाने के लिए, निम्नलिखित कमांड निष्पादित की जा सकती है, जिसमें वेरिएबल प्रिंटिंग के लिए एक रेफरर हेडर सेट करना शामिल है:
इस गलत कॉन्फ़िगरेशन के लिए सिस्टमों में स्कैन करने पर कई उदाहरण सामने आए जहाँ Nginx वेरिएबल्स को एक उपयोगकर्ता द्वारा प्रिंट किया जा सकता था। हालाँकि, कमजोर उदाहरणों की संख्या में कमी इस बात का संकेत देती है कि इस समस्या को ठीक करने के प्रयास कुछ हद तक सफल रहे हैं।
Nginx एक फीचर प्रदान करता है proxy_pass
के माध्यम से जो बैकएंड द्वारा उत्पन्न त्रुटियों और HTTP हेडर के इंटरसेप्शन की अनुमति देता है, जिसका उद्देश्य आंतरिक त्रुटि संदेशों और हेडर को छिपाना है। यह Nginx द्वारा बैकएंड त्रुटियों के जवाब में कस्टम त्रुटि पृष्ठों को सर्व करके किया जाता है। हालाँकि, जब Nginx एक अमान्य HTTP अनुरोध का सामना करता है, तो चुनौतियाँ उत्पन्न होती हैं। ऐसा अनुरोध बैकएंड को जैसे प्राप्त हुआ है, वैसा ही अग्रेषित किया जाता है, और बैकएंड की कच्ची प्रतिक्रिया फिर सीधे ग्राहक को Nginx के हस्तक्षेप के बिना भेजी जाती है।
एक उदाहरण परिदृश्य पर विचार करें जिसमें एक uWSGI एप्लिकेशन शामिल है:
इसका प्रबंधन करने के लिए, Nginx कॉन्फ़िगरेशन में विशिष्ट निर्देशों का उपयोग किया जाता है:
proxy_intercept_errors: यह निर्देश Nginx को 300 से अधिक स्थिति कोड वाले बैकएंड प्रतिक्रियाओं के लिए एक कस्टम प्रतिक्रिया देने में सक्षम बनाता है। यह सुनिश्चित करता है कि, हमारे उदाहरण uWSGI एप्लिकेशन के लिए, एक 500 Error
प्रतिक्रिया को Nginx द्वारा रोका और संभाला जाता है।
proxy_hide_header: जैसा कि नाम से स्पष्ट है, यह निर्देश क्लाइंट से निर्दिष्ट HTTP हेडर को छुपाता है, जिससे गोपनीयता और सुरक्षा बढ़ती है।
जब एक मान्य GET
अनुरोध किया जाता है, तो Nginx इसे सामान्य रूप से संसाधित करता है, बिना किसी गुप्त हेडर को प्रकट किए एक मानक त्रुटि प्रतिक्रिया लौटाता है। हालाँकि, एक अमान्य HTTP अनुरोध इस तंत्र को बायपास करता है, जिससे कच्ची बैकएंड प्रतिक्रियाएँ, जिसमें गुप्त हेडर और त्रुटि संदेश शामिल हैं, उजागर होती हैं।
डिफ़ॉल्ट रूप से, Nginx का merge_slashes
निर्देश on
पर सेट होता है, जो एक URL में कई फॉरवर्ड स्लैश को एकल स्लैश में संकुचित करता है। यह सुविधा, जबकि URL प्रसंस्करण को सरल बनाती है, Nginx के पीछे अनुप्रयोगों में कमजोरियों को अनजाने में छिपा सकती है, विशेष रूप से जो स्थानीय फ़ाइल समावेश (LFI) हमलों के प्रति संवेदनशील हैं। सुरक्षा विशेषज्ञ Danny Robinson और Rotem Bar ने इस डिफ़ॉल्ट व्यवहार से जुड़े संभावित जोखिमों को उजागर किया है, विशेष रूप से जब Nginx एक रिवर्स-प्रॉक्सी के रूप में कार्य करता है।
ऐसे जोखिमों को कम करने के लिए, यह अनुशंसा की जाती है कि इन कमजोरियों के प्रति संवेदनशील अनुप्रयोगों के लिए merge_slashes
निर्देश को बंद कर दें। यह सुनिश्चित करता है कि Nginx URL संरचना को बदले बिना अनुप्रयोग को अनुरोध अग्रेषित करता है, जिससे किसी भी अंतर्निहित सुरक्षा मुद्दों को छिपाया नहीं जाता है।
अधिक जानकारी के लिए Danny Robinson और Rotem Bar की जाँच करें।
जैसा कि इस लेख में दिखाया गया है, कुछ हेडर हैं जो यदि वे वेब सर्वर से प्रतिक्रिया में मौजूद हैं तो वे Nginx प्रॉक्सी के व्यवहार को बदल देंगे। आप उन्हें दस्तावेज़ों में देख सकते हैं:
X-Accel-Redirect
: Nginx को एक निर्दिष्ट स्थान पर अनुरोध को आंतरिक रूप से पुनर्निर्देशित करने का संकेत देता है।
X-Accel-Buffering
: नियंत्रित करता है कि क्या Nginx को प्रतिक्रिया को बफर करना चाहिए या नहीं।
X-Accel-Charset
: X-Accel-Redirect का उपयोग करते समय प्रतिक्रिया के लिए वर्ण सेट सेट करता है।
X-Accel-Expires
: X-Accel-Redirect का उपयोग करते समय प्रतिक्रिया के लिए समाप्ति समय सेट करता है।
X-Accel-Limit-Rate
: X-Accel-Redirect का उपयोग करते समय प्रतिक्रियाओं के लिए स्थानांतरण की दर को सीमित करता है।
उदाहरण के लिए, हेडर X-Accel-Redirect
Nginx में एक आंतरिक पुनर्निर्देश का कारण बनेगा। इसलिए, यदि Nginx कॉन्फ़िगरेशन में कुछ ऐसा है जैसे root /
और वेब सर्वर से प्रतिक्रिया में X-Accel-Redirect: .env
है, तो Nginx /.env
(Path Traversal) की सामग्री भेजेगा।
Nginx कॉन्फ़िगरेशन में, map
निर्देश अक्सर अधिकार नियंत्रण में भूमिका निभाता है। एक सामान्य गलती डिफ़ॉल्ट मान निर्दिष्ट न करना है, जो अनधिकृत पहुंच का कारण बन सकता है। उदाहरण के लिए:
बिना default
के, एक दुष्ट उपयोगकर्ता /map-poc
के भीतर एक अपरिभाषित URI तक पहुँचकर सुरक्षा को बायपास कर सकता है। Nginx मैनुअल ऐसे मुद्दों से बचने के लिए डिफ़ॉल्ट मान सेट करने की सलाह देता है।
Nginx के खिलाफ DNS स्पूफिंग कुछ शर्तों के तहत संभव है। यदि एक हमलावर को Nginx द्वारा उपयोग किए जाने वाले DNS सर्वर का ज्ञान है और वह इसके DNS प्रश्नों को इंटरसेप्ट कर सकता है, तो वह DNS रिकॉर्ड को स्पूफ कर सकता है। हालाँकि, यह विधि तब प्रभावी नहीं है जब Nginx को DNS समाधान के लिए localhost (127.0.0.1) का उपयोग करने के लिए कॉन्फ़िगर किया गया हो। Nginx एक DNS सर्वर को इस प्रकार निर्दिष्ट करने की अनुमति देता है:
proxy_pass
और internal
निर्देशproxy_pass
निर्देश का उपयोग अनुरोधों को अन्य सर्वरों की ओर पुनर्निर्देशित करने के लिए किया जाता है, चाहे वह आंतरिक हो या बाहरी। internal
निर्देश यह सुनिश्चित करता है कि कुछ स्थान केवल Nginx के भीतर ही सुलभ हैं। जबकि ये निर्देश अपने आप में कमजोरियाँ नहीं हैं, उनकी कॉन्फ़िगरेशन की सावधानीपूर्वक जांच की आवश्यकता होती है ताकि सुरक्षा में चूक न हो।
यदि nginx सर्वर को Upgrade और Connection हेडर पास करने के लिए कॉन्फ़िगर किया गया है, तो एक h2c Smuggling हमला किया जा सकता है ताकि संरक्षित/आंतरिक एंडपॉइंट्स तक पहुँच प्राप्त की जा सके।
यह कमजोरी एक हमलावर को proxy_pass
एंडपॉइंट के साथ एक सीधा कनेक्शन स्थापित करने की अनुमति देगी (http://backend:9999
इस मामले में) जिसका सामग्री nginx द्वारा जांचा नहीं जाएगा।
/flag
को चुराने के लिए कमजोर कॉन्फ़िगरेशन का उदाहरण यहाँ है:
ध्यान दें कि भले ही proxy_pass
एक विशिष्ट पथ की ओर इशारा कर रहा हो जैसे http://backend:9999/socket.io
, कनेक्शन http://backend:9999
के साथ स्थापित होगा, इसलिए आप उस आंतरिक एंडपॉइंट के अंदर किसी अन्य पथ से संपर्क कर सकते हैं। इसलिए यह मायने नहीं रखता कि proxy_pass के URL में कोई पथ निर्दिष्ट किया गया है।
Detectify ने एक GitHub रिपॉजिटरी बनाई है जहां आप Docker का उपयोग करके अपने स्वयं के कमजोर Nginx परीक्षण सर्वर को स्थापित कर सकते हैं जिसमें इस लेख में चर्चा की गई कुछ गलत कॉन्फ़िगरेशन हैं और उन्हें स्वयं खोजने की कोशिश कर सकते हैं!
https://github.com/detectify/vulnerable-nginx
Gixy Nginx कॉन्फ़िगरेशन का विश्लेषण करने के लिए एक उपकरण है। Gixy का मुख्य लक्ष्य सुरक्षा गलत कॉन्फ़िगरेशन को रोकना और दोष पहचान को स्वचालित करना है।
Nginxpwner सामान्य Nginx गलत कॉन्फ़िगरेशन और कमजोरियों की खोज के लिए एक सरल उपकरण है।
अपने वेब ऐप्स, नेटवर्क और क्लाउड पर एक हैकर का दृष्टिकोण प्राप्त करें
वास्तविक व्यावसायिक प्रभाव के साथ महत्वपूर्ण, शोषण योग्य कमजोरियों को खोजें और रिपोर्ट करें। हमारे 20+ कस्टम उपकरणों का उपयोग करके हमले की सतह को मानचित्रित करें, सुरक्षा मुद्दों को खोजें जो आपको विशेषाधिकार बढ़ाने की अनुमति देते हैं, और आवश्यक सबूत इकट्ठा करने के लिए स्वचालित शोषण का उपयोग करें, जिससे आपका कठिन काम प्रभावशाली रिपोर्टों में बदल जाए।
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)