المقالة مقسمة إلى ثلاثة أجزاء. يحتوي الأول على معلومات عامة حول ماهية اختطاف BGP وإصداره التقليدي. بالنسبة لأولئك الذين هم على دراية بهذه الظاهرة ، يوصى بالانتقال مباشرة إلى الجزء الثاني. يصف الجزء الثاني طريقة الإعلان عن البادئات الأجنبية عن طريق إضافة AS أجنبي إلى AS-SET. في الجزء الثالث ، سيتم إجراء تقييم لتعقد استخدام الطريقة الموضحة في الجزء الثاني لالتقاط عنوان IP لمورد torproject.org وإصدار شهادة له. من المفترض أن يكون القارئ معتادًا على مبادئ BGPv4.
BGP اختطاف بسيط
باختصار ، يستحوذ اختطاف BGP على عناوين IP الخاصة بشخص آخر (عشوائية أو مقصودة).
في العادة ، يبدو اختطاف BGP كما يلي: يبدأ AS الذي لا يمتلك بادئة في الإعلان عنه (بادئة شخص آخر) ، وتقبلها الوصلات الصاعدة / النظراء ، وتبدأ في الانتشار عبر الإنترنت. إنهم يقبلون ذلك لسبب عدم وجود تصفية للبادئات عند التقاطع (إما أن يكون هذا خطأ في التكوين ، أو تم تصوره على هذا النحو (نظرًا لأنه من الصعب جدًا إنشاء عامل تصفية بادئة عند التقاطع مع عوامل تشغيل كبيرة جدًا نظرًا لأسباب مختلفة ، هذا ليس مهمًا لهذه المقالة) ) أحد الأمثلة البارزة في الآونة الأخيرة عندما بدأت Rostelecom (
AS12389 )
في الإعلان عن البادئات Mastercard (
AS26380 ) وفيزا وبعض المؤسسات المالية الأخرى (وفقًا
للإصدار الرسمي ، نتيجة لفشل البرنامج). يمكنك أن ترى كيف بدت هذه الإعلانات في سجل bgplay (
المشاهدة عبر الويب ،
json (
أرشيف )) ، إليك أحدها على أحد جامعي RIPE (البادئة 216.119.216.0/24 تنتمي إلى Mastercard (AS26380)):
"source_id": "05-193.203.0.185", "path": [ 6939, 12389 ], "community": [], "target_prefix": 216.119.216.0/24
و هنا ما بدا عليه الإعلان الحقيقي:
"source_id": "05-193.203.0.63", "path": [ 6720, 8447, 32787, 26380, 26380, 26380 ], "community": [ "1120:1" ], "target_prefix": 216.119.216.0/24
أي في هذه الحالة ، أعلنت Rostelecom بادئة مباشرة من AS (AS AS في PATH هي 12389). يمكن تجنب المشكلات إذا قامت الوصلات الصاعدة والأعياد في Rostelecom بتصفية البادئات من Rostelecom عن طريق
إنشاء قوائم بادئات وفقًا لـ AS-SET و / أو
التحقق من صحة البادئات وفقًا لـ ROA RPKI . غالبًا ما لا يتم إنشاء قوائم البادئات بين المشغلين الكبار ، ولم يتم تنفيذ RPKI جميعًا (ولكن هناك
تقدم ). مثل هذا الاختطاف ، من الناحية النظرية ، يمكن القيام به من قبل أي شخص ، ولكن فقط إذا كانت البادئة المعلنة "تتسرب" خلال ما يصل إلى وليمة / وليمة واحدة على الأقل. عادةً ما يقوم المشغلون الروس الكبار بتكوين عوامل تصفية بادئة في اتجاه عملائهم ، وبالتالي فإن AS (شركات صغيرة / متوسطة الحجم ، وبعض الشركات المضيفة وبعض الشركات) ، دائمًا ، لا يمكنها القيام بمثل هذا الهجوم (ولكن مرة أخرى ، كل هذا يتوقف على المنطقة / البلد / مشغل معين).
ومع ذلك ، لا يزال المهاجمون يعثرون على أماكن (الوصلات الصاعدة) حيث لم تتم تهيئة التصفية (في عام 2017 ، كانت البرازيل هي
الرائدة في عمليات الاختطاف ) وتنفيذ هجوم عن طريق الاستيلاء على عناوين IP (غالبًا ، تقع مثل هذه الأحداث في قنوات الأخبار) ، لهجوم أكثر فعالية ، الإعلان عن بادئات أكثر تحديدًا (مع قناع أطول) من المنشئ الحقيقي. الآن دعنا ننتقل إلى إصدار الهجوم ، حيث لا يتم حفظ التحقق من صحة ROA RPKI ولا قوائم بادئة AS-SET.
اختطاف BGP مع إضافة الضحية AS في AS-SET
اطلع على السيناريو التالي:
- يحصل المهاجم على عناوين AS و IP (في الواقع ، من الناحية الفنية ، فهو لا يحتاج إلى عناوين IP ، فمن الأرجح ألا يسبب أسئلة).
- يتصل المهاجم بالعديد من المشغلين الكبار و IXs (مشغل واحد على الأقل أو IX) ، مما يشير ليس فقط إلى AS الخاص به ، ولكن AS-SET كمصدر للبيانات حول البادئات المعلنة (هذه ممارسة عادية للتفاعل بين المشغلين (بما في ذلك بما في ذلك عندما تكون في علاقة بين العميل والوصلة الصاعدة) أو لإدراجها على IX-ah)). في الحالة العادية ، يتم تحديد AS-SET ، وليس فقط AS ، عندما يُفترض أن العميل ليس طريق مسدود ، ولكنه في حد ذاته لديه (أو سيكون لديه) عملاء لديهم bgp وشبكاتهم الخاصة.
- بعد مرور بعض الوقت ، يضيف المهاجم AS الضحية إلى AS-SET ويبدأ في إعلان بادئة له من خلال نفسه ، أي يبدو AS-PATH المعلن بهذا الشكل: "AS_ المهاجم AS_ ضحايا". من وجهة نظر قوائم البادئات التي يتم إنشاؤها تلقائيًا ومن وجهة نظر RPKI ، يعد هذا إعلانًا صالحًا تمامًا ، لذلك لن تعمل كلتا آليتي الحماية هنا.
- تبدأ البادئة المعلن عنها في التنافس مع الإعلان الحقيقي (إعلان الضحية) ، في مكان يفوز فيه ويدخل إلى جدول التوجيه ، في مكان ما يخسره ولن يخسره (سيبقى إعلان الضحية هناك). يعتمد ذلك على عدد الوصلات الصاعدة وعدد IXs التي يستخدمها المهاجم. عندما يتصل أحد المهاجمين ب AS كعميل ، فإنه بداخله (في أغلب الأحيان) سيفوز بالضحية بسبب زيادة محلية موضحة (إذا لم تكن الضحية عميلاً للوصلة الصاعدة نفسها ، فستفوز الضحية ب AS-PATH إذا لم يفعل ذلك مقدما) ، أي يحتاج المهاجم إلى الاتصال بأكبر عدد ممكن من الوصلات الصاعدة مع AS-SET من أجل زيادة فعالية هجومه.
أيضًا ، يجب أن يتصل المهاجم بالعدد الأقصى من IXs ، مثل عادة ، تقوم deads ASs بتعيين أعلى pref المحلي إلى IXs وإذا كانت بادئة الضحية غير متورطة في IX ، فسوف تفقد إعلان المهاجم في جداول التوجيه الخاصة ASS deadlock.
من الناحية النظرية ، هذا هجوم قوي للغاية ، لكن لحسن الحظ ، في الممارسة العملية ، ستنشأ القيود التالية:
- تحتاج إلى إنشاء كيان قانوني ، واحد على الأقل ، ولكن في الواقع ، ستكون هناك حاجة على الأرجح في بلدان مختلفة.
- من الضروري إبرام اتفاقيات مع المشغلين ، IXs ، ودائمًا ما تقوم بعمل رسوم اتصال ، مع LIR / RIR.
- لا يزال بعض المشغلين لا يقومون بإنشاء قوائم بادئة AS-SET تلقائيًا ، فهم بحاجة إلى كتابة رسائل لهذا الغرض. سوف يشك أحد المسئولين ذوي الخبرة في حدوث شيء ما إذا ظهرت AS-ka لشركة معروفة فجأة في AS-SET لشركة غير معروفة.
- بعد الهجوم ، من المرجح أن يتم ضبط المعدات المستخدمة (إذا كانت موجودة في مركز نوع من البيانات) في حالة فتح قضية جنائية.
- يتم تحديث قوائم البادئات للعديد من المشغلين / IX في أوقات مختلفة ، لذلك ستحتاج إلى تحليل من الذي يقوم بالتحديثات عندما لا تكون هذه هي المهمة الأكثر سهولة.
تدابير الحماية الممكنة:
- من الناحية النظرية ، من أجل الدفاع ضد مثل هذا الهجوم ، يجب أن يكون لديك أكبر عدد ممكن من الواجهات مع المشغلين (أفضل ، العميل ، لأن لديهم مقدما محليًا أعلى) و IXs. أي افعل نفس الشيء الذي سيفعله المهاجم. بطبيعة الحال ، في الممارسة العملية من الصعب للغاية تنفيذ وسوف يتطلب موارد كبيرة. هذه الطريقة مناسبة فقط للخدمات التي توفر خدمات أمن المعلومات على أساس احترافي.
- إذا كان لديك موقع ويب ، فاستخدم سجل CAA مع مهمة الحساب (إذا كان موفر شهادة SSL يدعمه. يدعم Letsencrypt) (انظر RFC6844 ). في هذه الحالة ، لن يتمكن المهاجم من إصدار شهادة (إلا إذا كان بإمكانه تغيير سجل الجهاز المركزي للمحاسبات)
- من الناحية النظرية ، يجب على تطبيق BGPsec الواسع القضاء على مثل هذا الهجوم ، لكن مصيره لم يتضح بعد (من الناحية العملية لم يطبق بعد أو نادرًا).
- تطبيق التحقق البديل AS_PATH (بدون BGPsec) (حتى الآن هذا مشروع يحل المشكلة الموضحة في حالة تنفيذه على نطاق واسع).
- حظر الإضافة غير الخاضعة للرقابة لـ AS أجنبي إلى AS-SET (دون إذن من مالك AS) يمكن أن يقلل من إمكانية تنفيذ مثل هذه الهجمات في تلك المناطق التي تستخدم AS-SETs لتصفية المفاصل. الآن لا يوجد مثل هذا الحظر.
في الواقع ، بالنسبة إلى معظم القراء ، فإن النصيحة الوحيدة التي تنطبق عليهم هي الرقم 2 (فيما يتعلق باستخدام الحساب في سجل CAA) ورقم 1 جزئيًا في سياق اختيار مضيف ذي اتصال جيد. في الوقت نفسه ، عليك أن تتذكر الهجمات المحتملة على خدمة DNS التي تستضيف فيها سجلاتك (ولكن هذه مشكلة منفصلة وهناك الكثير من المواد عليها)
هل من الصعب التقاط torproject.org
يحتاج المهاجم إلى حل مشكلتين:
- إعادة توجيه حركة المرور إلى الجمهور المستهدف (الجمهور المستهدف - الذي سيتلقى الموقع المزيف)
- توليد الشهادة
تمهيدي:
$ dig torproject.org CAA +short 128 issuewild "\;" 0 iodef "mailto:torproject-admin@torproject.org" 128 issue "globalsign.com" 128 issue "letsencrypt.org" $ dig torproject.org +short 95.216.163.36 138.201.14.197
كما ترون ، هناك سجل CAA ، يمكنك الحصول على شهادة من letsencrypt ، لا يوجد رابط للحساب في سجل CAA ، مما يعني أن المشكلة قد تم حلها نظريًا من قبل المهاجم. إن عناوين IP الخاصة بـ torproject.org مملوكة لاستضافة هيزنر المعروفة.
لنفترض أن جمهور المهاجم المستهدف هو عملاء بعض المشغلين الروس. هيزنر ليس عميلًا للمشغلين الروس (لكنه يتعامل مع شركات كبيرة - مباشرة أو من خلال IX-s). أسهل طريقة لمهاجم لإعادة توجيه حركة المرور CA لنفسه هو أن تصبح عميلا لهذا المشغل والفوز ببساطة على حساب pref- محلي أعلى. كل شيء هنا بسيط للغاية وواضح.
للحصول على شهادة في letsencrypt ، تحتاج إلى الموفر الذي يستضيف allowencrypt لتوجيه حركة المرور إلى المهاجم ، وليس إلى Hezner (AS24940). يتيححل encencrypt لعناوين مختلفة للملكية الفكرية الأمريكية والأوروبية ، ولكن دعونا نرى مدى صعوبة التأثير على حركة المرور من acme-v02.api.letsencrypt.org/2.19.125.202 انتقل إلى مضيف المهاجم. نحن هنا نواجه حقيقة أن دعارة التشفير تتم استضافتها على Akamai CDN ، الذي يتمتع باتصال جيد للغاية حول العالم (موجود في معظم IXs الرئيسية ، له وصلات مباشرة مع عدد كبير من اللاعبين الرئيسيين). لا يوجد لدى Akamai جهاز LG عام ، من حيث المبدأ ، هناك
واجهة برمجة التطبيقات للعملاء التي يمكنك القيام بها traingoute / ping ، ولكن حتى من دون LG العامة ، يمكنك إلقاء نظرة على
النظراء ديسيبل لتقييم نطاق وجودها. وبالمثل ، يمكنك إلقاء نظرة على
hezner . من السهل أن نرى أن كلا ASS لهما وجود على IXs نفسه ، وبالتالي يمكننا أن نستنتج أنه مع احتمال قريب من الوحدة ، تكون بادئات AS Hezner (AS24940) في جدول Akamai (AS20940) مرئية مع AS_PATH 24940. وهذا يعني أنه إذا كان المهاجم إذا حاولت الإعلان عن بادئات هيزنر من خلال بعض IX ، فسوف تخسر وفقًا ل AS_PATH الإعلانات الحقيقية من هيزنر (بما أن AS_PATH ستحتوي على المهاجم AS). يتمثل الحل المحتمل في تنظيم نظير "مباشر" بين المهاجم و Akamai (إذا وافق Akamai على ذلك وإذا كان pref المحلي أعلى من الوصلات مع IXs).
لتلخيص ، من خلال إضافة شخص آخر باسم AS إلى AS-SET ، يمكنك أن تتسبب في تدهور كبير في موقع torproject.org (بالنسبة لعدد كبير من العملاء ، ولكن ليس للجميع في الحالة العامة) ، ولكن يمكنك الحصول على شهادة torproject.org SSL في allowencryptrypt ، على الأرجح لن ينجح ذلك نظرًا للتواصل الجيد بين المنشئ الحقيقي (هيزنر) و CDN المستخدم من قبل letsencrypt (Akamai). ومع ذلك ، في حالات أخرى ، عندما يكون هناك عبور ASS بين استضافة موقع الضحية وسلطة إصدار الشهادات وكانت موجودة في AS_PATH ، تزداد بشكل كبير خطر الحصول على شهادة باستخدام الطريقة الموضحة.