CVE-2020-0022

Muchas gracias a Insinuator por su increíble publicación y código!

Resultados

Todos los pasos mencionados en la publicación de Insinuator se han completado, y más. Son muchos pasos para incluir en un archivo README.md, así que siéntase libre de consultar la publicación de Insinuator mencionada anteriormente.

El exploit está completamente terminado hasta el punto donde:

1. La dirección del área de memoria suficientemente grande controlada por el atacante se filtra
2. El contador de programa se modifica para apuntar a una dirección personalizada
3. Se realizan reintentos automáticos hasta el punto en que las probabilidades de fallo disminuyen significativamente
4. El código se optimiza en términos de tiempo de desconexión y velocidad de búsqueda en memoria hasta el punto en que una mayor optimización compromete la estabilidad del exploit

Diferencias y Mejoras

Este exploit difiere de la implementación de Insinuator en los siguientes aspectos:

1. Está escrito en C en lugar de Python (porque amo C)
2. Está escrito de forma modular, donde cada módulo es responsable de una tarea específica
3. Fue probado en un Pixel 3 XL con Android 9 (PQ3A.190801.002, Nivel de Parche de Seguridad 2019-08-01) porque era lo que tenía a mano
4. Filtra direcciones en libandroid_runtime.so en lugar de libicuuc.so, porque funcionó mejor en este teléfono/objetivo
5. Tiene dos cadenas JOP de ejemplo implementadas, una que llama a execv directamente y otra que llama a fork y luego execv
6. Está acompañado de un script Ghidra personalizado que procesa el archivo libandroid_runtime.so y extrae los offsets de funciones y gadgets (para facilitar el porteo del exploit a otros objetivos)

Demo/Capturas de pantalla

Este es un video demo que muestra el exploit modificando el PC para apuntar a una dirección personalizada:

La primera iteración de la cadena es la que se puede ver en jop_experiment. Esta cadena llama a execv directamente sin llamar a fork. Se puede encontrar en el commit ca28fdf Esto es lo que ocurre al usar esta cadena:

La segunda iteración de la cadena es la que llama a fork y luego execv. Los detalles completos de esta cadena se pueden encontrar aquí. Esto es lo que ocurre al usar esta cadena:

Afortunadamente, el Pixel 3 XL tiene protecciones que impiden que el proceso de bluetooth llame a fork y/o execv. En términos de compartir conocimiento o lucirse, mi trabajo aquí está hecho. Si escribo y comparto algo más avanzado, podría ser demasiado útil para los black-hats.

Conclusión del Exploit

Considero que este exploit está completo. Las mejoras futuras podrían ser:

• Escribir una cadena JOP para llamar a dlsym y luego mprotect para ejecutar shellcode personalizado
• Recopilar y guardar una base de datos de offsets para diferentes objetivos
• Probar los exploits en múltiples objetivos para apuntar a una universalidad relativa
• Encadenar el exploit con un exploit a nivel de sistema operativo para obtener privilegios de root (como mi exploit anterior CVE-2019-2215)
• Y más...

Todas estas cosas convierten este proyecto de un proyecto divertido de compartir conocimiento a un exploit black-hat que puede ser convertido en arma, así que aquí termina mi viaje, por ahora.... Si tiene alguna pregunta, no dude en contactarme.

Uso

Para ejecutar el exploit, simplemente ejecute:

make build run ARGS="00:00:00:00:00:00" 

Donde 00:00:00:00:00:00 es la dirección MAC del dispositivo objetivo/víctima. Aparte de make clean, el resto de los objetivos de compilación solo son útiles si está intentando modificar, mejorar o reimplementar el exploit, por lo que no es necesario mencionarlos en profundidad.

Depuración

• El binario gdbserver de Android se puede encontrar en la carpeta NDK
• Use esto para depurar el objetivo (no recomendado):

# En el objetivo
/data/local/tmp/gdbserver 0.0.0.0:1234 --attach $(ps -A | grep -i "com.android.bluetooth" | awk '{print $2}')

# En el host
adb forward tcp:1234 tcp:1234
gdb-multiarch -q -x ./gdbinit

• Directamente en el teléfono a través de gdb de termux (recomendado):

# En el host
adb push ./gdbinit /data/local/tmp/gdbinit

# En el objetivo
su
/data/data/com.termux/files/usr/bin/gdb -q -x /data/local/tmp/gdbinit -p $(ps -A | grep -i "com.android.bluetooth" | awk '{print $2}') 
# O
/data/data/com.termux/files/usr/bin/gdb -q -p $(ps -A | grep -i "com.android.bluetooth" | awk '{print $2}') 

Puede reiniciar el servicio bluetooth en la máquina atacante en caso de que deje de funcionar:

sudo systemctl restart bluetooth.service

Notas

Esta sección explica algunos de los fenómenos que se observaron durante el desarrollo de este exploit:

• SSP está desactivado (al crear un fd de socket HCI) para evitar un tiempo de espera en el objetivo remoto:

• Estamos rociando paquetes heap cleaner para reducir la probabilidad de que el objetivo se bloquee debido a un desbordamiento no intencionado que modifica las vtablas del objeto base::MessageLoop utilizado a través de get_message_loop:

• Esto no estaba bien explicado en la publicación de Insinuator. Estamos filtrando la dirección de un paquete intentando apuntar a los chunks malloc de 32 bytes, que incluyen un elemento de lista enlazada por cada elemento en el unordered_map de partial_packets. Esto se averiguó usando el map_experiment El map_experiment no coincide con lo que se filtra en el programa real, así que simplemente seguí el patrón de Insinuator y usé otro patrón (que también encontré por experimentación).

• El bloqueo y la sobrescritura del PC bloquean con éxito el objeto de señal de chrome

• La cadena JOP ha sido simulada usando el jop_experiment. La cadena JOP completa (primera, solo execv) se explica en JOP_PLAN.md