hasan-khalil/cve-2020-6514Exploit para CVE-2020-6514 visando corrupção de memória SCTP do WebRTC em aplicações Android. Usa Frida para interceptar funções nativas e alterar pacotes SCTP para execução remota de código.
O exploit Ao escrever o exploit, eu originalmente alterava os pacotes SCTP enviados ao dispositivo alvo alterando a fonte do WebRTC e recompilando-o. Isso não era prático para atacar aplicativos de código fechado, então eventualmente mudei para usar Frida para hookar o binário do dispositivo atacante. A funcionalidade de hooking do Frida permite que código seja executado antes e depois que uma função nativa específica é chamada, o que permitiu que meu exploit alterasse pacotes SCTP de saída e inspecionasse os de entrada. Funcionalmente, é equivalente a alterar a fonte do cliente atacante, mas em vez das alterações serem feitas na fonte em tempo de compilação, elas são feitas dinamicamente pelo Frida em tempo de execução. O código fonte do exploit está disponível aqui.
Há sete funções que o dispositivo atacante precisa hookar, conforme abaixo.
usrsctp_conninput // recebe SCTP de entrada DtlsTransport::SendPacket // envia SCTP de saída cricket::SctpTransport::SctpTransport // detecta quando o transporte SCTP está pronto calculate_crc32c // calcula checksum para pacotes SCTP sctp_hmac // realiza HMAC para adivinhar a chave secreta sctp_hmac_m // assina pacote SCTP SrtpTransport::ProtectRtp // suprime RTP para reduzir ruído do heap
Essas funções podem ser hookadas como símbolos, ou como offsets no binário.
Há também três offsets de endereço do binário do dispositivo alvo que são necessários para o exploit funcionar. O offset entre a função system e a função malloc, bem como o offset entre o gadget descrito no post anterior e a função malloc são dois deles. Esses offsets estão na libc, que é uma biblioteca de sistema do Android, portanto precisam ser determinados com base na versão do Android do dispositivo alvo. O offset da localização da vtable de cricket::SctpTransport até a localização de malloc na tabela de offsets globais também é necessário. Isso deve ser determinado a partir do binário que contém o WebRTC no aplicativo atacado.
Note que os scripts de exploit fornecidos têm uma limitação séria: toda vez que a memória é lida, só funciona se o bit 31 do ponteiro estiver definido. As razões para isso são explicadas na Parte 2. O script de exploit tem um exemplo de como corrigir isso e ler qualquer ponteiro usando chunks FWD_TSN, mas isso não está implementado para toda leitura. Para fins de teste, eu reiniciei o dispositivo até que a biblioteca WebRTC fosse mapeada em uma localização favorável.
Uma lista de aplicativos Android populares que integram WebRTC foi determinada pesquisando arquivos APK no Google Play por uma string específica no usrsctp. Aproximadamente 200 aplicativos com mais de cinco milhões de usuários pareciam usar WebRTC. Eu avaliei esses aplicativos para determinar se eles poderiam plausivelmente ser afetados pelas vulnerabilidades no exploit, e qual seria o impacto.
Descobriu-se que as formas como os aplicativos usam WebRTC são bastante variadas, mas podem ser separadas em quatro categorias principais.
Projeção: a tela e os controles de um aplicativo móvel são projetados em um navegador de desktop com consentimento do usuário para maior usabilidade Streaming: conteúdo de áudio e vídeo é enviado de um usuário para muitos usuários. Geralmente há um servidor intermediário, então o remetente não precisa gerenciar possivelmente milhares de pares, e o conteúdo é gravado para visualização posterior Navegadores: todos os principais navegadores contêm WebRTC para implementar a API WebRTC do JavaScript Conferência: dois ou mais usuários se comunicam via áudio ou vídeo em tempo real
O impacto das vulnerabilidades usadas no exploit é diferente para cada uma dessas categorias. A projeção é de baixo risco, pois é necessária muita interação do usuário para configurar a conexão WebRTC, e o usuário tem acesso a ambos os lados da conexão em primeiro lugar, então há pouco a ganhar comprometendo o outro lado.
O streaming também é de risco relativamente baixo. Embora seja possível que alguns aplicativos usem conexões peer-to-peer quando uma transmissão tem baixo número de espectadores, eles geralmente usam um servidor intermediário que encerra a conexão WebRTC do par remetente e inicia novas conexões com os pares receptores. Isso significa que o atacante geralmente não pode enviar pacotes malformados diretamente a um par. Mesmo com uma configuração onde o streaming é feito peer-to-peer, é necessária interação do usuário para que o alvo visualize a transmissão, e muitas vezes não há como limitar quem pode acessar uma transmissão. Por essa razão, aplicativos de streaming que usam WebRTC provavelmente não são úteis para ataques direcionados. Claro, é possível que essas vulnerabilidades afetem os servidores usados por serviços de streaming, mas isso não foi investigado nesta pesquisa.
Os navegadores são quase certamente vulneráveis à maioria dos bugs no WebRTC, porque permitem um grande controle sobre como ele é configurado. Para explorar tal bug em um navegador, um atacante precisaria configurar um host que atue como o outro par na conexão peer-to-peer, e convencer o alvo a visitar uma página web que inicie uma chamada para esse host. Nesse caso, a vulnerabilidade teria um impacto similar a outras vulnerabilidades de corrupção de memória em JavaScript.
A conferência é o uso de maior risco do WebRTC, mas o impacto real de uma vulnerabilidade depende muito de como os usuários de um aplicativo entram em contato uns com os outros. O design de maior risco é um aplicativo onde qualquer usuário pode contatar qualquer outro usuário com base em um identificador. Alguns aplicativos exigem que o destinatário tenha interagido de uma forma específica com o chamador antes que uma chamada possa ser feita, o que torna mais difícil para os usuários contatar um alvo e geralmente reduz o risco. Alguns aplicativos exigem que os usuários insiram um código ou visitem um link para iniciar uma chamada, o que tem efeito semelhante. Há também um grande grupo de aplicativos onde é difícil ou impossível chamar um usuário específico, por exemplo, aplicativos de roleta de chat, e aplicativos que têm recursos que permitem a um usuário iniciar uma chamada para o suporte ao cliente.
Para esta pesquisa, foquei em aplicativos de conferência que permitem que usuários contatem outros usuários específicos. Isso reduziu minha lista de 200 aplicativos para 14 aplicativos, conforme abaixo.
