Nginx

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

कमजोरी मूल्यांकन और पैठ परीक्षण के लिए तुरंत उपलब्ध सेटअप। 20+ उपकरणों और सुविधाओं के साथ कहीं से भी एक पूर्ण pentest चलाएँ जो पुनः खोज से रिपोर्टिंग तक जाते हैं। हम pentesters का स्थान नहीं लेते - हम उन्हें गहराई से खुदाई करने, शेल पॉप करने और मज़े करने के लिए कुछ समय वापस देने के लिए कस्टम उपकरण, पहचान और शोषण मॉड्यूल विकसित करते हैं।

Penetration testing toolkit, ready to usePentest-Tools.com

Missing root location

जब Nginx सर्वर को कॉन्फ़िगर करते हैं, तो root निर्देश एक महत्वपूर्ण भूमिका निभाता है क्योंकि यह उस मूल निर्देशिका को परिभाषित करता है जिससे फ़ाइलें परोसी जाती हैं। नीचे दिए गए उदाहरण पर विचार करें:

server {
root /etc/nginx;

location /hello.txt {
try_files $uri $uri/ =404;
proxy_pass http://127.0.0.1:8080/;
}
}

इस कॉन्फ़िगरेशन में, /etc/nginx को रूट निर्देशिका के रूप में निर्दिष्ट किया गया है। यह सेटअप निर्दिष्ट रूट निर्देशिका के भीतर फ़ाइलों तक पहुँच की अनुमति देता है, जैसे कि /hello.txt। हालाँकि, यह महत्वपूर्ण है कि केवल एक विशिष्ट स्थान (/hello.txt) को परिभाषित किया गया है। रूट स्थान (location / {...}) के लिए कोई कॉन्फ़िगरेशन नहीं है। इस चूक का मतलब है कि रूट निर्देशिका वैश्विक रूप से लागू होती है, जिससे रूट पथ / पर अनुरोधों को /etc/nginx के तहत फ़ाइलों तक पहुँचने की अनुमति मिलती है।

इस कॉन्फ़िगरेशन से एक महत्वपूर्ण सुरक्षा विचार उत्पन्न होता है। एक साधारण GET अनुरोध, जैसे GET /nginx.conf, संवेदनशील जानकारी को उजागर कर सकता है क्योंकि यह /etc/nginx/nginx.conf में स्थित Nginx कॉन्फ़िगरेशन फ़ाइल को सर्व करता है। रूट को कम संवेदनशील निर्देशिका, जैसे /etc, पर सेट करना इस जोखिम को कम कर सकता है, फिर भी यह अन्य महत्वपूर्ण फ़ाइलों, जिसमें अन्य कॉन्फ़िगरेशन फ़ाइलें, एक्सेस लॉग, और यहां तक कि HTTP बेसिक प्रमाणीकरण के लिए उपयोग किए जाने वाले एन्क्रिप्टेड क्रेडेंशियल्स तक अनपेक्षित पहुँच की अनुमति दे सकता है।

Alias LFI Misconfiguration

Nginx के कॉन्फ़िगरेशन फ़ाइलों में, "location" निर्देशों के लिए एक करीबी निरीक्षण आवश्यक है। एक भेद्यता जिसे लोकल फ़ाइल समावेशन (LFI) के रूप में जाना जाता है, एक कॉन्फ़िगरेशन के माध्यम से अनजाने में पेश की जा सकती है जो निम्नलिखित के समान है:

location /imgs {
alias /path/images/;
}

यह कॉन्फ़िगरेशन LFI हमलों के प्रति संवेदनशील है क्योंकि सर्वर /imgs../flag.txt जैसे अनुरोधों को लक्षित निर्देशिका के बाहर फ़ाइलों तक पहुँचने के प्रयास के रूप में व्याख्या करता है, जो प्रभावी रूप से /path/images/../flag.txt में हल होता है। यह दोष हमलावरों को सर्वर की फ़ाइल प्रणाली से फ़ाइलें पुनः प्राप्त करने की अनुमति देता है जो वेब के माध्यम से सुलभ नहीं होनी चाहिए।

इस भेद्यता को कम करने के लिए, कॉन्फ़िगरेशन को इस प्रकार समायोजित किया जाना चाहिए:

location /imgs/ {
alias /path/images/;
}

अधिक जानकारी: https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/

Accunetix परीक्षण:

alias../ => HTTP status code 403
alias.../ => HTTP status code 404
alias../../ => HTTP status code 403
alias../../../../../../../../../../../ => HTTP status code 400
alias../ => HTTP status code 403

Unsafe path restriction

निम्नलिखित पृष्ठ पर जाएं यह जानने के लिए कि निर्देशों को कैसे बायपास करें जैसे:

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

Proxy / WAF Protections Bypass

असुरक्षित वेरिएबल उपयोग / HTTP अनुरोध विभाजन

कमजोर वेरिएबल $uri और $document_uri हैं और इसे $request_uri के साथ बदलकर ठीक किया जा सकता है।

एक regex भी कमजोर हो सकता है जैसे:

location ~ /docs/([^/])? { … $1 … } - कमजोर

location ~ /docs/([^/\s])? { … $1 … } - कमजोर नहीं (स्पेस की जांच कर रहा है)

location ~ /docs/(.*)? { … $1 … } - कमजोर नहीं

Nginx कॉन्फ़िगरेशन में एक कमजोरी नीचे दिए गए उदाहरण द्वारा प्रदर्शित की गई है:

location / {
return 302 https://example.com$uri;
}

HTTP अनुरोधों में \r (Carriage Return) और \n (Line Feed) नए लाइन वर्णों का संकेत देते हैं, और उनके URL-encoded रूप %0d%0a के रूप में दर्शाए जाते हैं। एक अनुरोध में इन वर्णों को शामिल करने पर (जैसे, http://localhost/%0d%0aDetectify:%20clrf) एक गलत कॉन्फ़िगर किए गए सर्वर पर सर्वर एक नए हेडर का नाम Detectify जारी करता है। यह इसलिए होता है क्योंकि $uri वेरिएबल URL-encoded नए लाइन वर्णों को डिकोड करता है, जिससे प्रतिक्रिया में एक अप्रत्याशित हेडर उत्पन्न होता है:

HTTP/1.1 302 Moved Temporarily
Server: nginx/1.19.3
Content-Type: text/html
Content-Length: 145
Connection: keep-alive
Location: https://example.com/
Detectify: clrf

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 में जैसा है वैसा ही सेट किया गया है

location ^~ /lite/api/ {
proxy_pass http://lite-backend$uri$is_args$args;
}

ध्यान दें कि फिर से $uri URL में है (इस बार एक पैरामीटर के अंदर)

location ~ ^/dna/payment {
rewrite ^/dna/([^/]+) /registered/main.pl?cmd=unifiedPayment&context=$1&native_uri=$uri break;
proxy_pass http://$back;

अब AWS S3 में

location /s3/ {
proxy_pass https://company-bucket.s3.amazonaws.com$uri;
}

Any variable

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

इस गलत कॉन्फ़िगरेशन का पता लगाने के लिए, निम्नलिखित कमांड निष्पादित की जा सकती है, जिसमें वेरिएबल प्रिंटिंग के लिए एक रेफरर हेडर सेट करना शामिल है:

$ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’

इस misconfiguration के लिए सिस्टमों में स्कैन करने पर कई उदाहरण सामने आए जहाँ Nginx वेरिएबल्स को एक उपयोगकर्ता द्वारा प्रिंट किया जा सकता था। हालाँकि, कमजोर उदाहरणों की संख्या में कमी यह सुझाव देती है कि इस समस्या को पैच करने के प्रयास कुछ हद तक सफल रहे हैं।

Raw backend response reading

Nginx एक फीचर प्रदान करता है proxy_pass के माध्यम से जो बैकएंड द्वारा उत्पन्न त्रुटियों और HTTP हेडर्स के इंटरसेप्शन की अनुमति देता है, जिसका उद्देश्य आंतरिक त्रुटि संदेशों और हेडर्स को छिपाना है। यह Nginx द्वारा बैकएंड त्रुटियों के जवाब में कस्टम त्रुटि पृष्ठों को सर्व करके किया जाता है। हालाँकि, जब Nginx एक अमान्य HTTP अनुरोध का सामना करता है, तो चुनौतियाँ उत्पन्न होती हैं। ऐसा अनुरोध बैकएंड को जैसे प्राप्त हुआ है, वैसा ही अग्रेषित किया जाता है, और बैकएंड का कच्चा उत्तर फिर सीधे ग्राहक को Nginx की मध्यस्थता के बिना भेजा जाता है।

एक उदाहरण परिदृश्य पर विचार करें जिसमें एक uWSGI एप्लिकेशन शामिल है:

def application(environ, start_response):
start_response('500 Error', [('Content-Type', 'text/html'), ('Secret-Header', 'secret-info')])
return [b"Secret info, should not be visible!"]

इसका प्रबंधन करने के लिए, Nginx कॉन्फ़िगरेशन में विशिष्ट निर्देशों का उपयोग किया जाता है:

http {
error_page 500 /html/error.html;
proxy_intercept_errors on;
proxy_hide_header Secret-Header;
}

proxy_intercept_errors: यह निर्देश Nginx को 300 से अधिक स्थिति कोड वाले बैकएंड प्रतिक्रियाओं के लिए एक कस्टम प्रतिक्रिया देने की अनुमति देता है। यह सुनिश्चित करता है कि, हमारे उदाहरण uWSGI एप्लिकेशन के लिए, एक 500 Error प्रतिक्रिया को Nginx द्वारा रोका और संभाला जाता है।
proxy_hide_header: जैसा कि नाम से स्पष्ट है, यह निर्देश क्लाइंट से निर्दिष्ट HTTP हेडर को छुपाता है, जिससे गोपनीयता और सुरक्षा बढ़ती है।

जब एक मान्य GET अनुरोध किया जाता है, तो Nginx इसे सामान्य रूप से संसाधित करता है, बिना किसी गुप्त हेडर को प्रकट किए एक मानक त्रुटि प्रतिक्रिया लौटाता है। हालाँकि, एक अमान्य HTTP अनुरोध इस तंत्र को बायपास करता है, जिससे कच्ची बैकएंड प्रतिक्रियाएँ, जिसमें गुप्त हेडर और त्रुटि संदेश शामिल हैं, उजागर होती हैं।

merge_slashes को बंद करना

डिफ़ॉल्ट रूप से, Nginx का merge_slashes निर्देश on पर सेट होता है, जो एक URL में कई फॉरवर्ड स्लैश को एकल स्लैश में संकुचित करता है। यह सुविधा, जबकि URL प्रसंस्करण को सरल बनाती है, Nginx के पीछे अनुप्रयोगों में कमजोरियों को अनजाने में छिपा सकती है, विशेष रूप से स्थानीय फ़ाइल समावेश (LFI) हमलों के प्रति संवेदनशील। सुरक्षा विशेषज्ञ Danny Robinson और Rotem Bar ने इस डिफ़ॉल्ट व्यवहार से जुड़े संभावित जोखिमों को उजागर किया है, विशेष रूप से जब Nginx एक रिवर्स-प्रॉक्सी के रूप में कार्य करता है।

ऐसे जोखिमों को कम करने के लिए, उन अनुप्रयोगों के लिए merge_slashes निर्देश को बंद करना अनुशंसित है जो इन कमजोरियों के प्रति संवेदनशील हैं। यह सुनिश्चित करता है कि Nginx अनुरोधों को अनुप्रयोग की ओर बिना URL संरचना को बदले अग्रेषित करता है, जिससे किसी भी अंतर्निहित सुरक्षा मुद्दों को छिपाया नहीं जाता है।

अधिक जानकारी के लिए Danny Robinson और Rotem Bar की जाँच करें।

Maclicious Response Headers

जैसा कि इस लेख में दिखाया गया है, कुछ हेडर हैं जो यदि वे वेब सर्वर से प्रतिक्रिया में मौजूद हैं तो वे 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 (पथ यात्रा) की सामग्री भेजेगा।

Map Directive में डिफ़ॉल्ट मान

Nginx कॉन्फ़िगरेशन में, map निर्देश अक्सर अधिकार नियंत्रण में भूमिका निभाता है। एक सामान्य गलती डिफ़ॉल्ट मान निर्दिष्ट न करना है, जो अनधिकृत पहुंच का कारण बन सकता है। उदाहरण के लिए:

http {
map $uri $mappocallow {
/map-poc/private 0;
/map-poc/secret 0;
/map-poc/public 1;
}
}

server {
location /map-poc {
if ($mappocallow = 0) {return 403;}
return 200 "Hello. It is private area: $mappocallow";
}
}

बिना default के, एक दुष्ट उपयोगकर्ता /map-poc के भीतर एक अपरिभाषित URI तक पहुँचकर सुरक्षा को बायपास कर सकता है। Nginx मैनुअल ऐसे मुद्दों से बचने के लिए डिफ़ॉल्ट मान सेट करने की सलाह देता है।

DNS Spoofing Vulnerability

Nginx के खिलाफ DNS स्पूफिंग कुछ शर्तों के तहत संभव है। यदि एक हमलावर को Nginx द्वारा उपयोग किए जाने वाले DNS सर्वर का ज्ञान है और वह इसके DNS प्रश्नों को इंटरसेप्ट कर सकता है, तो वह DNS रिकॉर्ड को स्पूफ कर सकता है। हालाँकि, यह विधि प्रभावी नहीं है यदि Nginx को DNS समाधान के लिए localhost (127.0.0.1) का उपयोग करने के लिए कॉन्फ़िगर किया गया है। Nginx एक DNS सर्वर को इस प्रकार निर्दिष्ट करने की अनुमति देता है:

resolver 8.8.8.8;

`proxy_pass` और `internal` निर्देश

proxy_pass निर्देश का उपयोग अनुरोधों को अन्य सर्वरों की ओर पुनर्निर्देशित करने के लिए किया जाता है, चाहे वह आंतरिक हो या बाहरी। internal निर्देश यह सुनिश्चित करता है कि कुछ स्थान केवल Nginx के भीतर ही सुलभ हैं। जबकि ये निर्देश अपने आप में कमजोरियाँ नहीं हैं, उनकी कॉन्फ़िगरेशन की सावधानीपूर्वक जांच की आवश्यकता होती है ताकि सुरक्षा में चूक न हो।

proxy_set_header Upgrade & Connection

यदि nginx सर्वर को Upgrade और Connection हेडर पास करने के लिए कॉन्फ़िगर किया गया है, तो एक h2c Smuggling attack किया जा सकता है ताकि संरक्षित/आंतरिक एंडपॉइंट्स तक पहुँच प्राप्त की जा सके।

यह कमजोरी एक हमलावर को proxy_pass एंडपॉइंट के साथ एक सीधा कनेक्शन स्थापित करने की अनुमति देगी (http://backend:9999 इस मामले में) जिसका सामग्री nginx द्वारा जांचा नहीं जाएगा।

/flag को चुराने के लिए कमजोर कॉन्फ़िगरेशन का उदाहरण यहाँ है:

server {
listen       443 ssl;
server_name  localhost;

ssl_certificate       /usr/local/nginx/conf/cert.pem;
ssl_certificate_key   /usr/local/nginx/conf/privkey.pem;

location / {
proxy_pass http://backend:9999;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
}

location /flag {
deny all;
}

ध्यान दें कि भले ही proxy_pass एक विशिष्ट पथ की ओर इशारा कर रहा हो जैसे http://backend:9999/socket.io, कनेक्शन http://backend:9999 के साथ स्थापित होगा, इसलिए आप उस आंतरिक एंडपॉइंट के अंदर किसी अन्य पथ से संपर्क कर सकते हैं। इसलिए यह मायने नहीं रखता कि proxy_pass के URL में कोई पथ निर्दिष्ट किया गया है।

खुद कोशिश करें

Detectify ने एक GitHub रिपॉजिटरी बनाई है जहाँ आप Docker का उपयोग करके अपने स्वयं के कमजोर Nginx परीक्षण सर्वर को स्थापित कर सकते हैं जिसमें इस लेख में चर्चा की गई कुछ गलत कॉन्फ़िगरेशन हैं और उन्हें खुद खोजने की कोशिश कर सकते हैं!

https://github.com/detectify/vulnerable-nginx

स्थिर विश्लेषक उपकरण

GIXY

Gixy Nginx कॉन्फ़िगरेशन का विश्लेषण करने के लिए एक उपकरण है। Gixy का मुख्य लक्ष्य सुरक्षा गलत कॉन्फ़िगरेशन को रोकना और दोष पहचान को स्वचालित करना है।

Nginxpwner

Nginxpwner सामान्य Nginx गलत कॉन्फ़िगरेशन और कमजोरियों की खोज के लिए एक सरल उपकरण है।

संदर्भ

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