Falhas de desenho no uso do armazenamento externo permitem manipulação de arquivos temporários, travamento de bibliotecas nativas, negação de serviço e substituição de APKs em fluxos de atualização.
| Componente | Aplicativos Android que usam External Storage para pacotes, arquivos temporários, dados de tradução, modelos de reconhecimento de fala, dicionários offline ou APKs de atualização. |
| Vetor | Aplicativo malicioso com permissão WRITE_EXTERNAL_STORAGE modifica arquivos compartilhados antes de eles serem processados por bibliotecas nativas ou instaladores do aplicativo alvo. |
| Impacto | Travamento de aplicativos legítimos, negação de serviço, possível execução de código no contexto privilegiado do aplicativo atacado e substituição de APK em fluxo de atualização quando verificação e instalação ocorrem em etapas separadas. |
| Prioridade | Remover dependência de External Storage para dados sensíveis, validar arquivos imediatamente antes do uso, mover processamento crítico para Internal Storage e revisar fluxos de download, descompressão e atualização. |
| Artefatos | Foram citados diretórios de dados de Google Translate, Google Voice Assistant, Xiaomi Browser, Yandex Translate e Yandex Search em /storage/emulated/0/Android/data/. |
| Mitigação | Usar armazenamento segregado, integridade criptográfica vinculada ao momento de consumo do arquivo, permissões mínimas, cópias atômicas e rejeição de conteúdo alterado em áreas compartilhadas. |
A classe de ataque conhecida como Man-in-the-Disk explora uma diferença central entre o isolamento esperado por aplicativos Android e o comportamento real do External Storage. O armazenamento interno de um aplicativo é separado pelo sandbox do Android, enquanto o armazenamento externo funciona como área compartilhada que pode ser observada e modificada por outros aplicativos com permissões compatíveis. Quando um aplicativo usa essa área compartilhada como buffer de download, repositório permanente de pacotes ou ponto intermediário para arquivos que serão processados por código nativo, ele transfere parte da sua superfície crítica para um espaço que não oferece a mesma segregação. O problema não está em um único produto ou pacote, mas no padrão de uso: dados recebidos da internet ou armazenados para funcionamento offline são gravados em local acessível a outros aplicativos e posteriormente consumidos como se continuassem íntegros.
O vetor descrito exige que um aplicativo malicioso instalado no mesmo dispositivo consiga escrever no armazenamento externo. Com essa condição, ele pode substituir arquivos que serão lidos por um aplicativo alvo. O impacto varia conforme o fluxo atingido. Em bibliotecas nativas que analisam pacotes de tradução, modelos de fala ou dicionários offline, a manipulação do arquivo pode provocar travamento e abrir a possibilidade de injeção de código no contexto do aplicativo que processa o conteúdo. Em fluxos de atualização, a troca de um APK depois da verificação e antes da instalação cria uma condição de tempo em que o arquivo validado não é necessariamente o arquivo instalado. O resultado defensivo mais importante é que a permissão de escrita no armazenamento externo deve ser tratada como uma ponte entre aplicativos, e não como acesso inofensivo a uma área temporária.
Os exemplos citados abrangem aplicativos populares e componentes de alto privilégio operacional para o usuário: tradução offline, reconhecimento de fala, navegador com autoatualização e busca offline. Em todos eles, o ponto comum é a confiança excessiva em arquivos mantidos fora da área protegida do aplicativo. Essa confiança é perigosa porque o atacante não precisa comprometer o servidor de origem nem quebrar criptografia de transporte; basta modificar o artefato depois que ele já chegou ao dispositivo e antes de o aplicativo legítimo processá-lo. Em termos de engenharia segura, a falha está no intervalo entre download, persistência, validação, descompressão, leitura por biblioteca nativa e instalação, quando qualquer uma dessas etapas aceita conteúdo de uma área compartilhada sem controle suficiente de integridade, origem e atomicidade.
O fluxo Man-in-the-Disk começa quando o aplicativo legítimo baixa ou mantém dados em External Storage. Essa área pode ser uma partição dentro da memória interna do dispositivo ou um cartão SD, mas, do ponto de vista de segurança, o detalhe crítico é que ela é compartilhada. Um segundo aplicativo, instalado pelo usuário ou distribuído por outro canal, obtém permissão de escrita nessa área e passa a monitorar ou modificar arquivos pertencentes ao caminho lógico usado pelo alvo. O atacante não precisa necessariamente observar todas as operações em tempo real: nos exemplos de pacotes offline, a simples substituição de arquivos persistentes pode ser suficiente para que o aplicativo vulnerável leia conteúdo adulterado na próxima execução da função correspondente.
Quando o alvo usa bibliotecas nativas para interpretar os arquivos manipulados, a superfície fica mais sensível. O conteúdo salvo no armazenamento externo é entregue a código nativo, como bibliotecas de tradução, reconhecimento de fala ou leitura de dados offline. Se o parser nativo não estiver preparado para entradas corrompidas ou malformadas, o resultado inicial pode ser um crash. O material analisado descreve o uso de fuzzing em bibliotecas nativas executadas com apoio de QEMU, Android Runtime modificado, dalvikvm, GLib e AFL para encontrar condições de falha. Esse detalhe é relevante para defesa porque indica que os arquivos de pacote não são apenas dados passivos; eles são entradas complexas para parsers binários, e qualquer corrupção em formato, tamanho, offset ou estrutura interna pode expor defeitos de memória.
No caso do Google Translate, pacotes de tradução offline armazenados em /storage/emulated/0/Android/data/com.google.android.apps.translate/files/olpv3/v5/25/r11/ eram processados pela biblioteca libtranslate.so quando o usuário iniciava uma tradução. A manipulação dos arquivos nessa localização podia levar ao travamento da biblioteca. No Google Voice Assistant, arquivos de reconhecimento de fala eram baixados em /storage/emulated/0/Android/data/com.google.android.googlequicksearchbox/files/download_cache/ como arquivo compactado e depois descomprimidos para um diretório interno relacionado a modelos, com processamento por libgoogle_speech_jni.so. O risco observado está no momento em que o arquivo baixado em área compartilhada passa a alimentar o processamento interno.
O Xiaomi Browser ilustra uma variação diferente: o arquivo de atualização APK era baixado em /storage/emulated/0/Android/data/com.android.browser/files/update, verificado com SHA1 e instalado depois. A condição frágil aparece porque verificação e instalação são ações separadas. Se o arquivo é alterado depois da verificação e antes da instalação, a validação já não representa necessariamente o artefato final. Esse padrão cria uma janela de substituição que pode levar à instalação de um aplicativo não pretendido. Nos exemplos de Yandex Translate e Yandex Search, os pacotes offline ficam em diretórios próprios sob /storage/emulated/0/Android/data/, e a adulteração pode atingir bibliotecas como libmobile-android.so e liboffline_search-data_reader.so.
A superfície afetada inclui aplicativos Android que usam External Storage como área de trabalho para conteúdo que depois recebe tratamento privilegiado. Isso abrange arquivos baixados da internet, pacotes de recursos offline, arquivos compactados, modelos de aprendizado de máquina, dicionários, pacotes de tradução, caches de atualização e APKs temporários. O problema se agrava quando o aplicativo assume que o caminho em /storage/emulated/0/Android/data/ é suficientemente privado apenas por estar dentro de um diretório com o nome do pacote. Esse caminho organiza arquivos por aplicativo, mas não equivale ao isolamento do Internal Storage. A separação visual do diretório não substitui controles de permissão, validação e integridade.
A exposição também depende do desenho do fluxo. Um arquivo em External Storage usado apenas como mídia não sensível tem risco diferente de um pacote que será analisado por código nativo, descompactado para armazenamento interno ou instalado como APK. Quanto mais perto o arquivo estiver de uma transição de privilégio, maior a prioridade. A transição pode ser lógica, quando dados adulterados influenciam o comportamento do aplicativo; de memória, quando um parser nativo falha ao processar formato malicioso; ou de instalação, quando o artefato final substitui o binário esperado. A defesa deve mapear essas transições em vez de tratar External Storage apenas como tema de permissões.
A presença de aplicativos populares nos exemplos não transforma todos os dispositivos em comprometidos, mas demonstra que o padrão de desenvolvimento é comum até em ambientes maduros. Sistemas móveis com pouco espaço interno incentivam o uso de armazenamento externo para cache e dados permanentes, e aplicativos com recursos offline costumam manter arquivos grandes fora da área interna. Essa pressão de armazenamento cria um conflito entre conveniência e isolamento. Para equipes de desenvolvimento Android, o ponto técnico é revisar todos os lugares em que um dado sai da rede, passa por External Storage e depois é consumido por uma biblioteca, descompactador, instalador ou componente que opera com confiança elevada.
- Aplicativos que armazenam pacotes offline, modelos, dicionários ou arquivos compactados em External Storage antes do processamento.
- Fluxos de atualização que verificam o artefato em uma etapa e instalam o mesmo caminho em outra etapa posterior.
- Bibliotecas nativas que analisam arquivos persistidos em área compartilhada sem validação robusta de formato, tamanho e integridade.
- Dispositivos onde aplicativos de terceiros têm permissão de escrita no armazenamento externo e coexistem com alvos que confiam nessa área.
A detecção defensiva deve procurar sinais de adulteração de arquivos em caminhos de External Storage associados a aplicativos sensíveis. Em endpoint móvel, a telemetria útil inclui escrita por um pacote diferente no diretório de dados externos de outro aplicativo, mudanças frequentes em arquivos de pacotes offline, alteração de APK após evento de verificação, falhas de bibliotecas nativas logo após leitura de arquivos externos e reinicializações ou travamentos repetidos de funções específicas, como tradução offline, reconhecimento de fala ou busca local. A correlação temporal é importante: o sinal mais forte é a sequência em que um aplicativo escreve no caminho externo, o alvo processa o arquivo e ocorre crash, instalação anômala ou comportamento inesperado.
Logs de crash devem ser analisados com foco em bibliotecas nativas envolvidas no parsing dos artefatos. Referências a libtranslate.so, libgoogle_speech_jni.so, libmobile-android.so ou liboffline_search-data_reader.so são exemplos citados no contexto e devem ser entendidas como indicadores de classe, não como lista completa. A presença de falha em uma biblioteca nativa após carregamento de pacote offline sugere que o arquivo de entrada precisa ser preservado para análise forense. A coleta deve evitar executar novamente conteúdo suspeito; o objetivo é calcular integridade, comparar com versões esperadas e identificar qual aplicativo criou ou modificou o arquivo.
Em ambientes corporativos com MDM ou EDR móvel, a prioridade é enriquecer eventos de permissão e acesso a armazenamento. Aplicativos que solicitam WRITE_EXTERNAL_STORAGE e não têm justificativa funcional clara devem ser revisados. Também é útil observar instalações de aplicativos que ocorrem após download em diretórios externos, especialmente quando há separação entre verificação e instalação. A investigação deve diferenciar atualização legítima, cache normal e manipulação. Para isso, compare timestamps, proprietário lógico do arquivo, sequência de chamadas do aplicativo, origem do download e ocorrência de crash ou instalação logo após a alteração.
- Escrita em diretórios sob
/storage/emulated/0/Android/data/pertencentes a outro aplicativo antes de crash ou instalação. - Travamentos de bibliotecas nativas durante processamento de pacotes offline, arquivos compactados, modelos de fala ou dicionários locais.
- Alteração de APK em caminho de atualização depois de validação de integridade e antes da instalação efetiva.
- Aplicativos com
WRITE_EXTERNAL_STORAGEcombinados com atividade sem relação clara com mídia, documentos ou backup do usuário. - Mudanças de hash, tamanho ou timestamp em arquivos de recursos offline entre o download e o momento de consumo pelo aplicativo alvo.
A mitigação principal é não usar External Storage para artefatos que influenciam execução, instalação, decisão de segurança ou processamento nativo sensível. Dados que serão interpretados por bibliotecas nativas, usados para atualizar componentes, descompactados para diretórios internos ou tratados como pacotes confiáveis devem permanecer em Internal Storage sempre que possível. Quando o uso de External Storage for inevitável por tamanho ou compatibilidade, o aplicativo precisa tratar todo arquivo nessa área como não confiável até o momento exato de consumo. Isso inclui validar integridade depois da última leitura, usar nomes temporários imprevisíveis, evitar janelas entre verificação e uso, copiar para área interna de forma atômica e rejeitar qualquer mudança detectada durante o fluxo.
A validação criptográfica deve estar ligada ao artefato que será realmente processado ou instalado. No exemplo do fluxo de atualização, verificar um APK e instalar depois o mesmo caminho cria uma janela de substituição; a defesa adequada é reduzir a janela, manter handle seguro para o conteúdo validado ou mover o arquivo para armazenamento interno protegido antes da instalação. SHA1 é citado no contexto como parte do fluxo do Xiaomi Browser, mas a lição defensiva maior é que qualquer verificação separada do consumo final perde força se o arquivo continua modificável por terceiros. A validação também precisa cobrir arquivos compactados e seus conteúdos após extração, porque a manipulação pode ocorrer no pacote original ou nos arquivos derivados.
Para desenvolvedores, a revisão deve começar por inventário de chamadas que gravam ou leem External Storage. Cada uso deve responder três perguntas: qual aplicativo pode modificar esse arquivo, qual componente consome esse conteúdo e qual é o pior impacto se o arquivo for trocado por uma entrada malformada. Para equipes de segurança, a prioridade é testar parsers nativos com entradas corrompidas, executar análise de permissões, revisar fluxos offline e verificar se há instalação ou execução dependente de arquivos compartilhados. Para resposta a incidente, a contenção envolve remover o aplicativo suspeito, preservar os artefatos adulterados, limpar caches externos, reinstalar ou atualizar o aplicativo afetado por fonte confiável e validar que os diretórios externos não continuam sendo usados como raiz de confiança.
A correção também deve considerar experiência de produto. Aplicativos frequentemente usam External Storage para economizar espaço interno ou permitir persistência de dados grandes, mas a escolha precisa ser explícita e acompanhada por controles. Pacotes offline podem ser baixados em área temporária, mas devem ser transferidos para armazenamento interno antes de alimentar bibliotecas nativas. Caches devem ser descartáveis e reconstruíveis, nunca fonte única de verdade. Arquivos de atualização devem ser protegidos contra troca entre validação e instalação. Em síntese, External Storage deve ser tratado como entrada de usuário ou de outro aplicativo: útil para armazenamento, mas inadequado como fronteira de confiança.
- Mover pacotes sensíveis, APKs de atualização, modelos e arquivos processados por bibliotecas nativas para Internal Storage.
- Validar integridade no momento de consumo, sem manter intervalo modificável entre verificação, descompressão, leitura e instalação.
- Executar fuzzing e testes negativos em parsers nativos que recebem arquivos salvos fora do sandbox do aplicativo.
- Reduzir ou remover
WRITE_EXTERNAL_STORAGEquando a função do aplicativo não exigir escrita ampla em armazenamento compartilhado. - Registrar e bloquear alterações inesperadas em artefatos offline antes de carregar bibliotecas, instalar atualizações ou importar dados para diretórios internos.
0 Comentários