🥦 👸🏽 🤾🏿 सर्वर अनुरोध जालसाजी, ब्लाइंड SSRF ऑपरेशन 🧛🏼 ⛄️ 🙎🏾

SSRF नामक एक ऐसी चीज है। उसके बारे में बहुत कुछ लिखा गया है, लेकिन फिर भी, मैं आपको संक्षेप में बताऊंगा।
मान लीजिए कि आप साइट पर जाते हैं, प्रोफ़ाइल भरें और "अवतार अपलोड करें" आइटम पर जाएं। और आपके पास एक विकल्प है - एक फ़ाइल अपलोड करें या एक लिंक निर्दिष्ट करें।

इस मामले में, हम दूसरे बिंदु में रुचि रखते हैं। यदि हम एक ऐसे संसाधन का लिंक प्रदान करते हैं जिसमें एक छवि है, तो वेब अनुप्रयोग:

इसे डाउनलोड करता है
जाँच लें कि चित्र चित्र है
आकार की जांच करें, क्योंकि वे फिट नहीं हो सकते हैं
इसे उपयोगकर्ता को प्रदर्शित करें (काटने के लिए)

तो यहाँ है। यदि साइट यह जांच नहीं करती है कि वह छवि को कहाँ से डाउनलोड करने की कोशिश कर रही है, तो यह एक भेद्यता है (एक नियम के रूप में)। इसके अलावा, छवियों को डाउनलोड करने जैसी छोटी सुविधा पर हमलों के वैक्टर इतने व्यापक हैं कि सभी विकल्पों के माध्यम से जाने के लिए बार में पर्याप्त जमा नहीं है।

मुझसे एक बार पूछा गया था - “मैं केवल एक http (s) लिंक डाल सकता हूं तो मैं क्या कर सकता हूं? यह कुछ भी नहीं देता! "
मैं आपको बताता हूं।

सबसे आसान विकल्प अंदर सेवाओं की पहचान करने की कोशिश करना है। अगर हम चित्र के बारे में बात कर रहे हैं, तो आप फ़ेविकॉनो, लोगो या आइकन निर्देशिका जैसे मानक पथों को देखने का प्रयास कर सकते हैं, यह सुझाव देते हुए कि अपाचे का उपयोग किया जाता है। अनुरोध भेजने से, हम लोकप्रिय स्थानीय पते, साथ ही साथ आंतरिक अवसंरचना में काम करने वाले साइट के उप-डोमेन पर पुनरावृति कर सकते हैं। ये सभी कंपनियों द्वारा सभी प्रकार के बांस, जीरा, गीतालाब और अन्य चीजें प्रिय हैं।

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

खैर, हमें आईपी पते दर्ज करने की अनुमति देने से मना किया गया था। मान लीजिए कि हमारे पास बुनियादी ढांचे के अंदर कुछ महत्वपूर्ण संसाधन हैं और इसका आईपी पता 192.168.1.1 है

सबसे पहले, हम मानसिक रूप से एक डोमेन शुरू करते हैं जिससे हम इस आईपी को असाइन करेंगे। इसे मेरे-test-site.com होने दें। वास्तविक जीवन में, आपको उप-डोमेन बनाना चाहिए, जिसका पता हमें उस आईपी को निर्देशित किया जाएगा जिसकी हमें आवश्यकता है, लेकिन बाद में और भी।

पासवर्ड जानवर बल

चलो सपना देखते हैं कि हमारे पास एक राउटर है। / व्यवस्थापक / निर्देशिका बेसिक कोरियर के अंतर्गत है। लिंक को बदलकर, हम राउटर के लिए लॉगिन और पासवर्ड का चयन कर सकते हैं। लेकिन यहाँ यह काफी सरल है, हम सिर्फ फॉर्म का लिंक बनाते हैं

http://login:password@my-test-site.com/admin/

इस प्रकार, बृहदान्त्र से पहले का मूल्य लॉगिन होगा, इसके बाद - पासवर्ड। और @ साइन के माध्यम से एक डोमेन होगा जहां यह डेटा भेजा जाएगा। कृपया ध्यान दें कि यह उन सभी प्रकार के संपर्क लोगों के साथ काम नहीं करता है जहाँ आपको एक फ़ॉर्म भरने की आवश्यकता है। इसलिए, मूल प्रमाणीकरण की आवश्यकता है - सर्वर से 401 प्रतिक्रिया के साथ एक पॉप-अप विंडो।

यदि हम भाग्यशाली थे और साइट कम से कम प्रतिक्रिया कोड (200, 401, 503) वापस कर देगी, तो यह बहुत आसान होगा। तब हम स्पष्ट रूप से प्रक्रिया का निरीक्षण कर सकते हैं और अपनी जीत देख सकते हैं:

http://admin:password@my-test-site.com/admin/ - 401
http://admin:admin@my-test-site.com/admin/ - 401
http://admin:123456@my-test-site.com/admin/ - 200

एक दर्जन या दो ऐसे अनुरोधों को भेजकर, आप इस राउटर के लिए पासवर्ड खोजने का प्रयास कर सकते हैं। और फिर अपनी डीएनएस या यहां तक कि /reboot.cgi को बचाने के लिए स्क्रिप्ट की ओर मुड़ें

और अगर कोई जवाब नहीं है और यह हमेशा एक ही है?

यहाँ समय हमारी मदद करेगा।

समय

हर चीज में समय लगता है। जैसा कि मैंने आपका समय एक लेख पढ़ने के लिए लिया है, इसलिए सेवाएं प्रतिक्रिया देने के लिए आपका समय लेती हैं।
ख़ासियत यह है कि हम आंतरिक संसाधनों तक पहुंचने की कोशिश कर सकते हैं और सवाल का जवाब देने के लिए समय को माप सकते हैं - क्या वहां कोई सेवा है या नहीं?
कई अनुरोध भेजने के बाद, आप नेत्रहीन आंतरिक सेवाओं, बंदरगाहों और यहां तक कि निर्देशिकाओं और फ़ाइलों के माध्यम से हल कर सकते हैं, जवाबों की एक विसंगति पर भरोसा करते हैं।

1302 ms - http://test.company.com
1307 ms - http://db.company.com
5483 ms - http://jira.company.com
1410 ms - http://docs.company.com
1366 ms - http://kafka.company.com

जीरा उपडोमेन ने सबसे लंबे समय तक जवाब दिया, सबसे अधिक संभावना है कि यह अंदर है, और अंतर इस तथ्य के कारण ध्यान देने योग्य है कि वेब सर्वर ने पृष्ठ को लोड करने की कोशिश की, और फिर महसूस किया कि यह एक छवि नहीं थी। और जो हमारे लिए मायने रखता है वह यह नहीं है कि "सबसे लंबे समय तक उत्तर किसने दिया?", लेकिन ठीक है "जिसने अन्य सभी को पसंद नहीं किया?" क्योंकि समय एक देरी की तरह हो सकता है - उदाहरण के लिए, यदि आपको एक बड़ी फ़ाइल या स्क्रिप्ट मिलती है जिसे निष्पादित करने में लंबा समय लगता है। या इसके विपरीत, एक त्वरित जवाब।

1302 ms - http://test.company.com
1307 ms - http://db.company.com
423 ms - http://jira.company.com
1410 ms - http://docs.company.com
1366 ms - http://kafka.company.com

इस मामले में, उत्तर कहता है कि यह 401 या पुनर्निर्देशित है जो छवि पार्सर को संसाधित नहीं करता है। या हो सकता है कि साइट सुलभ हो, लेकिन पहले बाइट्स या सामग्री-प्रकार की जांच करने के बाद, हमारे वेब एप्लिकेशन ने पृष्ठ को पूरी तरह से डाउनलोड करने से पहले इसे अस्वीकार कर दिया। इस उदाहरण की अन्य साइटें कनेक्शन के लिए प्रतीक्षा नहीं करती थीं (या होस्टनाम अपडेट नहीं किया गया था)

आईपी सत्यापन तंत्र

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

डोमेन my-test-site.com के पहले अनुरोध पर, एक बाहरी IP दें, उदाहरण के लिए 123.123.123.123
और जैसे ही यह सत्यापन पास करता है, उसी डोमेन पर आंतरिक आईपी भेजना शुरू करें।

इस मामले में, एमिल लर्नर ने एक अच्छी सेवा की - 1u.ms!

आपके द्वारा निर्दिष्ट IP पतों के साथ 1u.ms डोमेन उत्तर।

डोमेन का प्रारूप इस प्रकार होना चाहिए:

make-%IP%-rebind-%IP-rr.1u.ms

उदाहरण के लिए

make-123.123.123.123-rebind-127.0.0.1-rr.1u.ms

पहला अनुरोध 123.123.123.123 पते के साथ उत्तर दिया जाएगा, और दूसरा अनुरोध पहले से ही 127.0.0.1 पर जवाब दिया जाएगा (यदि वे एक के बाद एक, 5 सेकंड के भीतर)।

वैसे, यदि आप एक उपडोमेन की जरूरत है, तो आईपी पते को डॉट्स के बिना लिखा जा सकता है:

make-123-123-123-123-rebind-127-0-0-1-rr.1u.ms

वैसे, rr से पहले और बाद में, आप कैश्ड डेटा के उपयोग को रोकने के लिए मनमाने शब्द लिख सकते हैं:

bo0om-make-123-123-123-123-rebind-127-0-0.1-rr-test.1u.ms

और लॉग देखने के लिए - पूंछ-एफ का एनालॉग:
curl http://1u.ms:8080/log
(या ब्राउज़र में एक ही लिंक)

डीएनएस का उपयोग करते हुए पोर्ट स्कैनिंग

वास्तव में, DNS रिकॉर्ड्स को प्रबंधित करते हुए, आप पोर्ट को स्कैन करने का प्रयास कर सकते हैं। थोड़ी सी ट्रिक इसमें हमारी मदद करेगी।

मान लीजिए हमारे पास एक डोमेन my-test-site.com है।

आमतौर पर, इसमें संसाधन को खोलने के लिए कम से कम एक ए रिकॉर्ड होता है।
मान लीजिए कि हमारी साइट का आईपी 172.217.20.46 (google.com से लिया गया) है। लेकिन हम ऐसी कई प्रविष्टियाँ निर्दिष्ट कर सकते हैं! कल्पना कीजिए कि हमने उन्हें बनाया है और हमारे DNS रिकॉर्ड इस तरह दिखते हैं:

my-test-site.com 172.217.20.46
my-test-site.com 192.168.1.1

क्या हमारा संसाधन खोला जाएगा? हाँ, यह होगा। और सभी क्योंकि पहला रिकॉर्ड पहले जाता है।

अब DNS रिकॉर्ड को इस तरह बदलें:

my-test-site.com 192.168.1.1
my-test-site.com 172.217.20.46

क्या हमारा संसाधन खोला जाएगा? फिर से होगा :)

और सभी क्योंकि संसाधन पहले निर्दिष्ट पहले आईपी से बूट करने की कोशिश करेगा, और अगर इसके साथ कोई समस्या है, तो यह दूसरे पर जाएगा।

curl "my-test-site.com" -v
* Trying 192.168.1.1...
* TCP_NODELAY set
* Immediate connect fail for 192.168.1.1: Host is down
* Trying 172.217.20.46...
* TCP_NODELAY set
* Connected to my-test-site.com (172.217.20.46) port 80 (#0)
> GET / HTTP/1.1
> Host: my-test-site.com
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Content-Type: text/html; charset=UTF-8
< Referrer-Policy: no-referrer
< Content-Length: 1561
< Date: Tue, 21 Jan 2020 16:35:08 GMT

इस सुविधा का उपयोग करके, आप यह पता लगा सकते हैं कि कौन से पोर्ट खुले हैं और कौन से नहीं हैं। वास्तव में, कई (लेकिन सभी नहीं) पुस्तकालय पहले संसाधन पर पहले आने की कोशिश करेंगे, जो पहले डीएनएस रिकॉर्ड में सूचीबद्ध है, और फिर दूसरे में।
यहां हमने अवतार को लोड करने में हमारे संसाधन के लिंक का संकेत दिया है।

हमारे डोमेन को निर्दिष्ट करके, पोर्ट को बदलकर, हम यह निर्धारित करने के लिए अपवाद विधि का उपयोग करने का प्रयास करते हैं कि कौन सा पोर्ट उपलब्ध है।

http://my-test-site.com:22 - 172.217.20.46:22
http://my-test-site.com:80 - 172.217.20.46:80
http://my-test-site.com:8080 -
http://my-test-site.com:9200 - 172.217.20.46:9200
http://my-test-site.com:3306 -

चूंकि हमने 192.168.1.1 को पहले रिकॉर्ड के रूप में निर्दिष्ट किया था, इसलिए हम यह निष्कर्ष निकालते हैं कि इस पते ने लाइब्रेरी को 192.168.1.1 (बंदरगाहों 8080 और 3306) पर उत्तर दिया, भले ही यह गलत था, लेकिन इसका जवाब दिया। इसलिए ये बंदरगाह खुले हैं और उन पर सेवाएँ हैं। इस स्थिति में, यह दूसरे पते पर नहीं जाएगा।

यहाँ 1u.ms सेवा भी मदद कर सकती है, इस मामले में हमारे पास निम्नलिखित विन्यास होंगे:

make-%IP%-and-%IP%rr.1u.ms

प्रकार का

make-192.168.1.1-and-172.217.20.46rr.1u.ms

यह दो प्रविष्टियों को लौटाएगा, पिछले पैराग्राफ से अन्य सभी विशेषताएं।

वैसे, इस दृष्टिकोण का उपयोग तेजी से DNS रिबाइंडिंग के लिए किया जा सकता है, जिससे ब्राउज़र को "त्रिशंकु" सर्वर से काम करने के लिए मजबूर किया जा सकता है। मुझे लगता है कि DNS कैश को अपडेट करने के लिए एक मिनट इंतजार करने से ज्यादा तेज होगा। हालांकि, क्रोम के साथ, उदाहरण के लिए, यह चाल काम नहीं करेगी, क्योंकि यह एक यादृच्छिक आईपी लेता है।

एक और पकड़ यह है कि DNS सर्वर जिसके साथ वेब एप्लिकेशन निर्धारित करता है कि डोमेन पते में अंतर्निहित राउंड रॉबिन हो सकता है - रिकॉर्ड के क्रम को बदल सकता है, जिससे सभी सर्वरों पर लोड समान रूप से वितरित होता है। उदाहरण के लिए, 8.8.8.8 ने इस सुविधा से इनकार कर दिया, लेकिन 1.1.1.1 में यह मौजूद है।

रीडायरेक्ट

पुनर्निर्देश की कोशिश करो! खैर, सबसे पहले, पुनर्निर्देशन एक वेब अनुप्रयोग के लिए अनुरोधों की संख्या को कम कर सकता है, उदाहरण के लिए, जब डीएनएस का उपयोग करके पोर्ट को स्कैन किया जाता है। यदि उत्तर आप तक पहुँचता है, तो दूसरे पोर्ट या डोमेन पर पुनर्निर्देशित करें। यदि नहीं, तो शायद वह एक खुले बंदरगाह पर फंस गया।

लेकिन सबसे अच्छी बात, ज़ाहिर है, पुनर्निर्देशन का उपयोग करके प्रोटोकॉल को बदलने की कोशिश करना है। मेरे व्यवहार में, ऐसे मामले थे जब फ़ाइल को रीडायरेक्ट किया गया था: /// etc / passwd ने काम किया और फ़ाइल की सामग्री को दिखाया। अंधे ssrf वाले संस्करण में, आप प्रोटोकॉल को गोफर में बदलने का प्रयास कर सकते हैं (जबकि यह अभी भी मौजूद है), और आप पहले से ही एसएमटीपी और अन्य जादू के लिए कमांड का उपयोग करके पत्र भेज सकते हैं।

सेवा से इनकार

क्या मैं बूटलोडर को बंद कर दूंगा अगर मैं इसे 10 जीबी आकार की इनपुट फ़ाइल दूं? या 225,000 पिक्सेल से 225,000 की छवि, 141.4 जीबी रैम पर कब्जा कर लिया। यह साइट के प्रदर्शन को प्रभावित कर सकता है। सच है, एक दुर्घटनाग्रस्त सर्वर हमें कोई मज़ा नहीं लाएगा, इसलिए बस इसे ध्यान में रखें।

और हर चीज का एक पूरा गुच्छा

यह संभवत: अब मेरा नाम है। यह डाउनलोड से जुड़ी कमजोरियों (जहां इसे लोड किया जाता है, इसे कैसे सहेजा जाता है, जिसे एक ही समय में जांचा जाता है) और 3-पार्टी टुकड़ों ( इमेजेट्रैजिक और गिफोब को याद रखें) को ध्यान में नहीं रखा जा रहा है। यदि आपके पास कोई अन्य विचार है, तो एक टिप्पणी छोड़ दें।

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

https://bo0om.ru/blind-ssrf
जेन

सर्वर अनुरोध जालसाजी, ब्लाइंड SSRF ऑपरेशन