13 KiB
HTTP/2 डाउनग्रेड में अनुरोध अपराध
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
- क्या आप किसी साइबर सुरक्षा कंपनी में काम करते हैं? क्या आप अपनी कंपनी को HackTricks में विज्ञापित देखना चाहते हैं? या क्या आपको PEASS की नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करने का उपयोग करने की आवश्यकता है? सदस्यता योजनाएं की जांच करें!
- The PEASS Family की खोज करें, हमारा विशेष NFT संग्रह
- आधिकारिक PEASS & HackTricks swag प्राप्त करें
- 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या मुझे Twitter 🐦@carlospolopm** का पालन करें**.
- हैकिंग ट्रिक्स को साझा करें और PRs सबमिट करके hacktricks repo और hacktricks-cloud repo के लिए
मूल
इस संकट का मुख्य मूल है कि रिवर्स प्रॉक्सी क्लाइंट के साथ HTTP/2 का उपयोग करके बातचीत करेगा, लेकिन फिर यह बैक-एंड सर्वर के साथ उस संचार को HTTP/1.1 में परिवर्तित करेगा।
इस दृष्टिकोण की समस्या यह है कि उपयोगकर्ता को HTTP/2 संचार में अनावश्यक रूप से हैडर इंजेक्ट करने की अनुमति होगी, जो कि संभवतः प्रॉक्सी द्वारा जांचा नहीं जाएगा। लेकिन फिर, जब वे HTTP/1.1 संचार में अंधाधुंध इंजेक्ट किए जाएंगे, तो एक अनुरोध अपराध हमला किया जा सकता है।
उदाहरण
H2.CL डीसिंक
HTTP/2 निर्देशिका इसका संकेत करती है कि Content-Length हैडर की आवश्यकता नहीं है, लेकिन इसे इंगित किया जा सकता है। इसलिए, रिवर्स प्रॉक्सी सभी सामग्री को अनुरोध के रूप में इंगित करेगी, लेकिन फिर, जब HTTP/1.1 में डाउनग्रेड करते हैं, तो यह हैडर अनुरोध में इंजेक्ट किया जाएगा और इसलिए, बैक-एंड अनुरोध को 2 अलग-अलग अनुरोध के रूप में इंगित किया जाएगा, जैसा कि आप नीचे दी गई छवि में देख सकते हैं:
H2.TE डीसिंक URL टोकन हाइजैक
HTTP/2 निर्देशिका यह भी इंगित करती है कि कनेक्शन-विशिष्ट हैडर फ़ील्ड्स को अवैध माना जाना चाहिए... लेकिन यदि आप इस नियम का पालन नहीं करते हैं, तो आप संकटग्रस्त हो सकते हैं।
इस तकनीक का दुरुपयोग AWS लोड बैलेंसर पर किया गया था, इसलिए सुनिश्चित करना कि उपयोगकर्ता एक अटैकर द्वारा नियंत्रित सर्वर की ओर पहुंच करते हैं, वे उस सर्वर की ओर पहुंचेंगे।
H2.TE डीसिंक हेडर हाइजैक
यह पहले की तकनीक के बिल्कुल समान है, लेकिन जेम्स ने यह देखकर कि क्लाइंट्स उनसे अपने क्रेडेंशियल्स भेजने के लिए कह रहे हैं, उन्होंने अपने सर्वर को CORS को भेजने की अनुमति देने के लिए संशोधित किया:
H2.TE अनुरोध हेडर इंजेक्शन के माध्यम से
**HTTP/2 भी हेडर में अनुमति नहीं देगा अनुमतित वर्ण डालने क
टनलिंग पुष्टि
एक तरीका पुष्टि करने का यदि एंडपॉइंट संकटग्रस्त है लेकिन कनेक्शन एक "टनल" के भीतर है, तो यह है कि दो पूर्ण अनुरोधों को एक में चोरी करें।
HTTP/1.1 के साथ समस्या यह है कि यदि आपको 2 HTTP प्रतिक्रियाएं मिलती हैं, तो आपको पता नहीं चलता है कि एंडपॉइंट संकटग्रस्त था या नहीं और "चोरी की गई" अनुरोध को साधारित अनुरोध के रूप में केवल नहीं लिया गया था।
हालांकि, यह तकनीक HTTP/2 में उपयोग की जा सकती है क्योंकि यदि एंडपॉइंट संकटग्रस्त था और आपने एक अनुरोध चोरी किया था, तो आप उलटी प्रॉक्सी से प्रतिक्रिया के हैडर में चोरी की गई अनुरोध की देखेंगे:
टनल-दृष्टि समस्या
एक और समस्या हो सकती है, यदि वैध अनुरोध के प्रतिक्रिया में Content-Length होता है, तो रिवर्स प्रॉक्सी केवल उसी तक बाइट पढ़ेगा और नहीं, इसलिए आप चोरी की गई अनुरोध प्रतिक्रिया को पढ़ नहीं पाएंगे।
हालांकि, HEAD अनुरोध में शरीर नहीं होता है लेकिन आमतौर पर वह Content-Length को सम्मिलित करता है जैसे कि अनुरोध एक GET अनुरोध था। इसलिए, एक HEAD अनुरोध POST अनुरोध के बजाय भेजकर आप चोरी की गई अनुरोध प्रतिक्रिया के HEAD Content-Length बाइट पढ़ सकते हैं।
टनलिंग के माध्यम से आंतरिक हेडर लीक
यदि आप एक ऐसे अनुप्रयोग में एक POST पैरामीटर खोजते हैं जिसकी सामग्री को प्रतिक्रिया में प्रतिबिंबित किया जाएगा, तो आप HTTP/1.1 \r\n वर्णों को एक HTTP/2 अनुरोध हेडर में इंजेक्ट करने का प्रयास कर सकते हैं ताकि प्रॉक्सी द्वारा नवीनतम इंजेक्ट किए गए हेडर पोस्ट पैरामीटर में जोड़े जाएंगे जो प्रतिक्रिया में प्रतिबिंबित होगा:
ध्यान दें कि इस मामले में हमलावर केवल पहले अनुरोध की प्रतिक्रिया के बारे में चिंता करता है, उसे चोरी की गई अमान्य दूसरे अनुरोध को पढ़ने की आवश्यकता नहीं होती है।
{% hint style="info" %} इस हमले का उपयोग करके वेब के विभिन्न हिस्सों (विधि, पथ...) के खिलाफ विभिन्न बैक-एंड का उपयोग किया जा सकता है और विभिन्न संवेदनशील जानकारी लीक हो सकती है {% endhint %}
टनलिंग के माध्यम से कैश पॉइज़निंग
इस स्थिति में एक HEAD अनुरोध भेजा जाता है URL को जिसका कैश पॉइज़निंग होने जा रहा है, जबकि एक अनुरोध को चोरी किया जाएगा जिसकी प्रतिक्रिया सामग्री में पेलोड (शायद कुछ XSS पेलोड) होगी।
इसके कारण HEAD प्रतिक्रिया में Content-Type: text/html होता है और क्योंकि रिवर्स प्रॉक्सी को लगता है कि चोरी की गई अनुरोध की पूरी प्रतिक्रिया HEAD के शरीर है, इसलिए XSS पेलोड को HTML के रूप में व्यवहारिक किया जाएगा भले ही पृष्ठ XSS के लिए संकटग्रस्त न हो।
छिपी हुई HTTP/2
आमतौर पर सर्वर TLS हैंडशेक में ALPN फ़ील्ड के माध्यम से समर्थन का विज्ञापन करते हैं, लेकिन कुछ नहीं करते हैं।
इसे curl --http2 --http2-prior-knowledge का उपयोग करके आसानी से पता लगाया जा सकता है
उपकरण
- Burp एक्सटेंशन: HTTP Request Smuggler
- https://github.com/neex/http2smugl
संदर्भ
- इस टॉक में सभी तकनीकों की सही व्याख्या की गई है: https://www.youtube.com/watch?v=rHxVVeM9R-M