Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-30 00:20:59 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/network-services-pentesting/pentesting-web/nginx.md

30 KiB
Raw Blame History

Nginx

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

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

DragonJAR Security Conference एक अंतर्राष्ट्रीय साइबर सुरक्षा इवेंट है जो एक दशक से अधिक समय से चल रहा है और 7 और 8 सितंबर 2023 को बोगोटा, कोलंबिया में आयोजित किया जाएगा। यह एक उच्च तकनीकी सामग्री वाला इवेंट है जहां स्पेनिश में नवीनतम अनुसंधान प्रस्तुत किए जाते हैं जो दुनिया भर के हैकर्स और शोधकर्ताओं को आकर्षित करते हैं।
अभी निम्नलिखित लिंक पर रजिस्टर करें और इस महान सम्मेलन को मिस न करें!:

{% embed url="https://www.dragonjarcon.org/" %}

Missing root location 

server {
root /etc/nginx;

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

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

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

Alias LFI Misconfiguration

Nginx कॉन्फ़िगरेशन के अंदर "location" वक्तव्यों को देखें, यदि कोई इस तरह दिखता है:

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

इसमें LFI संवेदनशीलता है क्योंकि:

/imgs../flag.txt

# NGINX पेंटेस्टिंग

## सामान्य जानकारी

NGINX एक लोकप्रिय वेब सर्वर है जो अपाचे के विकल्प के रूप में उभरा है। यह उच्च प्रदर्शन, स्थिरता, सरल कॉन्फ़िगरेशन, और कम संसाधन की खपत के लिए जाना जाता है।

## सुरक्षा जांच

### संस्करण की जांच

सर्वर के संस्करण की जानकारी अक्सर HTTP हेडर्स में पाई जाती है। इसे निम्नलिखित कमांड के साथ प्राप्त किया जा सकता है:

curl -I 


सर्वर से `Server` हेडर में NGINX संस्करण की जानकारी मिल सकती है।

### डिफ़ॉल्ट फ़ाइलें और निर्देशिकाएँ

NGINX सर्वर पर डिफ़ॉल्ट फ़ाइलें और निर्देशिकाएँ संवेदनशील जानकारी का स्रोत हो सकती हैं। इन्हें खोजने के लिए, निम्नलिखित उपकरण और तकनीकें उपयोगी हो सकती हैं:

- `dirb`
- `gobuster`
- `nikto`

### संवेदनशील फ़ाइलें

कुछ फ़ाइलें जैसे कि `.git`, `.hg`, `.svn`, `backup.tar.gz`, या `dump.sql` सर्वर पर अनजाने में छोड़ी गई हो सकती हैं और यदि उन्हें एक्सेस किया जा सके तो वे संवेदनशील जानकारी का खुलासा कर सकती हैं।

### सर्वर कॉन्फ़िगरेशन त्रुटियाँ

गलत तरीके से कॉन्फ़िगर किए गए सर्वर अनधिकृत पहुँच या जानकारी के लीक का कारण बन सकते हैं। इसमें शामिल हैं:

- अनुचित फ़ाइल अनुमतियाँ
- डिफ़ॉल्ट क्रेडेंशियल्स
- अनुचित डायरेक्टरी लिस्टिंग्स

### SSL/TLS जांच

SSL/TLS कॉन्फ़िगरेशन की जांच करने के लिए, निम्नलिखित उपकरण उपयोगी हो सकते हैं:

- `sslyze`
- `testssl.sh`
- `Qualys SSL Labs' SSL Test`

ये उपकरण सर्टिफिकेट की वैधता, समर्थित साइफर्स, और अन्य सुरक्षा जांचों के लिए उपयोगी हैं।

## उपयोगी कमांड्स

यहाँ कुछ उपयोगी कमांड्स दी गई हैं जो NGINX पेंटेस्टिंग के दौरान काम आ सकती हैं:

curl -I nikto -h gobuster dir -u -w 


इन कमांड्स का उपयोग सर्वर की जानकारी प्राप्त करने, संवेदनशील फ़ाइलों की खोज करने, और सुरक्षा जांच करने के लिए किया जा सकता है।

/path/images/../flag.txt

सही कॉन्फ़िगरेशन होगा:

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

तो, यदि आपको कोई Nginx सर्वर मिलता है तो आपको इस संवेदनशीलता की जांच करनी चाहिए। साथ ही, यदि आप पाते हैं कि फाइल/डायरेक्टरीज़ की ब्रूट फोर्स अजीब तरह से व्यवहार कर रही है, तो आप इसे खोज सकते हैं।

अधिक जानकारी: 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;
}

{% content-ref url="../../pentesting-web/proxy-waf-protections-bypass.md" %} proxy-waf-protections-bypass.md {% endcontent-ref %}

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

एक संवेदनशील Nginx कॉन्फ़िगरेशन का उदाहरण है:

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

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

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/ पर।

कोई भी वेरिएबल

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

इसकी जांच करने का एक तरीका है रेफरर हेडर मान सेट करना:

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

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

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

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

यदि एक क्लाइंट Nginx को एक अमान्य HTTP अनुरोध भेजता है, तो वह अनुरोध जैसा है वैसा ही बैकएंड को फॉरवर्ड किया जाएगा, और बैकएंड अपनी कच्ची सामग्री के साथ उत्तर देगा। फिर, Nginx अमान्य HTTP प्रतिक्रिया को समझ नहीं पाएगा और बस इसे क्लाइंट को फॉरवर्ड कर देगा। इसे एक 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](http://nginx.org/en/docs/http/ngx\_http\_proxy\_module.html#proxy\_intercept\_errors) का उपयोग करके यदि बैकएंड का रिस्पॉन्स स्टेटस 300 से अधिक है, तो एक कस्टम रिस्पॉन्स प्रदान किया जाएगा। हमारे uWSGI एप्लिकेशन में ऊपर, हम `500 Error` भेजेंगे जिसे Nginx द्वारा इंटरसेप्ट किया जाएगा।

[proxy\_hide\_header](http://nginx.org/en/docs/http/ngx\_http\_proxy\_module.html#proxy\_hide\_header) काफी हद तक स्वयं स्पष्ट है; यह क्लाइंट से किसी भी निर्दिष्ट HTTP हेडर को छिपाएगा।

यदि हम एक सामान्य `GET` अनुरोध भेजते हैं, तो Nginx वापस करेगा:

HTTP/1.1 500 Internal Server Error
Server: nginx/1.10.3
Content-Type: text/html
Content-Length: 34
Connection: close

लेकिन अगर हम एक अमान्य HTTP अनुरोध भेजते हैं, जैसे कि:

GET /? XTTP/1.1
Host: 127.0.0.1
Connection: close

हमें निम्नलिखित प्रतिक्रिया मिलेगी:

XTTP/1.1 500 Error
Content-Type: text/html
Secret-Header: secret-info

Secret info, should not be visible!

merge_slashes को off सेट किया गया है

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

हमें 33 Nginx कॉन्फ़िगरेशन फ़ाइलें मिलीं जिनमें merge_slashes को "off" पर सेट किया गया है।

map निर्देश के लिए default निर्दिष्ट नहीं है

यह एक सामान्य मामला प्रतीत होता है जब 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 के अंदर अस्तित्वहीन मामले तक पहुँचकर जैसे कि https://targethost.com/map-poc/another-private-area.

DNS Spoofing Nginx

इस पोस्ट के अनुसार: http://blog.zorinaq.com/nginx-resolver-vulns/ DNS रिकॉर्ड्स को स्पूफ करना संभव हो सकता है Nginx के लिए यदि आप DNS सर्वर जानते हैं जिसका उपयोग Nginx कर रहा है (और आप किसी तरह संचार को इंटरसेप्ट कर सकते हैं, इसलिए यह मान्य नहीं है अगर 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 हमला किया जा सकता है।

{% hint style="danger" %} यह कमजोरी हमलावर को proxy_pass एंडपॉइंट (http://backend:9999 इस मामले में) के साथ सीधा संबंध स्थापित करने की अनुमति देगी जिसकी सामग्री nginx द्वारा जांची नहीं जाएगी। {% endhint %}

यहाँ से /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;
}

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

इसे स्वयं आजमाएं

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

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

स्टैटिक एनालाइज़र टूल्स

GIXY

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

Nginxpwner

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

संदर्भ

DragonJAR Security Conference es un evento internacional de ciberseguridad जो एक दशक से अधिक समय से चल रहा है और यह 7 और 8 सितंबर 2023 को बोगोटा, कोलंबिया में आयोजित किया जाएगा। यह एक उच्च तकनीकी सामग्री वाला कार्यक्रम है जहाँ स्पेनिश में नवीनतम अनुसंधान प्रस्तुत किए जाते हैं जो दुनिया भर के हैकर्स और शोधकर्ताओं को आकर्षित करता है।
अभी निम्नलिखित लिंक पर पंजीकरण करें और इस महान सम्मेलन को मिस न करें!:

{% embed url="https://www.dragonjarcon.org/" %}

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!

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