CVE-2020-0022

Muitos agradecimentos à Insinuator pelo excelente post no blog e código!

Resultados

Todos os passos mencionados no post da Insinuator foram concluídos, e mais. São muitos passos para colocar num ficheiro README.md, por isso fique à vontade para consultar o post da Insinuator mencionado acima.

O exploit está completamente funcional até ao ponto em que:

1. O endereço da área de memória controlada pelo atacante, suficientemente grande, é vazado
2. O contador de programa é modificado para apontar para um endereço personalizado
3. São feitas tentativas automáticas até ao ponto em que as hipóteses de falha diminuem significativamente
4. O código é otimizado em termos de tempo de desconexão e velocidade de pesquisa na memória até ao ponto em que mais otimização compromete a estabilidade do exploit

Diferenças e Melhorias

Este exploit difere da implementação da Insinuator das seguintes formas:

1. Está escrito em C em vez de Python (porque adoro C)
2. Está escrito de forma modular, onde cada módulo é responsável por uma tarefa específica
3. Foi testado num Pixel 3 XL a correr Android 9 (PQ3A.190801.002, Nível de Patch de Segurança 2019-08-01) porque era o que tinha à mão
4. Vaza endereços da libandroid_runtime.so em vez da libicuuc.so, porque funcionou melhor neste telefone/alvo
5. Possui duas cadeias JOP de exemplo implementadas, uma que chama execv diretamente e outra que chama fork e depois execv
6. É acompanhado por um script Ghidra personalizado que processa o ficheiro libandroid_runtime.so e extrai os offsets de funções e gadgets (para facilitar a portabilidade do exploit para outros alvos)

Demo/Capturas de Ecrã

Este é um vídeo de demonstração que mostra o exploit a modificar o PC para apontar para um endereço personalizado:

A primeira iteração da cadeia é a que pode ser vista no jop_experiment. Esta cadeia chama execv diretamente sem chamar fork. Pode ser encontrada no commit ca28fdf. Isto é o que acontece ao usar esta cadeia:

A segunda iteração da cadeia é a que chama fork e depois execv. Detalhes completos desta cadeia podem ser encontrados aqui. Isto é o que acontece ao usar esta cadeia:

Felizmente, o Pixel 3 XL tem proteções que impedem o processo bluetooth de chamar fork e/ou execv. Em termos de partilha de conhecimento ou exibição, o meu trabalho aqui está concluído. Se escrever e partilhar algo mais avançado, pode ser útil demais para hackers de chapéu preto.

Conclusão do Exploit

Considero este exploit completo. Melhorias futuras podem ser:

• Escrever uma cadeia JOP para chamar dlsym e depois mprotect para executar shellcode personalizado
• Recolher e guardar uma base de dados de offsets para diferentes alvos
• Testar os exploits em múltiplos alvos para procurar relativa universalidade
• Encadear o exploit com um exploit a nível de SO para obter privilégios de root (como meu exploit anterior CVE-2019-2215)
• E mais...

Todas estas coisas transformam este projeto de um projeto divertido de partilha de conhecimento para um exploit de chapéu preto que pode ser armadilhado, então é aqui que a minha jornada termina, por agora.... Se tiver alguma dúvida, sinta-se à vontade para entrar em contacto.

Uso

Para executar o exploit, basta correr:

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

Onde 00:00:00:00:00:00 é o endereço MAC do dispositivo alvo/vítima. Além de make clean, os restantes alvos de compilação só são úteis se estiver a tentar modificar, melhorar ou reimplementar o exploit, por isso não há necessidade de os mencionar em detalhe.

Depuração

• O binário gdbserver do Android pode ser encontrado na pasta NDK
• Use isto para depurar o alvo (não recomendado):

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

# No anfitrião
adb forward tcp:1234 tcp:1234
gdb-multiarch -q -x ./gdbinit

• Diretamente no telefone através do gdb do termux (recomendado):

# No anfitrião
adb push ./gdbinit /data/local/tmp/gdbinit

# No alvo
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}') 
# OU
/data/data/com.termux/files/usr/bin/gdb -q -p $(ps -A | grep -i "com.android.bluetooth" | awk '{print $2}') 

Pode reiniciar o serviço bluetooth na máquina atacante caso ele pare de funcionar:

sudo systemctl restart bluetooth.service

Notas

Esta secção explica alguns dos fenómenos que foram observados durante o desenvolvimento deste exploit:

• SSP está desligado (ao criar um socket HCI fd) para evitar um timeout no alvo remoto:

• Estamos a enviar pacotes de limpeza de heap para reduzir a probabilidade de o alvo crashar devido a um overflow não intencional que modifica as vtables do objeto base::MessageLoop usado através de get_message_loop:

• Isto não estava bem explicado no post da Insinuator. Estamos a vazar o endereço de um pacote ao tentar atingir os chunks malloc de 32 bytes, que incluem um item de lista ligada para cada item no unordered_map de partial_packets. Isto foi descoberto usando o map_experiment O map_experiment não corresponde ao que é vazado no programa real, por isso simplesmente segui o padrão da Insinuator e usei outro padrão (que também descobri por experimentação).

• O crash e a substituição do PC crasham com sucesso o objeto de sinal do chrome

• A cadeia JOP foi simulada usando o jop_experiment. A cadeia JOP completa (primeira, apenas execv) está explicada no JOP_PLAN.md