Hindi - Ht

Nginx

जानें AWS हैकिंग को शून्य से हीरो तक htARTE (HackTricks AWS Red Team Expert) के साथ!

HackTricks का समर्थन करने के अन्य तरीके:

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

Missing root location

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

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 बेसिक प्रमाणीकरण के लिए उपयोग किए जाने वाले एन्क्रिप्टेड क्रेडेंशियल्स भी शामिल हो सकते हैं।

उपनाम LFI गलतियों

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

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

असुरक्षित पथ प्रतिबंध

निम्नलिखित पृष्ठ की जाँच करें ताकि आप जैसे निर्देशों को छोड़ सकें:

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

असुरक्षित वेरिएबल का उपयोग / एचटीटीपी रिक्वेस्ट स्प्लिटिंग

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

रेजेक्स भी विकल्पनीय हो सकता है जैसे:

location ~ /docs/([^/])? { … $1 … } - विकल्पनीय

location ~ /docs/([^/\s])? { … $1 … } - विकल्पनीय नहीं (अंतरिक्ष की जांच)

location ~ /docs/(.*)? { … $1 … } - विकल्पनीय नहीं

निम्नलिखित उदाहरण द्वारा Nginx कॉन्फ़िगरेशन में एक सुरक्षा कमी का प्रदर्शन किया गया है:

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

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

कोई भी चर

पाया गया कि उपयोक्ता द्वारा प्रदत्त डेटा को कुछ परिस्थितियों के तहत एक Nginx चर के रूप में व्यवहारित किया जा सकता है। इस व्यवहार का कारण कुछ हद तक अज्ञात है, फिर भी यह अद्भुत नहीं है और स्पष्टीकृत करना सरल नहीं है। इस विसंगति को हाइकरवन पर एक सुरक्षा रिपोर्ट में उजागर किया गया था, जिसे यहाँ देखा जा सकता है। त्रुटि संदेश की अध्ययन के बाद और अधिक जांच में, इसकी पहचान 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 त्रुटि प्रतिक्रिया को Nginx द्वारा रोका और संभाला जाता है।

  • proxy_hide_header: जैसा नाम सूचित करता है, यह निर्देशिका ग्राहक से निर्दिष्ट HTTP हेडर को छुपाती है, गोपनीयता और सुरक्षा को बढ़ाती है।

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

merge_slashes set to off

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

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

अधिक जानकारी के लिए डैनी रॉबिंसन और रोटेम बार की जांच करें।

मैलिशस प्रतिक्रिया हेडर्स

जैसा कि इस लेखन में दिखाया गया है, कुछ हेडर्स हैं जो यदि वेब सर्वर से प्रतिक्रिया में मौजूद हैं तो वे 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 एक आंतरिक रीडायरेक्ट का कारण बनेगा एनजीनक्स में। इसलिए कुछ ऐसे एनजीनक्स कॉन्फ़िगरेशन के साथ जैसे root / और वेब सर्वर से एक प्रतिक्रिया जिसमें X-Accel-Redirect: .env है, एनजीनक्स /.env की सामग्री भेज देगा (पथ ट्रावर्सल)।

मानचित्र निर्देशिका में डिफ़ॉल्ट मान

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 अपग्रेड और कनेक्शन

यदि nginx सर्वर को अपग्रेड और कनेक्शन हेडर पास करने के लिए कॉन्फ़िगर किया गया है तो 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+ उपकरण और सुविधाओं के साथ पूर्ण पेनटेस्ट चलाएं जो पुनरीक्षण से रिपोर्टिंग तक जाते हैं। हम पेनटेस्टर्स को बदलने नहीं हैं - हम उन्हें वापस कुछ समय देने के लिए कस्टम उपकरण, पता लगाने और शोषण मॉड्यूल विकसित करते हैं ताकि वे गहराई में खोज कर सकें, शैल्स पॉप कर सकें, और मज़ा कर सकें।

जानें AWS हैकिंग को शून्य से हीरो तक htARTE (HackTricks AWS Red Team Expert) के साथ!

HackTricks का समर्थन करने के अन्य तरीके:

PreviousMoodleNextPHP Tricks

Last updated