Scanners automáticos: o que eles pegam e o que passa batido

Depois de ler manualmente o manifesto, o bundle JavaScript e o código nativo, chega a hora de rodar os scanners automáticos. A ordem importa: eles geram volume, muito falso positivo e algumas descobertas genuinamente úteis, mas só fazem sentido depois da análise manual, como uma rede de segurança para o que passou despercebido, não como atalho para pular a leitura do código.

APKiD: identificando o que protege o app

O APKiD é uma ferramenta de impressão digital: ele examina o APK e identifica qual compilador, ofuscador, empacotador ("packer") e técnicas anti-análise (anti-depuração, anti-root, anti-VM) foram usados na build.

apkid example.apk

Para um app que lida com dado sensível, o esperado costuma ser justamente a presença dessas proteções: ofuscação de código e algum nível de detecção de ambiente root ou emulado. A ausência delas num app desse tipo não é uma vulnerabilidade por si só, mas indica uma oportunidade de hardening (reforço de segurança) que faltou.

apkleaks: pistas, não resultados

O apkleaks varre o pacote em busca de padrões conhecidos de segredo e URL, usando expressões regulares genéricas.

apkleaks -f example.apk -o apkleaks.txt
grep -E '^\[' apkleaks.txt

A limitação principal é que ele não entende contexto: reconhece um padrão de texto, mas não sabe se aquele valor é, de fato, uma chave secreta, um identificador aleatório qualquer, ou um número de versão que por acaso bate com o formato de um token.

Isso produz tanto ruído (um IP que na verdade é um OID de certificado, uma string que "parece" um JWT mas não é) quanto lacunas: um segredo guardado numa variável chamada CLIENT_SECRET no BuildConfig, por exemplo, não costuma ser reconhecido por uma regex genérica, porque o valor em si pode não ter nenhum formato especial. É por isso que a varredura específica de variáveis de ambiente, feita manualmente no artigo sobre segredos no binário, continua necessária mesmo depois de rodar esse tipo de scanner.

gitleaks e trufflehog

Ferramentas como o gitleaks e o trufflehog foram criadas originalmente para buscar segredos em repositórios Git, mas funcionam igualmente bem apontadas para as saídas descompiladas de um APK, combinando regras por padrão (como o apkleaks) com análise de entropia: uma string com alta aleatoriedade de caracteres tem mais chance de ser uma chave ou token do que texto comum.

gitleaks dir . -v --no-banner
trufflehog filesystem . --no-verification

Um detalhe importante do trufflehog: por padrão, ele tenta verificar cada credencial encontrada, fazendo uma chamada real ao provedor correspondente (API da AWS, do GitHub, e assim por diante) para confirmar se ela ainda está ativa. Isso significa enviar o possível segredo para um serviço externo, o que pode não ser aceitável dependendo do escopo do teste. A flag --no-verification, usada acima, desliga essa checagem; a documentação da ferramenta detalha o comportamento padrão.

MobSF: o raio-x automatizado

O Mobile Security Framework (MobSF) é o scanner mais abrangente da lista: ele recebe um APK ou IPA, roda uma bateria de checagens estáticas (e, com configuração adicional, dinâmicas) e devolve um relatório organizado por categoria de risco, com boa cobertura dos mesmos temas do OWASP MASVS.

docker run -it --rm -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest

Com o container no ar, basta abrir http://localhost:8000, enviar o APK ou o IPA pela interface e ler as seções Manifest, Code, Secrets e URLs. Ele cobre, numa única passada, boa parte do que os artigos anteriores desta série descreveram manualmente: permissões, componentes exportados, uso de criptografia fraca, segredos aparentes e configuração de rede.

Isso o torna um bom ponto de partida para um primeiro raio-x do app, mas não substitui a leitura dirigida: o MobSF sinaliza padrões genéricos, sem o contexto de negócio que diz se um determinado achado é, de fato, explorável naquele app específico.

Chaves de serviços de nuvem expostas

Uma categoria de achado que vale a pena testar à parte: chaves de API do Google e do Firebase encontradas no app às vezes correspondem a projetos configurados sem restrição adequada.

grep -oE 'name="(google_api_key|google_storage_bucket|firebase_database_url|project_id)">[^<]+' apktool-out/res/values/strings.xml

Ferramentas como o GMapsAPIScanner testam se uma chave do Google Maps está habilitada para APIs que ela não deveria acessar (geocoding, gerenciamento de faturamento), e uma chamada direta a um banco do Firebase Realtime Database sem autenticação revela, em segundos, se as regras de segurança do projeto estão abertas para qualquer leitor:

curl https://<projeto>.firebaseio.com/.json

Esse tipo de teste é importante: faz uma requisição real contra a infraestrutura de produção do dono do app, e deve ser feito só com autorização explícita de quem administra aquele projeto, já que pode gerar cobrança ou alertas de segurança no provedor de nuvem.

Instalando as ferramentas

A maioria dessas ferramentas se instala com um gerenciador de pacotes comum:

brew install jadx apktool gitleaks trufflehog
uv tool install apkleaks
uv tool install apkid
docker pull opensecurity/mobile-security-framework-mobsf

Por que a ordem importa

Rodar os scanners antes da leitura manual tende a gerar uma lista longa e desorganizada, difícil de priorizar porque falta o contexto de como as partes do app se conectam. Rodá-los depois transforma essa mesma lista numa checagem cruzada: cada achado do scanner é comparado contra o que já foi visto manualmente, e, nesse ponto, qualquer coisa nova que aparecer merece atenção redobrada, já que passou despercebida na primeira leitura.

No próximo artigo: a mesma pergunta de análise estática, só que no lado iOS, onde o binário, o Info.plist e os entitlements contam uma história parecida, mas com ferramentas diferentes.