CVE-2020-0022

Muitos agradecimentos à Insinuator pelo seu incrível 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 em um arquivo README.md, então fique à vontade para conferir o post da Insinuator mencionado acima.

O exploit está totalmente completo até o ponto em que:

1. O endereço de uma área de memória suficientemente grande controlada pelo atacante é vazado
2. O contador de programa é modificado para apontar para um endereço personalizado
3. Novas tentativas são feitas automaticamente até o ponto em que as chances de falha diminuem significativamente
4. O código é otimizado em termos de tempo de desconexão e velocidade de busca na memória até o 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 maneiras:

1. É escrito em C em vez de python (porque eu amo C)
2. É escrito de forma modular, onde cada módulo é responsável por uma tarefa específica
3. Foi testado em um Pixel 3 XL rodando Android 9 (PQ3A.190801.002, Security Patch Level 2019-08-01) porque era o que eu tinha disponível
4. Ele vaza endereços em libandroid_runtime.so em vez de libicuuc.so, porque funcionou melhor neste telefone/alvo
5. Ele tem duas JOP chains 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 arquivo libandroid_runtime.so e extrai os offsets de funções e gadgets (para facilitar a portabilidade do exploit para outros alvos)

Demonstração/Capturas de tela

Este é um vídeo de demonstração mostrando o exploit modificando o PC para apontar para um endereço personalizado:

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

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

Felizmente, o Pixel 3 XL tem proteções que impedem o processo bluetooth de chamar fork e/ou execv. Em termos de compartilhamento de conhecimento ou de exibição, meu trabalho aqui está feito. Se eu escrever e compartilhar algo mais avançado, pode ser útil demais para black-hats.

Conclusão do Exploit

Considero este exploit completo. Melhorias futuras podem ser:

• Escrever uma JOP chain para chamar dlsym e depois mprotect para executar shellcode personalizado
• Coletar e salvar um banco de dados de offsets para diferentes alvos
• Testar os exploits em múltiplos alvos para buscar relativa universalidade
• Combinar o exploit com um exploit de nível de sistema operacional para obter privilégios de root (como meu exploit anterior CVE-2019-2215)
• E mais...

Todas essas coisas transformam este projeto de um projeto divertido de compartilhamento de conhecimento em um exploit black-hat que pode ser transformado em arma, então é aqui que minha jornada termina, por enquanto.... Se você tiver alguma dúvida, sinta-se à vontade para entrar em contato.

Uso

Para executar o exploit, basta executar:

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, o restante dos alvos de build só são úteis se você estiver tentando modificar, melhorar ou reimplementar o exploit, então não há necessidade de mencioná-los em profundidade.

Depuração

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

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

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

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

# On host
adb push ./gdbinit /data/local/tmp/gdbinit

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

Você pode reiniciar o serviço bluetooth na máquina do atacante caso ele pare de funcionar:

sudo systemctl restart bluetooth.service

Notas

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

• O SSP é desligado (ao criar um fd de socket HCI) para evitar um timeout no alvo remoto:

• Estamos fazendo spraying de pacotes limpadores de heap para reduzir a chance de o alvo travar 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 foi bem explicado no post da insinuator. Estamos vazando o endereço de um pacote ao tentar mirar nos chunks malloc de 32 bytes, que incluem um item de lista encadeada 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, então apenas segui o padrão da insinuator e usei outro padrão (que também encontrei por experimentação).

O resultado do experimento do mapa

• O crash e a sobrescrita do PC travam com sucesso o objeto de sinal do chrome

• A JOP chain foi simulada usando o jop_experiment. A JOP chain completa (primeira, apenas com execv) é explicada no JOP_PLAN.md