Recebemos um projeto para análise de vulnerabilidade em um aplicativo Android de forma a avaliar a segurança na construção do mesmo para que pudesse ser liberado na loja de aplicativos com as devidas funcionalidades e sem risco aos usuários do cliente em questão.

Ao iniciarmos os testes no arquivo .apk realizamos a descompilação do mesmo utilizando a ferramenta Visual Studio Code através do plugin APKLab disponibilizado de forma gratuita. Esse plugin realiza a descompactação do arquivo .apk para que o mesmo seja de fácil visualização de todo o código do aplicativo (se possível), pois em alguns casos pode haver códigos ofuscados que dependem de outras técnicas para serem ultrapassados.

Na imagem 01 abaixo é possível visualizar o plugin APKLab instalado no Visual Studio Code.

Em seguida, utilizamos a opção Ctrl + Shift + p para selecionar dentre os plugins disponíveis o APKLab conforme imagem 02 abaixo.

Uma vez realizada a escolha do plugin, é possível selecionar o arquivo .apk que iremos analisar, conforme imagem 03 abaixo. Após selecionado o mesmo, existem algumas opções disponíveis dentro do plugin APKLab que nos auxiliam em uma melhor visualização do conteúdo total do aplicativo.

Após selecionadas as opções acima o plugin APKLab irá tentar realizar a descompilação total do arquivo .apk de forma que será possível analisar toda a estrutura do código em texto claro, conforme a imagem 04 abaixo.

Após todos os procedimentos realizados acima, iniciamos a análise do código da aplicação de forma a encontrar algo que pudéssemos utilizar para inserir algum código malicioso na mesma a fim de obter acesso a dados sensíveis, etc. Conforme avançamos na análise do código observamos um comportamento estranho, pois a aplicação permitia a recompilação da estrutura do código de forma a obter um novo arquivo .apk válido para instalação sem que a assinatura fosse validada. Esse comportamento foi observado visto que utilizamos o mesmo plugin (APKLab) para recompilar o código, conforme visto na imagem 05 abaixo e também selecionamos as opções de recompilação (imagem 06) do mesmo selecionando apenas a opção “–use-appt2” e dessa forma o aplicativo é reconstruído e assinado pela própria ferramenta.

Dessa forma foi possível obter um aplicativo pronto para uso sem que houvesse qualquer erro em sua recompilação e isso acendeu um alerta pois se foi possível reconstruir o aplicativo e assiná-lo poderíamos tentar inserir algum código malicioso no mesmo como PoC (prova de conceito). Verificamos que havia uma activity que era invocada no momento da abertura do aplicativo. Com isso, verificamos a o código smali dessa activity e inserimos um código (Toast) para ser executado no momento da abertura da aplicação, conforme a imagem 07 abaixo:

Uma vez validada a inserção de código arbitrário na aplicação, iniciamos a criação de um código que pudesse nos fornecer uma shell reversa ao ser executada a aplicação pelo usuário e assim obter acesso ao dispositivo do mesmo.

Realizamos a construção de um código através do programa Android Studio de forma a obter uma lib para inserir na estrutura do código do aplicativo Android, gerar um novo arquivo .apk e explorar essa vulnerabilidade.

A criação da lib foi realizada em linguagem C e compilada diretamente pela ferramenta Android Studio, conforme observado na imagem 08 abaixo:

Após a compilação do código são geradas bibliotecas em algumas arquiteturas para aplicativos Android. Abaixo podemos verificar as pastas que são criadas após a compilação do código acima pela ferramenta Android Studio:

Na imagem abaixo podemos verificar a estrutura de uma pasta como exemplo e como inserimos a lib compilada para que essa seja compilada com o código da aplicação. A lib alterada está com nome “libbd.so”:

Uma vez realizada essa inserção de código precisamos fazer com que possamos abrir uma shell reversa em nossa estação como PoC (Prova de Conceito) e para isso precisamos executar o comando abaixo para que, ao clicar no aplicativo no device possamos receber essa conexão reversa:

adb.exe reverse tcp:4444 tcp:4444

Esse comando faz com que, ao ser executada a aplicação seja redirecionada a porta 4444 do device para a porta 4444 da estação onde o executável “nc.exe” está sendo executado e aguardando a conexão, conforme comando abaixo:

nc.exe -vnlp 4444

Conforme é possível visualizar na imagem 11 abaixo, após realizada a inserção da lib dentro da estrutura do código e a recompilação do mesmo, é possível verificar a obtenção da shell reversa ao ser executada aplicação:

Aproveitando, gostaria de agradecer ao grande Maycon Vitali por compartilhar seus conhecimentos com a comunidade, pois muito do mindset aqui empregado foi possível através dos conhecimentos adquiridos em seu canal na plataforma YouTube.

Por André Silva

Perdeu a primeira aventura? Não fique triste, você pode ler agora mesmo clicando aqui!