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+ कस्टम टूल का उपयोग करके हमले की सतह का मानचित्रण करें, सुरक्षा मुद्दों को खोजें जो आपको विशेषाधिकार बढ़ाने की अनुमति देते हैं, और आवश्यक सबूत इकट्ठा करने के लिए स्वचालित शोषण का उपयोग करें, जिससे आपका कठिन काम प्रभावशाली रिपोर्टों में बदल जाए।

Penetration testing toolkit, ready to usePentest-Tools.com

Missing root location

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

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-कोडित रूप %0d%0a के रूप में दर्शाए जाते हैं। एक अनुरोध में इन वर्णों को शामिल करने पर (जैसे, http://localhost/%0d%0aDetectify:%20clrf) एक गलत कॉन्फ़िगर किए गए सर्वर पर सर्वर एक नए हेडर का नाम Detectify जारी करता है। यह इसलिए होता है क्योंकि $uri वेरिएबल URL-कोडित नए लाइन वर्णों को डिकोड करता है, जिससे प्रतिक्रिया में एक अप्रत्याशित हेडर उत्पन्न होता है:

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’

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

कच्चे बैकएंड प्रतिक्रिया पढ़ना

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 स्पूफिंग कमजोरियाँ

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 गलत कॉन्फ़िगरेशन और कमजोरियों की खोज करता है।

संदर्भ

• https://blog.detectify.com/2020/11/10/common-nginx-misconfigurations/

• http://blog.zorinaq.com/nginx-resolver-vulns/

• https://github.com/yandex/gixy/issues/115

अपने वेब ऐप्स, नेटवर्क और क्लाउड पर एक हैकर का दृष्टिकोण प्राप्त करें

महत्वपूर्ण, शोषण योग्य कमजोरियों को खोजें और रिपोर्ट करें जिनका वास्तविक व्यावसायिक प्रभाव है। हमारे 20+ कस्टम उपकरणों का उपयोग करके हमले की सतह का मानचित्रण करें, सुरक्षा मुद्दों को खोजें जो आपको विशेषाधिकार बढ़ाने की अनुमति देते हैं, और आवश्यक सबूत इकट्ठा करने के लिए स्वचालित शोषण का उपयोग करें, जिससे आपका कठिन काम प्रभावशाली रिपोर्टों में बदल जाए।

Penetration testing toolkit, ready to usePentest-Tools.com

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)

HackTricks का समर्थन करें

• सदस्यता योजनाएँ देखें!

• हमारे 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या Twitter 🐦 पर हमें फॉलो करें @hacktricks_live.

• हैकिंग ट्रिक्स साझा करें और HackTricks और HackTricks Cloud GitHub रिपॉजिटरी में PR सबमिट करें।