Mirrors/hacktricks

Fork 0

mirror of https://github.com/carlospolop/hacktricks synced 2024-12-04 10:30:26 +00:00

Translator workflow 75e8745ba3 Translated to Hindi

2023-11-06 08:38:02 +00:00

34 KiB

Raw Blame History

एनजिनक्स

☁️ हैकट्रिक्स क्लाउड ☁️ -🐦 ट्विटर 🐦 - 🎙️ ट्विच 🎙️ - 🎥 यूट्यूब 🎥

क्या आप साइबर सुरक्षा कंपनी में काम करते हैं? क्या आप अपनी कंपनी को हैकट्रिक्स में विज्ञापित देखना चाहते हैं? या क्या आपको PEASS की नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करने का उपयोग करने की इच्छा है? सदस्यता योजनाएं की जांच करें!
खोजें द पीएस फैमिली, हमारा एक्सक्लूसिव एनएफटी संग्रह
प्राप्त करें आधिकारिक पीएस और हैकट्रिक्स स्वैग
शामिल हों 💬 डिस्कॉर्ड समूह या टेलीग्राम समूह या मुझे ट्विटर पर फॉलो करें 🐦@carlospolopm.
अपने हैकिंग ट्रिक्स को हैकट्रिक्स रेपो (https://github.com/carlospolop/hacktricks) और हैकट्रिक्स-क्लाउड रेपो में पीआर जमा करके अपने हैकिंग ट्रिक्स साझा करें।

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

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

गुम रूट स्थान

server {
root /etc/nginx;

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

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

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

अलियास LFI त्रुटि समाकृति

Nginx कॉन्फ़िगरेशन के भीतर "स्थान" विधानों को देखें, यदि कोई ऐसा दिखता है:

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

यहाँ एक LFI संकट है क्योंकि:

/imgs../flag.txt

Nginx

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

नेटवर्क सेवाओं के पेंटेस्टिंग के लिए उपयोगी टिप्स

1. नेटवर्क स्कैनिंग

Nginx सर्वर की पहचान करने के लिए, आप नेटवर्क स्कैनिंग टूल्स जैसे Nmap का उपयोग कर सकते हैं। Nmap के द्वारा आप निम्नलिखित जानकारी प्राप्त कर सकते हैं:

खुले पोर्ट्स की सूची
चल रहे सेवाओं की सूची
नेटवर्क टोपोलॉजी

2. वेब सर्वर कॉन्फ़िगरेशन की जांच

Nginx कॉन्फ़िगरेशन फ़ाइल (/etc/nginx/nginx.conf) की जांच करें और अनुमतियों, अनामित सर्वर ब्लॉक और अनुप्रयोगों को खोजें। यह आपको सुरक्षा की कमियों की जांच करने में मदद करेगा।

3. डायरेक्टरी लिस्टिंग

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

4. वेब फ़ाइल्स की जांच

वेब साइट के लिए उपलब्ध फ़ाइलों की जांच करें और संभावित गंभीरता के संकेतों को खोजें। यह आपको वेब साइट के अंदर की जानकारी प्राप्त करने में मदद करेगा।

5. वेब एप्लीकेशन विश्लेषण

वेब एप्लीकेशन के विश्लेषण के लिए टूल्स जैसे Burp Suite और OWASP ZAP का उपयोग करें। यह आपको संभावित सुरक्षा की कमियों की जांच करने में मदद करेगा।

6. वेब सर्वर के लिए अनुप्रयोगों की जांच

वेब सर्वर पर चल रहे अनुप्रयोगों की जांच करें और संभावित गंभीरता के संकेतों को खोजें। यह आपको वेब सर्वर की सुरक्षा की कमियों की जांच करने में मदद करेगा।

7. वेब फ़ाइल्स की लीकेज़

वेब साइट पर लीक हो सकने वाली गोपनीयता संबंधी जानकारी की जांच करें, जैसे कि डेटाबेस के लॉगिन क्रेडेंशियल्स, कॉन्फ़िगरेशन फ़ाइलों की जानकारी, और अन्य संबंधित फ़ाइलें।

8. वेब सर्वर के लिए दूसरे टेक्नोलॉजीज़ की जांच

वेब सर्वर के साथ जुड़े अन्य टेक्नोलॉजीज़ की जांच करें, जैसे कि डेटाबेस, कैश, और अन्य संबंधित सेवाएं। यह आपको सुरक्षा की कमियों की जांच करने में मदद करेगा।

9. वेब फ़ाइल्स की अनुमतियों की जांच

वेब साइट के लिए उपलब्ध फ़ाइलों की अनुमतियों की जांच करें और संभावित अनुमति द्वारा उत्पन्न सुरक्षा की कमियों की जांच करें।

10. वेब फ़ाइल्स की अपवाद

वेब साइट पर अपवादित फ़ाइलों की जांच करें, जैसे कि अपवादित कॉन्फ़िगरेशन फ़ाइलें, अपवादित स्क्रिप्ट फ़ाइलें, और अन्य संबंधित फ़ाइलें।

11. वेब फ़ाइल्स की अद्यतनीयता की जांच

वेब साइट पर अद्यतनीय नहीं होने वाली फ़ाइलों की जांच करें, जैसे कि पुराने या अपवादित संस्करणों की जांच करें। यह आपको सुरक्षा की कमियों की जांच करने में मदद करेगा।

12. वेब सर्वर के लिए लॉग विश्लेषण

Nginx लॉग फ़ाइलों की जांच करें और लॉग विश्लेषण टूल्स जैसे ELK Stack का उपयोग करें। यह आपको सुरक्षा की कमियों की जांच करने में मदद करेगा।

यहां दी गई टिप्स का उपयोग करके आप Nginx सर्वर की सुरक्षा की कमियों की जांच कर सकते हैं और संभावित गंभीरता को ठीक करने के लिए उपाय ढूंढ सकते हैं।

/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;
}

असुरक्षित चर उपयोग

एक असुरक्षित Nginx कॉन्फ़िगरेशन का उदाहरण है:

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

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

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

जानें https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/ पर CRLF इंजेक्शन और रिस्पॉन्स स्प्लिटिंग के जोखिमों के बारे में और अधिक।

कोई भी चर

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

इसका परीक्षण करने का एक तरीका एक referer हेडर मान सेट करना है:

$ 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 यदि बैकएंड का प्रतिक्रिया स्थिति 300 से अधिक होती है तो एक कस्टम प्रतिक्रिया प्रदान करेगा। हमारे uWSGI एप्लिकेशन में, हम एक 500 त्रुटि भेजेंगे जो Nginx द्वारा अवरोधित की जाएगी।

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 को बंद करें

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

हमने 33 Nginx कॉन्फ़िगरेशन फ़ाइलें खोजी हैं जिनमें merge_slashes को "बंद" कर दिया गया है।

map निर्देशिका के लिए डिफ़ॉल्ट निर्दिष्ट नहीं है

ऐसा लगता है कि यह सामान्य मामला है जब 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 पहुँचता है।

Nginx में DNS Spoofing

इस पोस्ट के अनुसार: http://blog.zorinaq.com/nginx-resolver-vulns/ यदि आपको पता है कि Nginx कौन सा DNS सर्वर उपयोग कर रहा है (और आप किसी तरीके से संचार को अवरोधित कर सकते हैं, इसलिए यह 127.0.0.1 का उपयोग नहीं किया जाता है) और डोमेन जिसकी जांच की जा रही है, तो Nginx को DNS रिकॉर्ड को निर्दिष्ट करने के लिए संभव हो सकता है।

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 के साथ स्थापित किया जाएगा, इसलिए आप उस आंतरिक अंतबिंदु के भीतर किसी अन्य पथ से संपर्क कर सकते हैं। इसलिए प्रॉक्सी_पास के 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 con más de una década que se celebrará el 7 y 8 de septiembre de 2023 en Bogotá, Colombia. Es un evento de gran contenido técnico donde se presentan las últimas investigaciones en español que atrae a hackers e investigadores de todo el mundo.
¡Regístrate ahora en el siguiente enlace y no te pierdas esta gran conferencia!: