francozappa/blurBLURtooth: استغلال اشتقاق المفاتيح عبر النقل في بلوتوث الكلاسيكي وبلوتوث منخفض الطاقة [CVE-2020-15802] [CVE-2022-20361]
مستودع حول هجمات BLUR المقدَّمة في مؤتمر AsiaCCS'22 في ورقة بحثية بعنوان: BLURtooth: Exploiting Cross-Transport Key Derivation in Bluetooth Classic and Bluetooth Low Energy.
روابط مفيدة: pdf، فيديو، الشرائح، الموقع.
إدخال BibTeX:
@inproceedings{antonioli22blur,
author={Antonioli, Daniele and Tippenhauer, Nils Ole and Rasmussen, Kasper
and Payer, Mathias},
title={{BLURtooth: Exploiting Cross-Transport Key Derivation in
Bluetooth Classic and Bluetooth Low Energy}},
booktitle={Proceedings of the Asia conference on computer and
communications security (ASIACCS)},
month={May},
year={2022}
}
تم تخصيص هجمات BLUR إلى CVE-2020-15802 و CVE-2022-20361.
في بقية ملف README نشير إلى Bluetooth Classic (المعروف أيضًا باسم BR/EDR) باسم BT وإلى Bluetooth Low Energy باسم BLE، وإلى Cross-Transport Key Derivation باسم CTKD. كما نفترض أن جهاز الهجوم والأجهزة الضحية تدعم BT وBLE وCTKD. وهذا يعني أن الأجهزة تدعم Bluetooth 4.2+ والاتصالات الآمنة BT/BLE.
أسهل طريقة لتنفيذ الهجمات هي استخدام جهاز واحد كضحية وجهاز هجوم في الوقت نفسه. على سبيل المثال، نوصي باستخدام حاسوب محمول يعمل بنظام Linux كجهاز ضحية/هجوم وأي جهاز آخر كالضحية الأخرى.
نستخدم جهازًا يعمل بنظام Linux ويشغّل bluez
وأدوات bluez tools. نعتمد على أداة btmgmt،
وقد يكون من المفيد الاطلاع على الكود المصدري الخاص بها.
وبشكل خاص، نستخدم الأمر الفرعي pair الذي يتيح، من بين أمور أخرى، إرسال
طلبات إقران عشوائية عبر BT/BLE مع الإعلان عن قدرات إدخال/إخراج عشوائية.
Usage: pair [-c cap] [-t type] <remote address>
إذا كنت تريد إعادة إنتاج سيناريو الهجوم الدقيق المقدَّم في ورقتنا البحثية، فستحتاج إلى عمل إضافي. وتحديدًا، تحتاج إلى إعادة إنتاج الإعداد المقدَّم في BIAS attack. وبمجرد أن يصبح الإعداد جاهزًا، يجب أن تكون قادرًا على استخدام لوحة التطوير كوحدة تحكم BT/BLE لديك، والحاسوب المحمول بنظام Linux كمضيف. علاوةً على ذلك، يجب أن تكون قادرًا على التقاط حزم طبقة الارتباط من المضيف (مثل حركة مرور BT LMP) وتصحيح البرنامج الثابت للوحة التطوير ديناميكيًا في وقت التشغيل باستخدام internalblue.
هذه الخطوة اختيارية وتتطلب تصحيح نواة Linux الخاصة بك.
عند استخدام btmgmt -c 3، يقوم bluez تلقائيًا بإلغاء تعيين علامة حماية MitM،
على سبيل المثال، يضبط بايت AuthReq إلى 0x02 بدلاً من 0x03.
ومع ذلك، لا تتطلب هجمات BLUR إلغاء تعيين هذه العلامة، بل تتطلب فقط
الإعلان عن قدرات NoInputNoOutput عندما يدعم الجهاز البعيد
قدرات الإدخال/الإخراج. وبهذه الحيلة، يتم تخفيض إجراء الإقران
إلى Just Works دون إلغاء تعيين علامة MitM.
يتطلب تنفيذ هذا الإعداد تعديلًا بسيطًا في نواة Linux. وتحديدًا،
في /net/bluetooth/hci_event.c نغيّر:
cp.authentication = conn->auth_type;
إلى:
cp.authentication = 0x03;
ومن خلال ذلك، نثبّت علامة AuthReq الخاصة بنا إلى 0x03 بغض النظر عن
قدرات الإدخال/الإخراج التي نعلنها.
قم بإقران الأجهزة الضحية كالمعتاد. على سبيل المثال، إذا كنت تستهدف هاتفًا ذكيًا، فقم بإقرانه مع حاسوبك المحمول (الذي يعمل كضحية وجهاز هجوم في الوقت نفسه). قد يتطلب الإقران بعض التفاعل من المستخدم (مثل المقارنة الرقمية).
REMOTE-BTADDhciconfig وسجّل فهرس hci لديك، على سبيل المثال 0sudo btmgmt -i 0[hci0] #هنا أفترض أن الضحية تستخدم عنوان BLE عامًا. إذا كانت تستخدم عنوانًا عشوائيًا،
فغيّر خيار -t إلى 2
من واجهة btmgmt، شغّل:
pair -t 1 REMOTE-BTADD
إذا كنت تحتاج أيضًا إلى تخفيض الارتباط إلى Just Works، فشغّل:
pair -c 3 -t 1 REMOTE-BTADD
يضبط خيار -c قدرات الإدخال/الإخراج للمهاجم، وتُشير القيمة 0x3 إلى NoInputNoOutput،
بينما القيمة الافتراضية لحاسوب محمول/هاتف ذكي هي 0x1 والتي تقابل Display Yes/No.
في هذه الحالة، حتى وإن كنا ننتحل صفة طرفي BLE، فإننا نقوم بالإقران عبر BT بوصفنا الجهاز المركزي.
من واجهة btmgmt، شغّل:
pair -t 0 REMOTE-BTADD
إذا كنت تحتاج أيضًا إلى تخفيض الارتباط إلى Just Works، فشغّل:
pair -c 3 -t 0 REMOTE-BTADD
كرر الهجمات الموضحة أعلاه أثناء انتحال صفة جهاز غير معروف حاليًا للضحية (أي غير مقترن بها).
من واجهة bluetoothctl يمكنك ضبط discoverable إلى on أو off وpairable. ومن واجهة btmgmt يمكنك أيضًا ضبط علامة connectable.
من bluetoothctl، يمكنك التحكم في مهلة قابلية الاكتشاف باستخدام discoverable-timeout،
على سبيل المثال، إذا ضبطتها على 0، فسيظل الجهاز قابلاً للاكتشاف دائمًا.
بالنسبة إلى BT، أثناء الإقران مع جهاز بعيد سواء بوصفك جهازًا مركزيًا أو طرفيًا، ستستقبل حزمة LMP التالية: LMP not accepted ext (رمز التشغيل: 0x02) مع عدم السماح بالإقران (رمز الخطأ: 0x18).
بالنسبة إلى BLE، أثناء الإقران مع جهاز بعيد سواء بوصفك جهازًا مركزيًا أو طرفيًا، ستستقبل حزمة SMP التالية: SMP Pairing Failed Command (رمز التشغيل 0x05) مع Pairing Not Supported (السبب 0x05).
بالنسبة إلى BT، أثناء الإقران مع جهاز بعيد، ابحث عن دعم الاتصالات الآمنة للمضيف ووحدة التحكم في حزم ميزات LMP، على سبيل المثال باستخدام عامل تصفية العرض التالي في Wireshark: btbrlmp.efeat.scc or btbrlmp.efeat.sch.
بالنسبة إلى BLE، أثناء الإقران مع جهاز بعيد في رسالة SMP Pairing Request أو Response، تحقق من بايت AuthReq الذي يحتوي على علامة الاتصال الآمن، على سبيل المثال باستخدام عامل تصفية العرض التالي في Wireshark: btsmp.sc_flag == 1.
بالنسبة إلى BT، أثناء الإقران مع جهاز بعيد، يتم نقل حركة مرور SMP الخاصة بـ BLE عبر نفق L2CAP. لذلك باستخدام عامل تصفية Wireshark btl2cap.payload، يجب أن ترى حزمة واحدة من الجهاز المركزي إلى الجهاز الطرفي تحتوي على حمولة تبدأ بـ 0x01 (SMP Pairing Request) وحزمة أخرى في الاتجاه المعاكس بحمولة تبدأ بـ 0x02 (SMP Pairing Response). بعد ذلك، يجب أن ترى أيضًا حزم L2CAP خام أخرى ترمز إلى مرحلة توزيع مفاتيح SMP.
بالنسبة إلى BLE، أثناء الإقران مع جهاز بعيد في رسالة SMP Pairing Request أو Response، تحقق من أن كلاً من الجهاز المركزي والجهاز الطرفي مستعدان لإرسال واستقبال مفتاح ارتباط أثناء توزيع مفاتيح SMP، على سبيل المثال استخدم عامل تصفية Wireshark التالي btsmp.key_dist_linkkey or btsmp.key_dist_linkkey.