HTTP Response Smuggling / Desync
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
इस पोस्ट की तकनीक वीडियो से ली गई थी: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s
सबसे पहले, यह तकनीक HTTP Request Smuggling भेद्यता का दुरुपयोग करती है, इसलिए आपको यह जानना आवश्यक है कि यह क्या है:
इस तकनीक और सामान्य HTTP Request smuggling के बीच का मुख्य अंतर यह है कि हम पीड़ित के अनुरोध को उसमें एक उपसर्ग जोड़कर हमला करने के बजाय, हम पीड़ित द्वारा प्राप्त प्रतिक्रिया को लीक या संशोधित करने जा रहे हैं। यह इस प्रकार किया जाता है, कि HTTP Request smuggling का दुरुपयोग करने के लिए 1 और आधा अनुरोध भेजने के बजाय, प्रॉक्सी प्रतिक्रियाओं की कतार को असंक्रमित करने के लिए 2 पूर्ण अनुरोध भेजें।
यह इसलिए है क्योंकि हम प्रतिक्रिया कतार को असंक्रमित करने में सक्षम होंगे ताकि पीड़ित के वैध अनुरोध से प्रतिक्रिया हमलावर को भेजी जाए, या पीड़ित की प्रतिक्रिया में हमलावर द्वारा नियंत्रित सामग्री को इंजेक्ट करके।
HTTP/1.1 पिछले अनुरोधों के लिए इंतजार किए बिना विभिन्न संसाधनों के लिए पूछने की अनुमति देता है। इसलिए, यदि बीच में एक प्रॉक्सी है, तो यह प्रॉक्सी का कार्य है कि वह बैकएंड को भेजे गए अनुरोधों और उससे आने वाली प्रतिक्रियाओं का एक समन्वयित मिलान बनाए रखे।
हालांकि, प्रतिक्रियाओं की कतार को असंक्रमित करने में एक समस्या है। यदि एक हमलावर एक HTTP Response smuggling हमला भेजता है और प्रारंभिक अनुरोध और स्मगल्ड एक के लिए प्रतिक्रियाएं तुरंत दी जाती हैं, तो स्मगल्ड प्रतिक्रिया पीड़ित की प्रतिक्रिया की कतार में नहीं डाली जाएगी बल्कि केवल एक त्रुटि के रूप में अस्वीकार कर दी जाएगी।
इसलिए, यह आवश्यक है कि स्मगल्ड अनुरोध प्रसंस्करण में अधिक समय ले। इसलिए, जब तक स्मगल्ड अनुरोध संसाधित होता है, तब तक हमलावर के साथ संचार समाप्त हो जाएगा।
यदि इस विशेष स्थिति में एक पीड़ित ने एक अनुरोध भेजा और स्मगल्ड अनुरोध का उत्तर पहले वैध अनुरोध से दिया गया, तो स्मगल्ड प्रतिक्रिया पीड़ित को भेजी जाएगी। इसलिए, हमलावर पीड़ित द्वारा "प्रदर्शित" अनुरोध को नियंत्रित करेगा।
इसके अलावा, यदि हमलावर फिर एक अनुरोध करता है और पीड़ित के अनुरोध का वैध उत्तर हमलावर के अनुरोध से पहले उत्तर दिया जाता है। पीड़ित के लिए प्रतिक्रिया हमलावर को भेजी जाएगी, पीड़ित की प्रतिक्रिया को चुराते हुए (जिसमें उदाहरण के लिए Set-Cookie हेडर हो सकता है)।
सामान्य HTTP Request Smuggling के साथ एक और दिलचस्प अंतर यह है कि, एक सामान्य स्मगलिंग हमले में, लक्ष्य पीड़ित के अनुरोध की शुरुआत को संशोधित करना है ताकि यह एक अप्रत्याशित क्रिया करे। एक HTTP Response smuggling हमले में, चूंकि आप पूर्ण अनुरोध भेज रहे हैं, आप एक पेलोड में दर्जनों प्रतिक्रियाएं इंजेक्ट कर सकते हैं जो दर्जनों उपयोगकर्ताओं को असंक्रमित कर रही होंगी जो इंजेक्ट की गई प्रतिक्रियाएं प्राप्त कर रहे हैं।
इसके अलावा, वैध उपयोगकर्ताओं के बीच दर्जनों शोषणों को अधिक आसानी से वितरित करने में सक्षम होने के अलावा, इसका उपयोग सर्वर में DoS उत्पन्न करने के लिए भी किया जा सकता है।
जैसा कि पहले समझाया गया है, इस तकनीक का दुरुपयोग करने के लिए, यह आवश्यक है कि सर्वर में पहला स्मगल्ड संदेश प्रसंस्करण में बहुत अधिक समय ले।
यदि हम केवल पीड़ित की प्रतिक्रिया चुराने की कोशिश करना चाहते हैं तो यह समय लेने वाला अनुरोध पर्याप्त है। लेकिन यदि आप एक अधिक जटिल शोषण करना चाहते हैं तो यह शोषण के लिए एक सामान्य संरचना होगी।
सबसे पहले HTTP Request smuggling का दुरुपयोग करते हुए प्रारंभिक अनुरोध, फिर समय लेने वाला अनुरोध और फिर 1 या अधिक पेलोड अनुरोध जिनकी प्रतिक्रियाएं पीड़ितों को भेजी जाएंगी।
HTTP Request Smuggling ज्ञात पेलोड के साथ, आप पीड़ित के अनुरोध को चुरा सकते हैं जिसमें एक महत्वपूर्ण अंतर है: इस मामले में आपको केवल प्रतिक्रिया में परावर्तित सामग्री भेजने की आवश्यकता है, कोई स्थायी भंडारण आवश्यक नहीं है।
सबसे पहले, हमलावर एक पेलोड भेजता है जिसमें परावर्तित पैरामीटर के साथ एक अंतिम POST अनुरोध होता है और एक बड़ा Content-Length होता है।
फिर, एक बार जब प्रारंभिक अनुरोध (नीला) प्रसंस्कृत हो जाता है और जब नींद वाला एक संसाधित हो रहा है (पीला) तो एक पीड़ित से आने वाला अगला अनुरोध परावर्तित पैरामीटर के ठीक बाद कतार में जोड़ा जाएगा:
फिर, पीड़ित नींद वाले अनुरोध का उत्तर प्राप्त करेगा और यदि इस बीच हमलावर ने एक और अनुरोध भेजा, तो परावर्तित सामग्री अनुरोध से प्रतिक्रिया उसे भेजी जाएगी।
अब तक, हमने सीखा है कि HTTP Request Smuggling हमलों का दुरुपयोग कैसे किया जाए ताकि अनुरोध जिसकी प्रतिक्रिया एक क्लाइंट को प्राप्त होने वाली है और आप फिर पीड़ित के लिए निर्धारित प्रतिक्रिया को चुरा सकते हैं।
लेकिन यह अभी भी संभव है कि प्रतिक्रियाओं को और भी अधिक असंक्रमित किया जाए।
कुछ दिलचस्प अनुरोध हैं जैसे HEAD अनुरोध जो निर्दिष्ट करते हैं कि प्रतिक्रिया के शरीर में कोई सामग्री नहीं होनी चाहिए और जो अनुरोध के Content-Length को GET अनुरोध की तरह शामिल करना चाहिए।
इसलिए, यदि एक हमलावर HEAD अनुरोध इंजेक्ट करता है, जैसे कि इन छवियों में:
फिर, जब नीला उत्तर हमलावर को दिया जाता है, अगला पीड़ित का अनुरोध कतार में पेश किया जाएगा:
फिर, पीड़ित HEAD अनुरोध से प्रतिक्रिया प्राप्त करेगा, जो एक Content-Length शामिल करेगा लेकिन कोई सामग्री नहीं होगी। इसलिए, प्रॉक्सी इस प्रतिक्रिया को पीड़ित को नहीं भेजेगा, बल्कि कुछ सामग्री की प्रतीक्षा करेगा, जो वास्तव में पीले अनुरोध की प्रतिक्रिया होगी (जो हमलावर द्वारा भी इंजेक्ट की गई थी):
पिछले उदाहरण का अनुसरण करते हुए, यह जानते हुए कि आप उस अनुरोध के शरीर को नियंत्रित कर सकते हैं जिसकी प्रतिक्रिया पीड़ित को प्राप्त होने वाली है और कि एक HEAD प्रतिक्रिया आमतौर पर अपने हेडर में Content-Type और Content-Length शामिल करती है, आप निम्नलिखित अनुरोध भेज सकते हैं ताकि पीड़ित में XSS उत्पन्न हो बिना कि पृष्ठ XSS के लिए संवेदनशील हो:
पहले टिप्पणी की गई प्रतिक्रिया असंक्रमण सामग्री भ्रम हमले का दुरुपयोग करते हुए, यदि कैश पीड़ित द्वारा किए गए अनुरोध की प्रतिक्रिया को संग्रहीत करता है और यह प्रतिक्रिया एक इंजेक्ट की गई है जो XSS उत्पन्न कर रही है, तो कैश विषाक्त हो जाता है।
XSS पेलोड वाले दुर्भावनापूर्ण अनुरोध:
पीड़ित के लिए दुर्भावनापूर्ण प्रतिक्रिया जो कैश को प्रतिक्रिया संग्रहीत करने के लिए संकेत देती है:
ध्यान दें कि इस मामले में यदि "पीड़ित" हमलावर है तो वह अब मनमाने URL में कैश विषाक्तता कर सकता है क्योंकि वह दुर्भावनापूर्ण प्रतिक्रिया के साथ कैश होने वाले URL को नियंत्रित कर सकता है।
यह हमला पिछले वाले के समान है, लेकिन कैश के अंदर एक पेलोड इंजेक्ट करने के बजाय, हमलावर पीड़ित की जानकारी को कैश के अंदर संग्रहीत करेगा:
इस हमले का लक्ष्य फिर से प्रतिक्रिया असंक्रमण का दुरुपयोग करना है ताकि प्रॉक्सी 100% हमलावर द्वारा उत्पन्न प्रतिक्रिया भेजे।
इस लक्ष्य को प्राप्त करने के लिए, हमलावर को एक वेब एप्लिकेशन के उस एंडपॉइंट को खोजने की आवश्यकता है जो प्रतिक्रिया के अंदर कुछ मानों को परावर्तित कर रहा है और HEAD प्रतिक्रिया की सामग्री की लंबाई को जानता है।
वह एक शोषण भेजेगा जैसे:
पहले अनुरोध के हल होने और हमलावर को वापस भेजे जाने के बाद, पीड़ित का अनुरोध कतार में जोड़ा जाएगा:
पीड़ित को HEAD प्रतिक्रिया + दूसरे अनुरोध की प्रतिक्रिया की सामग्री (परावर्तित डेटा का एक भाग शामिल) के रूप में प्रतिक्रिया प्राप्त होगी:
हालांकि, ध्यान दें कि परावर्तित डेटा का आकार HEAD प्रतिक्रिया की Content-Length के अनुसार था जिसने प्रतिक्रिया कतार में एक वैध HTTP प्रतिक्रिया उत्पन्न की।
इसलिए, दूसरे पीड़ित का अगला अनुरोध कुछ पूरी तरह से हमलावर द्वारा तैयार की गई प्रतिक्रिया प्राप्त करेगा। चूंकि प्रतिक्रिया पूरी तरह से हमलावर द्वारा तैयार की गई है, वह प्रॉक्सी को प्रतिक्रिया को कैश करने के लिए भी बना सकता है।
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
