Passo a Passo

Está sessão apresenta um passo a passo de pentest (teste de penetração ou intrusão) baseado em informações coletadas do Guia de teste de segurança móvel da OWASP (OWASP Mobile Security Testing Guide).

PreviousMetodologia NextReferências

Last updated 4 years ago

Was this helpful?

Passo a Passo

Instalar Virtual Box Oracle ().
Baixar a ISO do Sistema Operacional Santoku (().
Instalação de alguns drivers que ajudarão o SO a se comportar bem (drivers presentes na sessão de Ferramentas).

Reiniciar, agora é possível utilizar o Full screen mode.
Criar uma conta no site do Genymotion
Instalar Genymotion(emulador Android)
Criando uma imagem android

Configurar o modo de rede na configuração(dentro do Genymotion) para Bridge
Conectar o ADB(Android Debug Bridge) entre o SO e o Emulador

$ adb shell (entrando nos files do android)
$ cd /data/app (apps do android)
Explorando mais o Emulador

Ter qualquer apk e instalar dentro do genymotion: $ adb install “apk.file.apk”
$ adb logcat (ter acesso aos log das aplicações)

Do emulador para a ISO(imagem):

1. Android App

Classes.dex(file), analisar como o app funciona
AndroidManifest.xml (file), características do app, e também com META-INF(folder) podendo descobrir qual tipo de permissão do usuário, um código fonte completo, enquanto gerenciador de intenção de atividades.
res(folder), assests(folder) e lib(folder), como componentes adicionais.

$ vim classes.dex

Não verá nada porque há a necessidade de descompilar.
Android-apktool, ferramenta APK para reverter ou descompilar qualquer arquivo APK do android. (já instalado no Santoku (SO)
JaDX Decompiler, reverter o aplicativo Android.

$ apktool d app.apk, “d” de decompiler.
Descompilando:

Primeiro App sem permissões de usuario em “androidmanifest.xml”
$ vim AndroidManifest.xml, para ver as permissões de usuário

“smali” é o diretório que contém nosso código-fonte, diretório que varia de acordo com o desenvolvimento da aplicação.

$ cd smali, conseguindo ter acesso ao código.

Outra maneira é pelo Jadx

2. Android Application Signing

Assinar um app antes de torná-lo publico, através de um certificado de autoridade ou uma auto-assinatura, através de diferentes algoritmos de criptografia, tendo as duas chaves a pública e privada, mantendo a segunda em segurança.
- Assinatura JAR (esquema v1)
  É baseado em JAR assinado . As assinaturas v1 não protegem algumas partes do APK, como metadados ZIP. O verificador de APK precisa processar muitas estruturas de dados não confiáveis (ainda não verificadas) e, em seguida, descartar os dados não cobertos pelas assinaturas. Isso oferece uma superfície de ataque considerável. Além disso, o verificador de APK deve descompactar todas as entradas compactadas, consumindo mais tempo e memória.
- Esquema de assinatura APK v2 e v3 (esquema v2 +)
  O esquema v2 foi atualizado para v3 no Android 9 para incluir informações adicionais no bloco de assinatura, mas de outra forma funciona da mesma forma. O conteúdo do APK é hash e assinado, então o APK Signing Block resultante é inserido no APK.
  Durante a validação, o esquema v2 + trata o arquivo APK como um blob e executa a verificação de assinatura em todo o arquivo. Qualquer modificação no APK, incluindo modificações nos metadados ZIP, invalida a assinatura do APK. Essa forma de verificação de APK é substancialmente mais rápida e permite a detecção de mais classes de modificações não autorizadas.

3. Tráfego Android

Passivo: analisando o tráfego secretamente, capturando os dados para a análise posterior, farejando o pacote TCP.
Ativo: interceptação de solicitação de usuário, por exemplo, utilizando algumas ferramentos proxy, como BURPSUITE.

Ferramenta já presente no Santoku SO.
Primeiro: Proxy < Options < Edit(Selecionando o primeiro) < All interfaces

Obs: Configure a Placa em modo Bridge no virtual Box : Botão direito < Configuraçoes < Rede < Placa em modo Bridge

$ Ifconfig , para pegar o ip do SO

4 . Configurações de Proxy com o IP do Santoku (SO)

Digitando qualquer coisa no navegador

Interceptação

Instalar o certificado do burp no android: http://burp

Configurações < Segurança < Instalar do cartao SD < certificado.crt

5. Aplicativo de Teste (DIVA - Damn Insecure and Vulnerable Application)

Link : payatu.com/damn-insecure-and-vulnerable-app/
Procure por “diva-beta.apk”

Instalar o 010 Editor para analisar arquivos.dex transformandos em arquivos java futuramente.
Analisando os Logs de app
Descobrindo que o processo é “21425” podemos através do comando $adb logcat | grep 21425

Conseguimos armazenar o número do cartao de crédito através dos Logs.

6. Problemas de Codificação (HardcodeActivity)

Descobringo o codigo “HardcodeActivity” descobrimos uma key

Com essa key, seria possível garantir algum acesso no app.

7. Armazenamento de Dados de Forma Insegura

Em um app que armazena login e senha temos:

Salvando um password : admin, secretpassword

Assim como em hardcore inssues, analisamos através do “jd-gui” as classes.dex que foram transformadas em codigos .jar através do comando $ d2j-dex2jar classes.dex

Através do comando $ jd-gui “classes .dex transformadas em “.jar” para alise do código fonte, sendo possivelmente as atividades inseguras do logon

Ao abrir código podem ver um metodo que salva as credencias de user e password, em seguida voltamos ao Santoku e ao emulador atraves do $ adb shell

Entramos em seguida $ data/data,
$ cd jakhar.assem.diva
$ cd $shared_prefs
e vemos que existem um arquivo chamado “jakhar.assem.diva_preferences.xml”
usando $ cat jakhar.assem.diva_preferences.xml, podemos ter acesso ao nosso login e senha salvos.

8. Banco de Dados Inseguro

Salvando um login como demo, e password como secretpassword em outra partição, vamos tentar descobrir aonde estão esses dados.

Usando a mesma técnica anterior, analisamos novamente a codificação e vemos sua estrutura e como está armazenado e vamos ver se está ou não criptografado

No android usamos o comando $ sqlite3 ids, pelo fato desse banco é o mais comum nos androids. Depois um .tables, e faremos um select para visualizar

9. Arquivos Temporários Inseguros

Usando demo como login e demodemodemo como senha

Abrimos novamente o jd-gui, e as classes.2jat para analisar o código temporários

Seguindo o mesmo processo dos tópicos anteriores conseguimos visualizar os arquivos temporários

Utilizando novamente o $ cat uinfo-1634723552tmp

obtendo assim, os dados do arquivo temporário.

10. Dados do Cartão SD

Utilizando dessa vez “lucas” como login e “senhamuitosecreta” como password

Analisaremos novamente o código fonte atraves do “jd-gui”, conseguimos observar como o método funciona e como e salvo o arquivos

Procurando agora no SDCARD pelo arquivo, utilizaremos o comando $ ls -a, para encontrar os arquivos ocultos

Encontramos o “uinfo.txt” abrindo novamente com o comando “cat” e tendo assim acesso as credenciais ocultas

11. SQL INJECTION

Colocando algo malicioso na entrada de dados onde o app não valida ou higieniza os dados de inserção, podendo resultar no despejo de todo o banco de dados.
Em uma caixa de busca, supostamente colocamos algo malicioso e assim que é pressionado o botao de “search” tentaremos recuperar todos os dados.
Verificando o código fonte novamente para analisar a estrutura e olhando o select

Obtemos: “SELECT * FROM sqliuser WHERE user = “+ localEditText.getText().toString+””
Inserindo algo malicioso no código como uma condição para mostrar os dados com o código “SELECT * FROM sqliuser WHERE user = ‘ 1’ or ‘ 1’=’1 ”, podemos simplesmente depois na própria barra de pesquisa digitá-lo para ter acesso a database: