Black Box

Flags inseguras no AndroidManifest.xml e Info.plist

Quando o aplicativo utiliza flags inseguras ou permissivas no AndroidManifest.xml (Android) ou no arquivo Info.plist (iOS), determinadas proteções nativas da plataforma podem ser desabilitadas ou enfraquecidas. Nessas condições, funcionalidades sensíveis podem ficar expostas, permitindo comportamentos não intencionais, como execução em ambientes inseguros, uso de componentes indevidamente exportados ou comunicações menos restritivas.


Network security config e network security flags no iOS

Quando o aplicativo não define adequadamente as configurações de segurança de rede, como Network Security Config ou network security flags no iOS, as comunicações podem ocorrer sem controles rígidos de proteção. Nessas condições, o aplicativo pode permitir conexões inseguras, certificados não confiáveis ou políticas de transporte menos restritivas.


⁠Ausência de ofuscação

Quando o aplicativo não utiliza mecanismos de ofuscação de código, sua lógica interna torna-se mais fácil de ser analisada e compreendida. Nessa condição, um atacante pode realizar engenharia reversa com maior facilidade, identificando fluxos de negócio, pontos sensíveis e possíveis vulnerabilidades.


ADB Backups Enabled

Quando o aplicativo permite a realização de backups via ADB (Android Debug Bridge), dados armazenados localmente podem ser extraídos a partir de um dispositivo com acesso físico ou lógico. Nessa condição, um atacante pode obter informações sensíveis, como arquivos de configuração, preferências ou dados do usuário, sem necessidade de comprometer diretamente o aplicativo.


Versão mínima de SDK e versão mínima do iOS

Quando o aplicativo define versões mínimas de SDK ou do iOS muito antigas, ele pode herdar limitações e vulnerabilidades conhecidas dessas plataformas. Nessas condições, mecanismos de segurança mais recentes deixam de ser aplicados, reduzindo o nível de proteção disponível para o aplicativo.


O aplicativo funciona em dispositivos com root e emuladores sem restrições

O aplicativo não implementa verificações para detectar ou restringir a execução em dispositivos rooteados ou emuladores. Esses ambientes contornam proteções críticas do sistema operacional e permitem que atacantes adulterem o aplicativo, interceptem o tráfego ou analisem lógicas sensíveis com pouca resistência. Enquanto o acesso root possibilita a leitura direta do armazenamento do aplicativo (bancos de dados, caches, shared preferences), ferramentas como Frida, Xposed ou Magisk podem ser utilizadas para realizar hooking de funções sensíveis e potencialmente burlar controles de segurança.


Ausência de mecanismos Anti-Hook e Anti-Debug

O aplicativo não possui mecanismos adequados de anti-hooking e anti-debugging, o que o torna vulnerável à manipulação em tempo de execução e à engenharia reversa. Sem essas proteções, atacantes podem conectar frameworks de instrumentação dinâmica (por exemplo, Frida, Objection) ou depuradores para interceptar, modificar e analisar processos sensíveis da aplicação.


Configurações de App Transport Security (ATS) inseguras

A configuração do Info.plist do aplicativo enfraquece as proteções do App Transport Security (ATS) do iOS. Especificamente, a chave:<key>NSAllowsArbitraryLoads</key> <true/>está definida como true. Essa configuração permite que o aplicativo inicie conexões de rede por meio de HTTP inseguro, em vez de exigir HTTPS/TLS. O ATS foi projetado para impor conexões seguras, e sua desativação contorna as práticas recomendadas pela Apple.


Nenhuma criptografia forte foi declarada na configuração do aplicativo

O arquivo Info.plist do aplicativo contém a chave ITSAppUsesNonExemptEncryption definida como false, indicando que o aplicativo não utiliza algoritmos de criptografia fortes, como AES ou RSA.Embora essa configuração possa ser válida para aplicativos que não lidam com dados sensíveis, ela também pode indicar criptografia fraca ou inexistente para dados em repouso ou em trânsito, especialmente se o aplicativo processar informações pessoais, financeiras ou relacionadas à autenticação.


Ausência de aviso sobre a preservação dos dados do usuário ao desinstalar

Quando o aplicativo não informa ao usuário sobre a preservação ou remoção de seus dados no momento da desinstalação, ocorre falta de transparência quanto ao ciclo de vida das informações armazenadas. Nessa situação, o usuário pode assumir incorretamente que seus dados foram excluídos, enquanto informações sensíveis podem permanecer armazenadas localmente ou em servidores.


Utilização da permissão de verificação de licença obsoleta

Quando o aplicativo utiliza permissões de verificação de licença consideradas obsoletas, baseadas em mecanismos descontinuados ou não recomendados pelas plataformas atuais, a proteção contra uso não autorizado torna-se ineficaz. Nessas condições, um atacante pode contornar com maior facilidade os controles de licenciamento, permitindo a execução, modificação ou redistribuição indevida do aplicativo.


Ausência de implementação de RASP (Runtime Application Self-Protection) no aplicativo

Quando o aplicativo não possui mecanismos de autoproteção em tempo de execução, não há monitoramento ou reação a comportamentos suspeitos durante sua execução. Com isso, um atacante pode realizar técnicas como engenharia reversa, hooking, injeção de código ou execução em ambientes comprometidos sem que o aplicativo identifique ou bloqueie essas ações.


Ausência de recursos de autenticação forte e biometria no aplicativo

Quando o aplicativo não implementa mecanismos de autenticação forte, como autenticação multifator ou biometria, o processo de acesso torna-se mais suscetível a ataques. Nessa condição, um atacante que obtenha credenciais válidas, por meio de vazamentos, phishing ou força bruta, pode acessar funcionalidades e informações sensíveis com maior facilidade.


Ausência de restrição ao uso de teclados de terceiros

O aplicativo não sobrescreve o método application:shouldAllowExtensionPointIdentifier: no app delegate. Como resultado, teclados de terceiros são permitidos por padrão, inclusive em campos de entrada sensíveis (por exemplo, campos de senha e formulários de autenticação).Teclados de terceiros podem capturar as teclas digitadas e transmiti-las para serviços externos. Sem restrições, dados sensíveis como nomes de usuário, senhas e tokens podem ser expostos caso uma extensão de teclado maliciosa ou comprometida seja utilizada.


Uso da classe padrão de proteção de dados

O aplicativo utiliza a classe padrão de proteção de dados (NSFileProtectionCompleteUntilFirstUserAuthentication) para o armazenamento de arquivos. Embora isso ofereça um bom nível de segurança, não é equivalente ao NSFileProtectionComplete, pois as chaves de descriptografia permanecem na memória após o dispositivo ser bloqueado ou o usuário encerrar a sessão.Isso aumenta o risco de acesso não autorizado a arquivos sensíveis caso o dispositivo seja comprometido enquanto estiver bloqueado.


Ausência do certificado SSL/TLS pinning

O aplicativo depende da validação TLS padrão com base em autoridades certificadoras confiáveis pelo sistema, mas não implementa o certificado SSL/TLS pinning. Sem o pinning, atacantes que controlem uma AC raiz confiável, porém comprometida, ou usuários induzidos a instalar uma AC maliciosa, podem interceptar e modificar o tráfego do aplicativo por meio de ataques man-in-the-middle (MitM).Embora o aplicativo utilize HTTPS por padrão, ele não aplica certificado SSL/TLS pinning. Como resultado, atacantes podem modificar respostas da API, injetar payloads ou até mesmo burlar verificações de integridade


Ausência de aviso sobre preservação de dados do usuário na desinstalação

O aplicativo não declara o atributo android:hasFragileUserData="true" em seu manifesto. Esse atributo é um recurso de experiência do usuário (UX) e privacidade que, quando habilitado, solicita ao usuário que escolha entre manter ou excluir os dados do aplicativo no momento da desinstalação. Para um aplicativo de carteira de criptomoedas, que gerencia dados altamente sensíveis e insubstituíveis — como chaves privadas e históricos de transações — a ausência desse aviso cria um risco significativo de perda acidental e permanente de dados pelo usuário, podendo resultar na perda irreversível de ativos digitais.


Serviços exportados sem proteção por permissões

O aplicativo declara vários serviços com android:exported="true" sem aplicar nenhuma permissão por meio de android:permission. Exemplos incluem SuspendWindowService, SignalCloneService e LogWindowService. Essa configuração permite que qualquer outro aplicativo no dispositivo envie intents manipulados para esses serviços. Sem a aplicação de permissões ou validação do chamador, atacantes podem abusar de funcionalidades privilegiadas expostas por esses serviços.Aplicativos maliciosos podem invocar ou se vincular (bind) a serviços exportados para acionar janelas de sobreposição, clonar sinais ou registrar dados sensíveis.


Bypass de Stack canaries

Stack canaries, também conhecidos como stack cookies, são valores inseridos na pilha (stack) para detectar ataques de buffer overflow. Caso ocorra um buffer overflow e o valor do canary seja sobrescrito, isso atua como um indicativo de uma possível exploração, acionando uma exceção.


Verificar vulnerabilidades baseadas em servidores web

Quando aplicativos Android utilizam um servidor web ou incorporam funcionalidades de servidor web, a superfície de ataque é inerentemente ampliada. Se esses componentes não forem projetados, desenvolvidos ou configurados corretamente, atacantes podem comprometer o servidor, roubar dados ou interromper serviços.Essas vulnerabilidades podem existir em diversos componentes da pilha de um servidor web, incluindo o próprio software do servidor, aplicações do lado do servidor e plugins ou módulos associados.


Aplicativo permite captura de tela em todas as sessões

Quando o aplicativo não implementa mecanismos de proteção para bloquear a captura de tela, como o uso de flags de segurança adequadas no sistema operacional (por exemplo, FLAG_SECURE no Android ou controles equivalentes no iOS), todo o conteúdo exibido na interface pode ser livremente capturado durante as sessões. Nessas condições, informações sensíveis apresentadas ao usuário — como dados pessoais, credenciais, tokens de sessão ou informações financeiras — podem ser registradas por meio de screenshots ou gravações de tela, aumentando o risco de vazamento de informações, exposição indevida de dados e uso malicioso por terceiros.

Atualizado