Em meio a pesquisas voltadas à segurança mobile, estudando novas tecnologias, frameworks, estratégias e análise de aplicativos, alguns questionamentos começaram a surgir. Entre a análise estática e a análise dinâmica, o que realmente existe? Será que o trabalho de um pesquisador ou de um pentester mobile se resume apenas a alternar formas de exploração e ferramentas?
Refletindo sobre isso, estava claro que havia uma peça faltando. Foi a partir dessa reflexão que elaboramos uma fase complementar aos assessments: o Mapping.
O que é Mapping no Pentest Mobile?
O conceito de Mapping está diretamente ligado ao ato de mapear o aplicativo. Mas não somente uma análise estática ou dinâmica. Trata-se de entender o aplicativo por meio do uso cotidiano, de maneira semelhante aos insights que um session replay pode revelar quando o assunto é observabilidade de UX.
O objetivo é simples: com o uso legítimo de um app, identificar pontos de entrada, comportamentos, tecnologias e modos de exploração. Tudo isso sem ferramentas sofisticadas em um primeiro momento, apenas usando o aplicativo com atenção e propósito.
Como é feito o Mapping?
E como isso é feito no dia a dia? Ao iniciar um novo teste ou pesquisa, é feita a instalação da aplicação em dispositivo pessoal próprio, de forma a utilizá-la por um périodo. Se for uma aplicação privada, que depende de cadastro interno, a abordagem muda, mas isso é assunto para um próximo artigo sobre cadeias de ataque em aplicações mobile a partir de OSINT e spear phishing.
De onde surgiu o Mapping?
Essa forma de pensar surgiu de experiências com Web Pentesting, principalmente da técnica de Spidering, que consiste em explorar a aplicação web em seu uso natural ou por meio de crawlers, mapeando suas páginas e interações. Essa etapa quase sempre revela gaps de segurança, falhas de lógica, entrypoints e até aumenta o escopo dos testes.
No caso dos testes mobile, enquanto a análise estática ajuda a descobrir endpoints, componentes e potenciais vulnerabilidades, e a análise dinâmica revela o comportamento sob instrumentação, o Mapping se propõe a ser uma primeira camada: usar o app como qualquer usuário faria, mas com olhar malicioso.
Afinal, no dia a dia, um atacante dificilmente vai recorrer imediatamente a técnicas de instrumentação ou engenharia reversa para realizar uma fraude. Muitas vezes ele se aproveita de comportamentos legítimos, que, se mal interpretados ou escalados, podem gerar prejuízos enormes.
Com essa visão, foi utilizada uma ferramenta que já faz parte do ecossistema de desenvolvimento: o FigJam, do Figma. Porém, com um novo propósito: criar conexões entre as sessões do app e montar um registro visual. Dessa forma, cada vez que o material é revisitado, é possível anotar hipóteses de vulnerabilidades e refletir sobre o comportamento da aplicação.
Abaixo, um exemplo do que seria um Mapping de uma aplicação, utilizando o FigJam (embora qualquer outra ferramenta de anotação ou fluxograma, como Miro ou Draw.io, possa ser usada). Nesse caso, informações sensíveis foram censuradas para proteger propriedade intelectual de terceiros. Esta aplicação em específico foi escrita em Flutter.
A lógica por trás dessa etapa é simples: durante o uso do aplicativo, são feitas capturas de tela e anotações, construindo uma cadeia de usabilidade. Esse fluxo permite visualizar as sessões da aplicação e direcionar os testes de maneira mais estratégica: quais áreas são mais sensíveis, quais botões de ação podem gerar comportamentos inesperados e onde podem surgir gaps de segurança.
Quando o Mapping é realizado, a análise deixa de ser apenas técnica e passa a envolver criticidade, funcionalidades e até preocupações de UX e engenharia de software. Às vezes, em um simples entrypoint ou lógica de negócio, encontramos vulnerabilidades sistêmicas ou até o acesso antecipado a sessões de releases futuros.
Com essa base, vamos falar de alguns exemplos práticos de vulnerabilidades que podem ser identificadas durante o Mapping. Para isso, selecionamos três cenários que vemos com frequência em aplicações bancárias e de e-commerce.
Vulnerabilidades que podem ser identificadas durante o Mapping
Fingerprint Bypass
Essa falha é particularmente interessante, pois está diretamente ligada à forma como a validação biométrica é implementada. Em muitos aplicativos, o desenvolvedor simplesmente chama a API nativa do sistema para verificar se há biometria cadastrada no dispositivo. O problema é que essa abordagem não garante que a digital cadastrada seja realmente a do dono da conta.
No Brasil, infelizmente, o problema da segurança pública faz com que roubos de celulares muitas vezes sejam acompanhados da exigência da senha da vítima. O criminoso, de posse do dispositivo desbloqueado, pode cadastrar uma nova biometria e, em seguida, acessar aplicativos bancários ou outros apps sensíveis.
Nesse cenário, confiar apenas na biometria fornecida pelo sistema é abrir a porta para um roubo de sessão, perda financeira e fraude.
E existem caminhos para mitigar isso: armazenar a informação biométrica vinculada ao cadastro do usuário, validar se novas biometrias foram adicionadas ao dispositivo ou até integrar serviços de terceiros que cruzem dados documentais e confirmem a autenticidade das ações.
Na prática do Mapping: durante o uso cotidiano, cadastre uma nova biometria no dispositivo e veja como o app reage. Alguns bancos já implementam etapas adicionais nesse processo, exigindo autenticação extra para validar o comportamento do usuário. Outros, porém, ainda deixam essa brecha aberta.
Background Screen Caching
Outra falha observável pelo Mapping é o Background Screen Caching. Embora nem sempre seja considerada crítica, pode se tornar perigosa dependendo do contexto, especialmente quando pensamos em malwares ou info-stealers.
Essa vulnerabilidade ocorre porque, ao enviar o app para segundo plano, o sistema pode gerar snapshots da tela, exibidos na visão de multitarefas. Se o aplicativo não tiver um mecanismo para ocultar ou limpar a tela nesses casos, informações sensíveis (como credenciais, tokens ou dados pessoais) podem ser reveladas.
Na prática do Mapping: abra o app em uma tela sensível, minimize e observe o que aparece na visualização de multitarefas. Se dados importantes ainda estiverem visíveis, já temos um potencial vetor de ataque.
Execução em ambientes e SDKs inseguros
O terceiro cenário é um dos mais comuns: como a aplicação reage quando executada em ambientes manipulados ou em versões antigas do sistema operacional.
Por exemplo: em um dispositivo pessoal, você costuma utilizar o ADB para diversas ações de instalação e configuração, o que exige que o modo desenvolvedor esteja ativo. Se um aplicativo executa normalmente em um ambiente assim, sem restrições ou avisos, podemos considerar que ele está rodando em um contexto manipulado. Aplicativos governamentais, em geral, implementam esse tipo de proteção, mas muitos outros simplesmente ignoram.
Outro fator importante é a versão do dispositivo. Considerando um iOS 15, um Samsung A54 ARM e um J2 Prime, este último roda uma versão de SDK extremamente antiga e cheia de vulnerabilidades conhecidas. Muitas vezes, por incompatibilidade, o app quebra ao executar, revelando erros de stack trace que podem ser explorados.
Na prática do Mapping: testar o app em diferentes dispositivos e ambientes (modos de desenvolvedor, versões antigas de SO, dispositivos com root ou jailbreak) já revela comportamentos interessantes. Logs inesperados, falhas de compatibilidade e erros de execução se tornam pistas valiosas para pós-exploração.
Conclusão
Esses foram apenas alguns exemplos de como o Mapping pode revelar falhas de segurança com base em uso cotidiano, sem instrumentação avançada.
Consideramos o Mapping uma etapa indispensável nos assessments. É o que permite olhar para além do macro e, longe das ferramentas, construir uma mentalidade de testes a partir da experiência real de uso. Assim, é possível imaginar, de forma prática, como um atacante exploraria uma funcionalidade e qual seria o impacto para a aplicação ou para o usuário final.
Quer conhecer o Pentest Mobile da Vantico? Clique aqui e fale conosco.
