HTTP Response Smuggling / Desync

Reading time: 8 minutes

इस पोस्ट की तकनीक वीडियो से ली गई थी: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s

HTTP Request Queue Desynchronisation

सबसे पहले, यह तकनीक HTTP Request Smuggling vulnerability का दुरुपयोग करती है, इसलिए आपको यह जानना आवश्यक है कि यह क्या है:

इस तकनीक और सामान्य HTTP Request smuggling के बीच का मुख्य अंतर यह है कि हम पीड़ित के request में prefix जोड़ने के बजाय, हम पीड़ित द्वारा प्राप्त प्रतिक्रिया को लीक या संशोधित करने जा रहे हैं। यह इस प्रकार किया जाता है कि, HTTP Request smuggling का दुरुपयोग करने के लिए 1 और आधा request भेजने के बजाय, प्रॉक्सी प्रतिक्रियाओं की कतार को असंक्रमित करने के लिए 2 पूर्ण requests भेजें।

यह इसलिए है क्योंकि हम प्रतिक्रिया कतार को असंक्रमित करने में सक्षम होंगे ताकि पीड़ित के वैध request की प्रतिक्रिया हमलावर को भेजी जाए, या हमलावर द्वारा नियंत्रित सामग्री को पीड़ित की प्रतिक्रिया में इंजेक्ट करके।

HTTP Pipeline Desync

HTTP/1.1 पिछले संसाधनों के लिए इंतजार किए बिना विभिन्न संसाधनों के लिए पूछने की अनुमति देता है। इसलिए, यदि बीच में एक प्रॉक्सी है, तो यह प्रॉक्सी का कार्य है कि वह बैकएंड को भेजे गए requests और उससे आने वाली प्रतिक्रियाओं का एक समन्वयित मिलान बनाए रखे।

हालांकि, प्रतिक्रियाओं की कतार को असंक्रमित करने में एक समस्या है। यदि एक हमलावर एक HTTP Response smuggling हमला भेजता है और प्रारंभिक request और स्मगल्ड request के लिए प्रतिक्रियाएं तुरंत दी जाती हैं, तो स्मगल्ड प्रतिक्रिया पीड़ित की प्रतिक्रिया की कतार में नहीं डाली जाएगी बल्कि केवल एक त्रुटि के रूप में अस्वीकार कर दी जाएगी।

इसलिए, यह आवश्यक है कि स्मगल्ड request प्रोसेस होने में अधिक समय ले। इसलिए, जब तक स्मगल्ड request प्रोसेस होती है, तब तक हमलावर के साथ संचार समाप्त हो जाएगा।

यदि इस विशेष स्थिति में एक पीड़ित ने एक request भेजी और स्मगल्ड request को वैध request से पहले उत्तर दिया गया, तो स्मगल्ड प्रतिक्रिया पीड़ित को भेजी जाएगी। इसलिए, हमलावर पीड़ित द्वारा "प्रदर्शित" request को नियंत्रित करेगा।

इसके अलावा, यदि हमलावर फिर एक request करता है और पीड़ित की request का वैध उत्तर हमलावर की request से पहले उत्तर दिया जाता है। पीड़ित के लिए प्रतिक्रिया हमलावर को भेजी जाएगी, पीड़ित की प्रतिक्रिया को चुराते हुए (जिसमें उदाहरण के लिए Set-Cookie हेडर हो सकता है)।

Multiple Nested Injections

सामान्य HTTP Request Smuggling के साथ एक और दिलचस्प अंतर यह है कि, एक सामान्य स्मगलिंग हमले में, लक्ष्य पीड़ित के request के प्रारंभ को संशोधित करना है ताकि यह एक अप्रत्याशित क्रिया करे। एक HTTP Response smuggling हमले में, चूंकि आप पूर्ण requests भेज रहे हैं, आप एक payload में दर्जनों प्रतिक्रियाएं इंजेक्ट कर सकते हैं जो दर्जनों उपयोगकर्ताओं को असंक्रमित कर देंगी जो इंजेक्ट की गई प्रतिक्रियाएं प्राप्त कर रहे हैं।

वैध उपयोगकर्ताओं के बीच दर्जनों exploits को अधिक आसानी से वितरित करने के अलावा, इसका उपयोग सर्वर में DoS उत्पन्न करने के लिए भी किया जा सकता है।

Exploit Organisation

जैसा कि पहले समझाया गया है, इस तकनीक का दुरुपयोग करने के लिए, यह आवश्यक है कि सर्वर में पहला स्मगल्ड संदेश प्रोसेस होने में बहुत समय ले।

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

सबसे पहले HTTP Request smuggling का दुरुपयोग करते हुए प्रारंभिक request, फिर समय लेने वाला request और फिर 1 या अधिक payload requests जिनकी प्रतिक्रियाएं पीड़ितों को भेजी जाएंगी।

Abusing HTTP Response Queue Desynchronisation

Capturing other users' requests

HTTP Request Smuggling के ज्ञात payloads के साथ, आप पीड़ित के request को चुरा सकते हैं जिसमें एक महत्वपूर्ण अंतर है: इस मामले में आपको केवल प्रतिक्रिया में परावर्तित सामग्री भेजने की आवश्यकता है, कोई स्थायी भंडारण आवश्यक नहीं है।

पहले, हमलावर एक payload भेजता है जिसमें परावर्तित पैरामीटर के साथ एक अंतिम POST request और एक बड़ा Content-Length होता है।

फिर, एक बार जब प्रारंभिक request (नीला) को प्रोसेस किया गया और जब नींद वाली request को प्रोसेस किया जा रहा है (पीला) तो एक पीड़ित से आने वाली अगली request को परावर्तित पैरामीटर के ठीक बाद कतार में जोड़ा जाएगा:

फिर, पीड़ित को नींद वाली request की प्रतिक्रिया प्राप्त होगी और यदि इस बीच हमलावर ने एक और request भेजी, तो परावर्तित सामग्री request से प्रतिक्रिया उसे भेजी जाएगी।

Response Desynchronisation

अब तक, हमने सीखा है कि HTTP Request Smuggling हमलों का दुरुपयोग कैसे किया जाए ताकि क्लाइंट को प्राप्त होने वाली प्रतिक्रिया को नियंत्रित किया जा सके और आप फिर पीड़ित के लिए निर्धारित प्रतिक्रिया को चुरा सकते हैं।

लेकिन अभी भी प्रतिक्रियाओं को और अधिक असंक्रमित करना संभव है।

कुछ दिलचस्प requests हैं जैसे HEAD request जो निर्दिष्ट करते हैं कि प्रतिक्रिया के शरीर में कोई सामग्री नहीं होनी चाहिए और जो Content-Length को GET request की तरह शामिल करना चाहिए।

इसलिए, यदि एक हमलावर HEAD request इंजेक्ट करता है, जैसे कि इन छवियों में:

फिर, जब नीला उत्तर हमलावर को दिया जाता है, अगली पीड़ित की request कतार में पेश की जाएगी:

फिर, पीड़ित को HEAD request से प्रतिक्रिया प्राप्त होगी, जो एक Content-Length शामिल करेगी लेकिन कोई सामग्री नहीं होगी। इसलिए, प्रॉक्सी इस प्रतिक्रिया को पीड़ित को नहीं भेजेगी, बल्कि कुछ सामग्री की प्रतीक्षा करेगी, जो वास्तव में पीले request की प्रतिक्रिया होगी (जो हमलावर द्वारा भी इंजेक्ट की गई थी):

Content Confusion

पिछले उदाहरण का पालन करते हुए, यह जानते हुए कि आप पीड़ित को प्राप्त होने वाली प्रतिक्रिया के लिए request के शरीर को नियंत्रित कर सकते हैं और कि एक HEAD प्रतिक्रिया आमतौर पर इसके हेडर में Content-Type और Content-Length शामिल करती है, आप निम्नलिखित request भेज सकते हैं पीड़ित में XSS उत्पन्न करने के लिए बिना पृष्ठ के XSS के प्रति संवेदनशील होने के:

Cache Poisoning

पहले टिप्पणी की गई प्रतिक्रिया असंक्रमण सामग्री भ्रम हमले का दुरुपयोग करते हुए, यदि कैश पीड़ित द्वारा किए गए request की प्रतिक्रिया को संग्रहीत करता है और यह प्रतिक्रिया एक इंजेक्ट की गई है जो XSS उत्पन्न करती है, तो कैश विषाक्त हो जाता है।

XSS payload वाली दुर्भावनापूर्ण request:

पीड़ित के लिए दुर्भावनापूर्ण प्रतिक्रिया जो कैश को प्रतिक्रिया संग्रहीत करने के लिए संकेत देती है:

Web Cache Deception

यह हमला पिछले वाले के समान है, लेकिन कैश के अंदर एक payload इंजेक्ट करने के बजाय, हमलावर पीड़ित की जानकारी को कैश के अंदर संग्रहीत करेगा:

Response Splitting

इस हमले का लक्ष्य फिर से प्रतिक्रिया असंक्रमण का दुरुपयोग करना है ताकि प्रॉक्सी 100% हमलावर द्वारा उत्पन्न प्रतिक्रिया भेजे।

इस लक्ष्य को प्राप्त करने के लिए, हमलावर को एक वेब एप्लिकेशन के एक एंडपॉइंट को खोजने की आवश्यकता है जो प्रतिक्रिया के अंदर कुछ मानों को परावर्तित कर रहा है और HEAD प्रतिक्रिया की सामग्री की लंबाई को जानता है।

वह एक exploit भेजेगा जैसे:

पहली request के हल होने और हमलावर को वापस भेजे जाने के बाद, पीड़ित की request कतार में जोड़ी जाती है:

पीड़ित को प्रतिक्रिया के रूप में HEAD प्रतिक्रिया + दूसरी request की प्रतिक्रिया (जिसमें परावर्तित डेटा का एक भाग शामिल है) प्राप्त होगी:

हालांकि, ध्यान दें कि परावर्तित डेटा का आकार HEAD प्रतिक्रिया की Content-Length के अनुसार था जिसने प्रतिक्रिया कतार में एक वैध HTTP प्रतिक्रिया उत्पन्न की।

इसलिए, दूसरे पीड़ित की अगली request को प्रतिक्रिया के रूप में कुछ पूरी तरह से हमलावर द्वारा तैयार किया गया प्राप्त होगा। चूंकि प्रतिक्रिया पूरी तरह से हमलावर द्वारा तैयार की गई है, वह प्रॉक्सी को प्रतिक्रिया को कैश करने के लिए भी बना सकता है।