CVE-2020-0022

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

Resultados

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

El exploit está completamente terminado hasta el punto en que:

1. Se filtra la dirección de un área de memoria suficientemente grande controlada por el atacante
2. El contador de programa se modifica para apuntar a una dirección personalizada
3. Se realizan reintentos automáticos hasta que las posibilidades de fallo disminuyen significativamente
4. El código está optimizado en términos de tiempo de desconexión y velocidad de búsqueda en memoria hasta el punto en que más 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 me encanta 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 esto es 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. Se acompaña de un script Ghidra personalizado que procesa el archivo libandroid_runtime.so y extrae los desplazamientos de funciones y gadgets (para facilitar el traslado 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 a 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 evitan que el proceso de bluetooth llame a fork y/o execv. En términos de compartir conocimiento o presumir, 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 desplazamientos 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 divertido proyecto de intercambio de conocimiento a un exploit black-hat que puede ser armado, así que aquí termina mi viaje, por ahora.... Si tienes alguna pregunta, no dudes en ponerte en contacto.

Uso

Para ejecutar el exploit, simplemente ejecuta:

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ás 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 del NDK
• Úsalo 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 del 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}') 

Puedes 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 posibilidad de que el objetivo falle debido a un desbordamiento no intencionado que modifique las vtablas del objeto base::MessageLoop utilizado a través de get_message_loop:

• Esto no fue bien explicado en la publicación de Insinuator. Estamos filtrando la dirección de un paquete al intentar apuntar a los fragmentos malloc de 32 bytes, que incluyen un elemento de lista enlazada por cada elemento en el unordered_map de partial_packets. Esto se descubrió usando 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é mediante experimentación).

• La sobrescritura del PC y el fallo (crash) del objeto de señal de chrome se logran exitosamente

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