Análise de várias vulnerabilidades no AirDroid
Relatado por: Simone Margaritelli
Pesquisador de Segurança da Zimperium zLabs
Editar: 11:02 PDT: adicionado código POC exploração abaixo da cronologia de divulgação.
Editar: 06:01 PM PDT: linha de tempo editada para refletir as datas de lançamento 4.0.0 e 4.0.1 e confirmando que ambas as versões ainda são vulneráveis.
Background
AirDroid é uma ferramenta de gerenciamento remoto popular para Android. Tem uma base estimada de mais de 50 milhões de dispositivos de acordo com a Google Play Store.
Nossa pesquisa destaca como os canais de comunicação inseguros tornam milhões de usuários vulneráveis a ataques Man-in-the-Middle (MITM), vazamento de informações e sequestro remoto de atualização do APK, o que leva a uma execução remota de código por parte mal-intencionada. O invasor explora as funcionalidades internas do aplicativo e as usa contra seus usuários.
Produtos Afetados
AirDroid <= 4.0 (versão mais recente)
Https://www.airdroid.com/
Https://play.google.com/store/apps/details?id=com.sand.airdroid
Criptografia DIY e canais de comunicações inseguros
Resumo
AirDroid depende de canais de comunicações inseguros, a fim de enviar os mesmos dados utilizados para autenticar o dispositivo para o seu servidor de estatísticas. Essas solicitações são criptografadas com DES (modo ECB), porém a chave de criptografia é codificada dentro da própria aplicação (assim conhecida por um invasor). Qualquer parte mal-intencionada na mesma rede do dispositivo de destino pode executar um ataque man in the middle para obter credenciais de autenticação e representar o usuário para solicitações adicionais.
Impacto
Uma parte mal-intencionada pode executar um ataque de rede MITM e capturar as informações de autenticação do dispositivo, conforme mostrado na seção “Detalhes” da primeira solicitação HTTP que o aplicativo executa.
Esta solicitação HTTP pode ser descriptografada em tempo de execução usando a chave 890jklms codificada dentro do aplicativo e os campos de autenticação analisados a partir do JSON resultante.
Tendo essas informações, o invasor agora pode personificar o dispositivo da vítima e executar várias solicitações HTTP ou HTTPS em seu nome para os pontos de extremidade AirDroid API.
Por exemplo, uma carga útil como a seguinte (criptografada em DES com a mesma chave exata) pode ser enviada para o nó de extremidade http://id4.airdroid.com/p14//user/getuserinfoviadeviceid.html:
O servidor responderá com as informações do usuário, incluindo seu e-mail e hash de senha:
Este é o log de saída do nosso módulo proxy POC bettercap:
Além disso, um invasor que executa um ataque MITM e redireciona o tráfego HTTP para um proxy mal-intencionado transparente, pode modificar a resposta para a solicitação / phone / vncupgrade que é normalmente usada pelo aplicativo para verificar atualizações de addons:
GET /p14/phone/vncupgrade/?q=[DES ENCRYPTED PAYLOAD]&ver=20151 HTTP/1.1
Host: srv3.airdroid.com
Connection: close
User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)
Injetar uma nova atualização, executando remotamente o código personalizado no dispositivo de destino, é apenas uma questão para modificar essa resposta:
Para algo como o seguinte:
AirDroid irá notificar o usuário de uma atualização disponível, baixar o pacote RCE.apk e, eventualmente, solicitar ao usuário para sua instalação no dispositivo de destino.
Detalhes
A AirDroid confia em endpoints HTTPS API seguros para a maioria de suas funcionalidades, mas durante nossa análise descobrimos que outros canais inseguros são usados para tarefas específicas. Por exemplo, o aplicativo envia estatísticas para http://stat3.airdroid.com como podemos ver na classe com.sand.airdroid.configs.urls.Release:
Ao usar este ponto de extremidade, o aplicativo se baseia em DES criptografados JSON de cargas úteis, a fim de adicionar uma camada mínima de segurança. Você pode ver no objeto com.sand.common.Jsonable que é usado como uma classe base para cada carga JSON sendo enviada para o servidor de stats:
Uma vez que o buildParamQ é executado na carga útil, toda a solicitação HTTP será semelhante a:
GET /phone/open/?q=[HEX ENCODED DES ENCRYPTED PAYLOAD]&ver=20151 HTTP/1.1
Host: stat3.airdroid.com
Connection: close
User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)
Infelizmente, sendo a chave usada para criptografia DES codificada no APK, você pode ver na classe com.sand.common.DesCrypto :
Apesar de seu nome, o método sandDecrypt inverte esses números e hexadecimal decodificando-os, retornando a chave de criptografia final: 890jklms
Uma vez desencriptada, a carga é enviada para o servidor de estatísticas. Essa carga é semelhante a esta:
Os campos account_id, androidid, device_id, imei, imsi, logic_key e unique_id são usados para todas as outras solicitações de API, em HTTP ou HTTPS, para autenticar o dispositivo e identificá-lo de forma exclusiva.
Mitigação
Utilize apenas canais de comunicação seguros (HTTPS)
Verifique a chave pública remota (key pinning) para evitar SSL MITM.
Para criptografia adicional, use mecanismos seguros de troca de chaves como Diffie-Hellman em vez de chaves de criptografia codificadas no aplicativo.
Aproveite e verifique assinaturas digitais para arquivos de atualização.
Use a solução de proteção contra ameaças móveis como ZIPS de Zimperium para prevenir proativamente os ataques de violação de rede e fornecer perícias para entender o impacto potencial para o dispositivo do funcionário.
Desinstale ou desative o AirDroid até que uma correção esteja disponível.
