Um Raio-X do código malicioso.

Olá e obrigado pela sua visita.  Neste artigo, cubro o MobSF (Mobile Security Framework).  Trata-se de um código aberto escrito em Python e projetado para analisar malware em plataformas móveis (Android e iOS).  Ele foi concebido por Ajin Abraham, e é atualmente mantido por ele, juntamente com a ajuda Dominik SchlechtMaton Dobrushin.  É uma ferramenta bem interessante.

Para entender porque decidi escrever sobre malware, especialmente no Android, coletei algumas estatísticas para mostrar o aumento na quantidade de usuários de dispositivos móveis, e a correspondente diminuição no uso de computadores de mesa e laptops.  Veja as Figuras 1 e 2.

Figura 1: uso de desktop contra mobile (fonte: Telegraph.co.uk)

 

Figura 2: uso da Internet por tipo de dispositivo (fonte: StatCounter.com)

À medida que aumenta o número de usuários de Android, obviamente, aumenta a possibilidade de ataques sobre ele.

Os gráficos anteriores são significativos.  Vamos ver o quanto o Android colabora para esse movimento crescente do uso de dispositivos móveis.  A Figura 3 mostra isso.  Ela exibe a diferença colossal que existe entre o Android e todos os demais sistemas operacionais móveis e fabricantes relevantes.  A grande quantidade de fornecedores neste segmento, aliado com preços mais acessíveis de alguns modelos, certamente contribui para esta subida. A possibilidade de executar root nos equipamentos também ajuda na venda de aparelhos com Android.

Figura 3: o uso de Android comparado com outros sistemas/fabricantes (fonte: Statista)

À medida que aumenta o número de usuários de Android, obviamente, aumenta a possibilidade de ataques sobre ele. Sabemos que isto acontece com o Windows, por exemplo. De acordo com a Figura 4, ainda é o sistema operacional para desktops mais usado no mundo. O crescente uso do sistema operacional móvel desperta a atenção dos cibercriminosos.

Figura 4: uso de sistemas operacionais para desktop (fonte: WindowsReport.com)

 

Contato Inicial

O MobSF é mantido no GitHub.  O site oficial do projeto está aqui.  Lá, o autor disponibiliza alguns recursos para aprendizado, compartilha apresentações em eventos e oferece links para doações. Muito justo. 🙂

Como qualquer repositório GitHub, você pode começar os trabalhos clonando-o e inspecionando o código. De fato, você pode interagir com a ferramenta do início ao fim desta maneira. Se for este seu caso, não se esqueça de instalar os requisitos expressos no arquivo requirements.txt. Felizmente, o autor fornece uma imagem/container Docker para facilitar o trabalho, e foi como eu segui para escrever este artigo.  Na verdade, recomendo fortemente que você siga por este caminho também, pois é bem mais prático.  Você pode construir a estrutura do zero usando o Dockerfile fornecido ou, melhor ainda, baixar a imagem já construída e iniciar o container.

Para este artigo, fiz todos os testes sobre o macOS.  Se você ainda não conhece nada de Docker, confira minha série de posts sobre este conceito. Um dos fundamentos de containers é o compartilhamento de kernel do sistema operacional que os mantém. Como o MobSF foi feito primariamente para rodar sobre Linux, não posso executar diretamente o container no macOS. Assim, a alternativa é empregar o Docker Machine. Através do uso de uma máquina virtual Linux, o container funciona normalmente. Conheça mais sobre Docker na minha série de posts e no site oficial.

 

Hands-On Fase 1

Vamos continuar com a abordagem Docker. Iniciei instalando os gerenciadores de pacote Homebrew e Cask. Com o Cask, instalei o Virtualbox (necessário para executar a máquina virtual Linux). Com o Homebrew, instalei o Docker Engine e o Docker Machine.

$ brew install docker
$ brew install docker-machine
$ brew cask install virtualbox

O passo abaixo também pode ser executado no Windows, se você já possuir o Virtualbox instalado. Se você estiver executando Linux, pule este passo:

$ docker-machine create -d "virtualbox" --virtualbox-disk-size "5000" kernel-docker

O comando acima cria uma VM de nome “kernel-docker”, com um disco de 5 GB, usando o Virtualbox como provider.  Depois de criada, a máquina é automaticamente iniciada.  Após desligar seu computador, caso queira voltar ao ambiente de análise, basta iniciar a VM assim:

$ docker-machine start kernel-docker

As outras operações possíveis são stop e list.  Para desligar a VM, simplesmente substitua o “start” do comando acima por um “stop”. Para listar todas as máquinas virtuais criadas com o Docker Machine, simplesmente execute “docker-machine ls”. A VM é iniciada no modo headless, ou seja, você não verá qualquer console. Caso queira vê-la, inicie a interface gráfica do Virtualbox. De qualquer forma, isto não é necessário.

O MobSF pode fazer análises estáticas e dinâmicas do malware.

Não terminamos ainda. Será necessário exportar algumas variáveis de ambiente para dizer ao Docker Engine como se conectar à máquina virtual. Assim, digite (substitua “kernel-docker” com o nome da VM que você criou):

$ eval $(docker-machine env kernel-docker)

Por fim, inicie o container. No caso do Linux, é o único passo a ser executado, uma vez que o Docker Engine já esteja instalado:

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

Observe que eu adicionei a opção “–rm” ao comando acima.  Isto é útil para remover o container tão logo ele é finalizado, e liberar o espaço em disco correspondente.  Se você não incluí-la, depois de alguns usos, poderá ter uma quantidade considerável de containers parados.  Uma das ideias principais de containers é que eles sejam o mais descartáveis possível.  A opção “-it” mostra a saída do container na sua tela, incluindo resultados de operações do MobSF.  Assim, você pode encerrá-lo com um “Ctrl+C”. Ao contrário do que é apresentado na documentação do MobSF, você não precisa manualmente baixar a imagem do container, pois a simples execução do mesmo (último comando mostrado) já faz isso.

Se você estiver usando Linux, já pode acessar a interface gráfica do MobSF pelo endereço http://localhost:8000.  Do contrário, você precisará do endereço IP da VM.  No meu caso, a VM obteve o endereço 192.168.99.100.  Este endereço é fornecido pelo serviço de DHCP do Virtualbox.

O MobSF pode fazer análises estáticas e dinâmicas. A primeira consiste em descompilar o binário enviado, verificar strings, system calls, comunicação de rede e as permissões solicitadas pela aplicação. É muito importante, mas pode não ser suficiente para seus propósitos. Se você pretende parar por aqui, tudo bem. Para realizar a análise dinâmica, ou seja, para efetivamente executar o malware, você precisa ir um pouco além…

 

Hands-on Fase 2

O MobSF é uma ferramenta completa. Ele fornece um OVA com um emulador Android embutido. Você precisa apenas importá-lo à sua biblioteca de VMs Virtualbox.  O procedimento é detalhado aqui (a página Wiki do produto).  Este download é de aproximadamente 1,2 GB.

Opcionalmente, você pode desejar usar o emulador ARM no lugar do OVA, visto que esta segunda opção permite a análise de mais aplicações. Os contras são que você precisará baixar o Android Studio (cerca de 730 MB) e criar um AVD (Android Virtual Device), que demandará outro download de 730 MB. O emulador em si tem 284 MB de tamanho.

Não escolhi esta opção, pois isto me faria precisar trabalhar com outro software. Assim, importei o OVA e o executei no Virtualbox.  A primeira tela é apresentada na Figura 5. Pode ser que você precise fornecer a senha:  1234.

Figura 5: emulador Android do MobSF (tela inicial)

A partir daqui, a primeira coisa a se fazer é checar se existe alguma atualização para os componentes internos da ferramenta.  Abra a aplicação “Xposed Installer”, clique na opção “Download” e aguarde alguns instantes.  Os downloads disponíveis aparecerão logo abaixo dos textos descrevendo o que cada componente faz.  No meu laboratório, o “RootCloak” sofreu atualização.

Depois disso, volte uma tela e clique em “Framework”.  Você verá a tela da Figura 6.  Agora, você deve clicar em “Install/Update”, para garantir que o emulador executará qualquer aplicação sendo analisada.

Figura 6: Xposed Installer Framework

Depois disso, a VM automaticamente reiniciará.  Quando ela iniciar, desligue-a imediatamente e crie um snapshot. Isto é crucial, pois permitirá que você restaure o estado inicial da VM após alguma análise.  Agora, você está pronto!

 

Análise Estática

Se o MobSF estiver executando diretamente em sua máquina Linux, acesse a interface gráfica em http://localhost:8000.  Se estiver executando na forma de container com uma VM, acesse em http://<endereço da VM>:8000.  A Figura 7 apresenta a tela inicial.

Figura 7: tela inicial do MobSF

O processo começa clicando na área cinza (ou no botão abaixo dela) e enviando o arquivo do malware.  Você pode verificar os resultados de todas análises que realizou clicando no link “Recent Scans”.  Mas, onde conseguir algum malware?!

Há alguns repositórios muito bons na Internet.  Apenas para citar alguns:

Você vai encontrar muitos outros aqui. Alguns deles requerem a criação de uma conta. Outros só permitem o acesso após fazer contato com o administrador.

Obtive algumas amostras neste site.  Depois de clonar o repositório (ou baixar um conjunto desejado), procure por arquivos com a extensão .APK.  Eles podem estar localizados dentro de um .ZIP.  Percebi que muitas fontes protegem o ZIP com a senha “infected“.

Para meu teste, escolhi um trojan bancário descoberto pela Trend Micro.  Você pode encontrar informação sobre ele facilmente na Internet.  O upload do arquivo e a correspondente análise estática podem ser acompanhados em tempo real através da console do container.  O MobSF descompila o byte code Java usando o CFR.  Em algumas situações, você pode também ver um processo de converter arquivos . DEX (dalvik) para .JAR.

Depois que a análise estática termina, uma tela de sumário é mostrada, como a da Figura 8.

Figura 8: tela de sumário da análise do trojan

O ícone da aplicação aparece no canto superior esquerdo. Além disto, são mostrados nomes e hashes (úteis para compara com indicadores de comprometimento – IoCs – que podem ser encontrados em fóruns e grupos). Outras informações específicas são apresentadas nos retângulos coloridos:

  • Activities:  telas que permitem interação com o usuário;
  • Services:  componentes que executam tarefas em background e não mostram qualquer interface;
  • Receivers:  códigos que permitem à aplicação receber conteúdo, mesmo que não esteja em execução;
  • Providers:  software auxiliar que cria uma interface entre a aplicação e outras aplicações em execução no telefone.  Úteis para compartilhar informações.

Você pode ver detalhes de cada componente clicando no retângulo correspondente.  Rolando a tela para baixo, você verá mais informações, como: certificado digital, permissões e o arquivo de manifesto.  Cada parte da análise estática também pode ser vista ao se clicar na seção correspondente da coluna à esquerda.

Como exemplo, tomemos o bloco “permissões” mostra que muitas perigosas são requeridas, tais como:  CHANGE_NETWORK_STATE, WRITE_SMS, CHANGE_WIFI_STATE, e mais algumas.  Em outras palavras, a análise do manifesto igualmente mostra tópicos de alta severidade que merecem atenção.  Como você já deve saber, qualquer aplicação Android deve prover um arquivo de manifesto (no formato XML).  Este arquivo é responsável por muitas coisas internas, como:  fornecer o nome do pacote Java, declarar permissões necessárias, determinar os processos que suportam os componentes da aplicação, e outras.  Veja esta parte também, pois ela pode revelar características importantes do malware.  Este em particular possui alguns domínios russos que foram ofuscados.  Bastante suspeito…

Se você quiser verificar o código da aplicação (Java ou Smali), use os botões correspondentes.  Smali é como um formato intermediário entre DEX/Davik e o código-fonte em Java.  Funciona como uma visão arquitetural da aplicação.

 

Análise Dinâmica

Aqui, é onde a brincadeira começa.  Com esta parte do MobSF, você instalará a aplicação real dentro de um dispositivo Android (sim, o MobSF permite comunicar diretamente com um telefone) ou na VM com o Emulador.  Assim, de volta à tela de sumário da análise estática, clique no botão verde “Start Dynamic Analysis”.  Antes, verifique que o emulador está em execução, ou seu telefone está conectado ao computador.

Figura 9: tela inicial da Análise Dinâmica

A interação é trivial:  clique no único botão disponível e assista ao “show”.  A primeira tela do malware pede permissão de administrador, como apresentado na Figura 10:

Figura 10: troja solicitando permissão de admin

Como alertado na tela de sumário da análise estática, o ícone do trojan é oculto no Android, e você pode conferir isso navegando através do diretório de aplicações.  De volta à console web, clique no botão “Start Activity Tester”.  Isto permitirá ao MobSF ir ainda mais fundo na análise do código, observando as atividades executadas.  Nesta tela de análise, você também pode inserir comandos adb, uma vez que a ferramenta incorpora um  Android Debugger.

Quando tiver acabado aqui, clique em “Finish”, e aguarde pela coleta e processamento dos dados.  Como observação, no meu emulador, o malware transformou o telefone numa tela preta, sem qualquer resposta.

A tela de relatório da análise mostra muitas possibilidades de verificações e os resultados correspondentes:

Figura 11: resultado da Análise Dinâmica

Cada botão revela logs específicos que foram coletados pelo MobSF.  Um dump inteiro do telefone também pode ser visto.  Todos os dados da aplicação podem ser descarregados no formato tar usando o último botão.

Se a aplicação tentar gerar qualquer tráfego web, este tráfego pode sofrer fuzzing usando o botão correspondente. Se você não sabe o que é fuzzing, verifique este artigo.  No entanto, como pude observar diversas vezes usando o emulador do OVA, nenhuma aplicação conseguiu acesso à web.

Ainda na tela de sumário (veja a Figura 8), se você descer, verá os resultados do Activity Tester (caso tenha usado).  Confirmei a tela preta da minha análise em diversos códigos da aplicação.

 

Indo além – A API

O MobSF prova ser uma ferramenta fantástica de análise de malware ao fornecer uma API.  Através de uma interface RESTful, você pode executar quatro operações:

  • Enviar uma amostra de malware;
  • Requisitar o scan de uma amostra;
  • Baixar o arquivo de relatório da análise estática;
  • Solicitar a exclusão dos dados.

Portanto, se você tiver um conjunto de arquivos de malware e gostaria de processá-los na forma de um script, isso é possível através do uso do utilitário curl, conforme mostrado na página de API (clique no link “API Docs”).  Nesta página a primeira coisa à qual você deve prestar atenção é a chave de API.  Ela muda toda vez que você reinicia o MobSF.

Escrevi o código Python a seguir para automatizar o processamento destas operações. Este programa presume que todos os arquivos de malware se encontram no mesmo diretório/folder que o próprio script.  Sinta-se à vontade para alterar o código de acordo com sua necessidade.  Na verdade, ele também ficará disponível no meu repositório GitHub.

#!/usr/bin/env python

import pycurl, json, glob
from io import BytesIO

'''
Script to automate MobSF's API operations.  This code currently accepts no arguments.
All malware files (.APK extension) must be put inside the same directory as the code itself.
The user has the option to not delete scans.  This allows him to further check results
on the web interface.
'''

# Building the Base URL.
base = input("Type the full URL of MobSF, including port. (No trailing slash): ").strip()
base += "/api/v1/"

key = input("Type the current API key: ").strip()
delete = input("DELETE the scans? Only y or Y will be considered a positive answer: ").strip()
delete = delete.upper()

# Operations to make with the API
operations = ["upload", "scan", "download_pdf"]
if delete == "Y":
  operations.append("delete_scan")

# Listing .API files located in the same directory.
files = sorted(glob.glob("*.apk"))
total_files = len(files)
position = 1
print()

for file in files:
  print("Processing file %d of %d..." % (position, total_files))
  for operation in operations:
    buffer = BytesIO()
    url = base + operation
    c = pycurl.Curl()
    c.setopt(c.URL, url)
    c.setopt(c.POST, 1)
    c.setopt(pycurl.HTTPHEADER, ['Authorization:' + key])
    c.setopt(c.WRITEDATA, buffer)
    print("Running %s of %s file..." % (operation, file))
    if operation == "upload":
      c.setopt(c.HTTPPOST, [("file", (c.FORM_FILE, file))])
      c.perform()
      body = buffer.getvalue()
      result = json.loads(body.decode('iso-8859-1'))
      code = result["hash"]
    elif operation == "scan":
      c.setopt(c.POSTFIELDS, "scan_type=apk&file_name=" + file + "&hash=" + code)
      c.perform()
    elif operation == "download_pdf":
      file_pdf = file.replace("apk", "pdf")
      c.setopt(c.POSTFIELDS, "hash=" + code + "&scan_type=apk")
      c.perform()
      body = buffer.getvalue()
      f = open(file_pdf, "wb")
      f.write(body)
      f.close()
    elif operation == "delete_scan":
      c.setopt(c.POSTFIELDS, "hash=" + code)
      c.perform()
    c.close()
  print("------------------------------------------------------------------")
  position += 1
print("End of Processing.")

Cada operação retorna uma resposta JSON.  O código captura todas as respostas para evitar bagunçar a tela.  Testei alguns malwares e os arquivos de relatório correspondentes ficaram entre 4 e 10 páginas.  As saídas são praticamente as mesmas daquelas obtidas via GUI.

 

Conclusão

Para os propósitos deste artigo, foquei os malwares apenas na plataforma Android.  A GUI rápida e simples de usar do MobSF torna a experiência de análise de malwares muito tranquila.  A análise estática é bastante poderosa, e a análise dinâmica é extremamente útil para inspecionar o comportamento real da aplicação suspeita.

Seria interessante melhorar o emulador OVA para permitir a execução de malwares mais recentes, e uma versão mais atualizada do Android.  A ferramenta, no entanto, permite a integração com outros emuladores, como o Genymotion.

Abraço e até o próximo post! 😉

Compartilhe:

Maurício Harley

Olá! Meu nome é Maurício Harley. Tenho mais de 20 anos de experiência em Tecnologia da Informação. Durante minha carreira, trabalhei em setores diversos, como suporte a usuário final, manutenção de hardware, instalação e suporte a redes de computadores, programação, projetos avançados em Data Center, Cloud Computing, Cyber Security e Redes, incluindo Service Providers.

0 comentário

Deixe um comentário

Avatar placeholder

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Translate

You cannot copy content of this page.