Aplicativo de segurança pré-instalado aceitava tráfego HTTP interceptável e combinava atualizações de SDKs no mesmo sandbox, permitindo sobrescrever componentes carregados pelo mecanismo antivírus.
| Componente | Aplicativo Xiaomi Guard Provider, identificado como com.miui.guardprovider, com SDKs antivírus Avast, AVL e Tencent integrados no mesmo contexto de aplicação. |
| Vetor | Atacante na mesma rede Wi-Fi podia interceptar tráfego HTTP usado por atualizações de SDK, alterar respostas de configuração e explorar extração de arquivo ZIP com path traversal no fluxo do AVL. |
| Impacto | A cadeia permitia substituir um APK de atualização do Avast dentro do sandbox do Guard Provider e fazer o SDK carregar código não autorizado quando o mecanismo Avast fosse selecionado novamente. |
| Prioridade | Aplicar a correção disponibilizada pela Xiaomi e revisar tráfego de atualização inseguro, alternâncias de mecanismo antivírus e artefatos inesperados no diretório privado do aplicativo. |
| Artefatos | O fluxo envolvia o APK avast-android-vps-v4-release.apk, arquivos vps_update_*.apk, configuração 20180704.cj.conf e gravação em /data/data/com.miui.guardprovider/app_dex/. |
| Mitigação | A atualização do fabricante corrige o problema; controles defensivos adicionais devem bloquear interceptação em Wi-Fi não confiável e validar integridade de componentes baixados por SDKs. |
A vulnerabilidade atingia o Guard Provider, aplicativo de segurança pré-instalado em telefones Xiaomi convencionais e associado ao pacote com.miui.guardprovider. O aplicativo foi projetado para oferecer recursos de proteção do dispositivo, limpeza, otimização e varredura antivírus, mas sua arquitetura combinava múltiplos SDKs de terceiros no mesmo contexto da aplicação. Essa decisão ampliou o impacto de falhas individuais: componentes que deveriam operar como motores independentes compartilhavam permissões, diretórios privados e confiança implícita no armazenamento interno do aplicativo.
A cadeia explorável dependia de uma condição de rede específica, mas comum em ambientes públicos ou corporativos: o agressor precisava estar na mesma rede Wi-Fi da vítima para interceptar comunicações não protegidas do aplicativo. Como parte do tráfego de atualização era feito por HTTP, um ataque de intermediário podia observar requisições, bloquear respostas legítimas, alterar arquivos de configuração e induzir o aplicativo a processar artefatos controlados. O resultado técnico descrito era execução de código remoto dentro do contexto do Guard Provider, acionada por abuso combinado dos fluxos de atualização dos SDKs Avast e AVL.
O caso é relevante para engenharia de produto e segurança móvel porque não se limita a um erro isolado de transporte inseguro. A exploração combinava ausência de proteção criptográfica no canal, falta de verificação suficiente de integridade antes do carregamento de um APK de atualização, path traversal durante a descompactação de assinaturas e compartilhamento de sandbox entre SDKs. Em conjunto, esses fatores permitiam que um arquivo associado a um mecanismo antivírus fosse sobrescrito por outro componente e posteriormente carregado como se fosse uma atualização confiável.
A Xiaomi disponibilizou uma correção após divulgação responsável. Para equipes defensivas, o ponto central é tratar aplicativos pré-instalados com o mesmo rigor aplicado a componentes corporativos críticos: eles possuem permissões relevantes, rodam em dispositivos de usuários finais e podem operar como ponto de execução privilegiado dentro do ecossistema móvel. A confiança do usuário no aplicativo de segurança não reduz a necessidade de validação de transporte, isolamento entre bibliotecas e verificação de assinatura antes de qualquer carregamento dinâmico.
O Guard Provider oferecia ao usuário a escolha entre três motores antivírus embutidos: Avast, AVL e Tencent. Com o Avast configurado como mecanismo padrão, o aplicativo buscava periodicamente uma atualização de base de vírus na forma do arquivo avast-android-vps-v4-release.apk. Esse APK era salvo no diretório privado do Guard Provider, com nome derivado de um padrão de atualização contendo data e horário, como vps_update_20190205-124933.apk. Antes da varredura do dispositivo, o SDK do Avast carregava e executava esse artefato.
A primeira etapa da cadeia explorava o fato de que o download do APK do Avast ocorria por conexão HTTP. Um agressor em posição de intermediário na mesma rede podia identificar o momento da atualização e inferir o nome do próximo arquivo gravado em disco. Em seguida, podia interferir nas comunicações subsequentes do Avast, respondendo com erro às consultas de informação de atualização. Essa interferência não exigia publicação de um exploit local no dispositivo; o ponto de controle era o tráfego em trânsito, antes que o aplicativo processasse os dados como atualização legítima.
Com o fluxo do Avast bloqueado, o usuário poderia alternar para o motor AVL, também embutido no Guard Provider. Ao se tornar o mecanismo ativo, o SDK do AVL consultava um arquivo de configuração em texto claro, como 20180704.cj.conf, que informava URL, tamanho e hash MD5 do arquivo ZIP de assinaturas a ser baixado. Como essa configuração também era recebida por canal não seguro, o intermediário podia modificar seus campos e apontar o processo de atualização para um arquivo ZIP preparado pelo próprio agressor.
A segunda etapa dependia de uma falha de path traversal na descompactação do arquivo de assinaturas do AVL. Ao processar entradas de arquivo com caminhos manipulados, o SDK podia gravar fora do diretório pretendido e alcançar outros arquivos dentro do sandbox compartilhado do Guard Provider. Isso permitia sobrescrever o APK de atualização do Avast previamente observado, por exemplo usando uma entrada que resolvesse para o diretório app_dex onde o arquivo vps_update_*.apk estava armazenado. A relevância técnica está no cruzamento entre dois SDKs: o problema de extração do AVL impactava diretamente o artefato carregado pelo Avast.
Depois que o APK do Avast era substituído, o agressor precisava liberar a comunicação do Avast e impedir a do AVL até que o usuário selecionasse novamente o mecanismo Avast. Nesse momento, o SDK carregaria o arquivo presente no diretório esperado. A cadeia funcionava porque o arquivo de atualização anterior não era verificado novamente antes do carregamento; o Guard Provider tratava o artefato como já validado no momento original em que foi baixado. Assim, a substituição feita por outro caminho dentro do mesmo sandbox contornava a expectativa de integridade do fluxo do Avast.
O impacto descrito incluía desativação de proteções antimalware e injeção de código não autorizado. Como o código passaria a executar no contexto do aplicativo de segurança, um agressor poderia condicionar ações posteriores às permissões e capacidades disponíveis ao Guard Provider. O texto técnico associado ao caso menciona possibilidades como roubo de dados, implantação de ransomware, rastreamento ou instalação de outro malware, mas essas consequências dependem do código carregado e do ambiente do dispositivo. O fato confirmado pela cadeia é a capacidade de substituir e executar um componente dentro do aplicativo vulnerável.
A superfície principal era composta por telefones Xiaomi que traziam o Guard Provider pré-instalado. O aplicativo fazia parte da experiência padrão de proteção do dispositivo e, por isso, podia estar presente mesmo em aparelhos nos quais o usuário não instalou software de segurança adicional. Essa característica aumenta o alcance operacional da falha: o componente vulnerável não dependia de adesão voluntária a um aplicativo de terceiros, mas de software fornecido com o próprio telefone.
A exploração exigia proximidade lógica de rede, especificamente capacidade de atuar como intermediário no tráfego Wi-Fi da vítima. Esse requisito reduz o escopo em comparação com uma exploração remota pela Internet, mas continua relevante em redes públicas, hotspots, ambientes compartilhados, locais de trabalho com segmentação fraca e cenários nos quais o usuário se conecta a redes controladas por terceiros. A ausência de TLS no fluxo de atualização era o pré-requisito que convertia essa posição de rede em controle sobre conteúdo consumido por SDKs de segurança.
Outro elemento de exposição era a integração de vários SDKs dentro da mesma aplicação. Cada motor antivírus possuía comportamento próprio de atualização, mas todos compartilhavam o contexto do Guard Provider. Na prática, uma vulnerabilidade no processamento de arquivos do AVL podia alterar o estado consumido pelo Avast. Esse tipo de acoplamento enfraquece o modelo de separação esperado entre fornecedores de mecanismo antivírus e mostra que o isolamento interno entre bibliotecas é tão importante quanto a reputação individual de cada fornecedor integrado.
- Aplicativo afetado: Guard Provider, pacote
com.miui.guardprovider, pré-instalado em telefones Xiaomi convencionais. - SDKs envolvidos: motor Avast no carregamento de APK de atualização e motor AVL no processamento de configuração e arquivo ZIP de assinaturas.
- Condição de ataque: presença do agressor na mesma rede Wi-Fi da vítima com capacidade de interceptar e modificar tráfego HTTP.
- Diretório sensível:
/data/data/com.miui.guardprovider/app_dex/, usado para artefatos carregados pelo SDK do Avast. - Limite confirmado: a cadeia depende de alternância ou seleção de mecanismos antivírus dentro do aplicativo e de carregamento posterior do artefato substituído.
A detecção deve partir de eventos de rede e de integridade do aplicativo. Em redes gerenciadas, equipes podem procurar dispositivos Xiaomi realizando requisições HTTP para domínios de atualização associados aos SDKs, como au.ff.avast.sec.miui[.]com e update.avlyun.sec.miui[.]com, especialmente quando houver respostas anômalas, falhas repetidas, códigos de erro artificiais ou alternância incomum de destinos de atualização. Como os endpoints são de atualização legítima, o valor analítico está no padrão: tráfego sem TLS, alterações de resposta, erros persistentes e discrepância entre configuração recebida e artefato baixado.
No endpoint móvel, a telemetria ideal inclui criação, modificação e carregamento de arquivos no diretório privado do Guard Provider. Ambientes Android corporativos nem sempre permitem visibilidade direta em /data/data/, mas soluções de MTD, EDR móvel ou coleta forense autorizada podem observar mudanças em arquivos vps_update_*.apk, presença de ZIPs de assinatura com entradas de caminho anômalas e divergência entre o momento de download e o momento de carregamento pelo SDK. A presença de um arquivo de atualização do Avast modificado após uma atualização do AVL é um sinal particularmente alinhado à cadeia descrita.
Também é útil correlacionar comportamento de usuário e estado do aplicativo. Uma sequência com falhas de atualização do Avast, troca para AVL, download de pacote de assinaturas, novas falhas no AVL e retorno ao Avast deve ser tratada como suspeita quando ocorrer em rede não confiável. A análise não deve depender de um indicador único, porque os nomes de arquivo incluem marca temporal e os domínios observados fazem parte do fluxo de atualização do aplicativo. A defesa deve combinar rede, integridade de artefatos, logs do aplicativo quando disponíveis e inventário de versão corrigida.
- Requisições HTTP de atualização para domínios de SDKs com respostas inesperadas, redirecionamentos, erros repetidos ou conteúdo de configuração inconsistente.
- Criação ou sobrescrita de
vps_update_*.apkfora do ciclo normal de atualização do Avast. - Arquivos ZIP de assinaturas contendo entradas de caminho que tentam sair do diretório de extração esperado.
- Alternância incomum entre mecanismos Avast e AVL após falhas de atualização em rede Wi-Fi compartilhada.
- Carregamento de APK de atualização sem nova verificação de integridade após modificação no armazenamento privado do aplicativo.
A ação principal é garantir que os dispositivos Xiaomi afetados tenham recebido a correção disponibilizada pelo fabricante. Como se trata de aplicativo pré-instalado, a atualização pode chegar por mecanismo do sistema, atualização de aplicativo do fabricante ou pacote de firmware, conforme o modelo e a política de distribuição. Inventários corporativos devem registrar versão do aplicativo, nível de atualização do sistema e presença do Guard Provider para confirmar cobertura. Dispositivos sem capacidade de atualização devem ser tratados como ativos de maior risco em redes não confiáveis.
Do ponto de vista de arquitetura, a mitigação adequada exige mais do que trocar um endpoint. Atualizações de SDKs que resultam em carregamento dinâmico de código precisam usar transporte autenticado, validação forte de integridade e verificação de assinatura imediatamente antes da execução. A validação não deve ocorrer apenas no primeiro download, porque o arquivo pode ser alterado por outro componente com acesso ao mesmo sandbox. Quando múltiplos SDKs compartilham diretório e permissões, cada componente deve assumir que o armazenamento local pode ter sido modificado por outra biblioteca integrada.
Para ambientes corporativos, a contenção operacional inclui desencorajar uso de redes Wi-Fi abertas para dispositivos não corrigidos, aplicar proteção contra intermediário quando disponível, monitorar tráfego HTTP de atualização e revisar alertas de MTD relacionados a manipulação de tráfego. Em investigações, equipes devem preservar artefatos do aplicativo, registrar sequência de atualizações e verificar se houve substituição de arquivos no diretório privado antes de qualquer limpeza. A resposta deve priorizar atualização, validação do estado do dispositivo e remoção de artefatos não confiáveis, sem tentar reproduzir a cadeia em sistemas de produção.
O caso também orienta revisões de fornecedores. Aplicativos móveis que agregam SDKs de segurança, publicidade, análise ou proteção devem ser avaliados quanto a isolamento, permissões compartilhadas e caminhos de atualização. Um defeito de path traversal em uma biblioteca não deve permitir alteração de artefatos carregados por outra. Da mesma forma, arquivos de configuração recebidos em texto claro não devem determinar URLs, tamanhos e hashes de pacotes executáveis ou semiexecutáveis sem autenticação do canal e política de assinatura independente.
- Atualizar dispositivos Xiaomi afetados com a correção do fabricante e confirmar versão corrigida em inventário.
- Restringir uso de Wi-Fi público ou não confiável por aparelhos sem atualização aplicada.
- Monitorar tráfego HTTP de atualização associado ao Guard Provider e SDKs integrados.
- Verificar integridade de
vps_update_*.apke investigar sobrescritas após atualizações do AVL. - Exigir validação de assinatura imediatamente antes de qualquer carregamento dinâmico de APK por SDK.
- Revisar aplicações móveis com múltiplos SDKs para impedir compartilhamento inseguro de diretórios e permissões.
0 Comentários