Oldboot.B: Bootkit Trojan ataca plataforma Android

Em abril a PSafe, desenvolvedora do dfndr, principal aplicativo antivírus do Brasil, detectou o primeiro Bootkit Trojan da plataforma Android, o Oldboot.A.

Também foi a primeira companhia de segurança digital a lançar uma ferramenta de detecção e remoção desse trojan. Nos últimos dias a PSafe descobriu uma nova variante desse malware, nomeada de Oldboot.B

O que faz

Esse é um malware poderoso, pois consegue instalar apps sem o conhecimento do usuário e inserir módulos maliciosos no sistema. Além disso, ele também modifica a página inicial do navegador e impede desinstalação de apps. No entanto, a pior atividade dele é desabilitar e/ou desinstalar programas de antivírus, deixando o aparelho mais vulnerável ainda.

O Oldboot.B é bem parecido com seu antecessor, tanto no código quanto na funcionalidade, como você pode ver na imagem abaixo. Do lado esquerdo é representado o Oldboot.A; o imei_chk executa, automaticamente, durante a inicialização do sistema os outros dois arquivos – GoogleKernel.apk e libgooglekernel.so. Ele consegue isso ao registrar um serviço no init.rc script e colar os dois arquivos maliciosos.

Do lado direito está o mais recente, o Oldboot.B, que, assim como o outro, tem um ponto de início no init.rc script, porém, dessa vez, são mais componentes como ponto de início. Esse trojan coloca ele mesmo no initrd e introduz um ponto de entrada no init.rc script, para em seguida acessar o boot.img do Android.

O que tem de diferente

Especialmente, alguns binários ELF da nova variante têm seu código executável e sequências de caracteres criptografados, e o arquivo de configuração baixado do servidor C&C está oculto usando esteganografia. Isso significa que ele tem a habilidade de se manter fora do radar dos antivírus. O Oldboot é muito bem organizado, onde cada componente deleta seus arquivos do disco após serem executados, ficando o registro somente na memória do processo.

Essa família de trojan foi desenvolvida por programadores profissionais, promovido por empresas comerciais e tem evoluído constantemente, mas a PSafe têm uma ferramenta para deletá-lo efetivamente.

Como funciona

De acordo com a funcionalidade, o Oldboot.B pode ser dividido em 4 partes:

Parte 1 – boot_tst

A principal funcionalidade é, remotamente, inserir códigos no ‘system_server’ do sistema do Android, continuamente ouvir a comunicação do sistema e executar os comandos enviados. Abaixo seguem os arquivos relevantes:

1. /init.rc, o script de configuração para o booting do sistema Android que foi modificado pelo Oldboot
2. /sbin/boot_tst, um arquivo ELF executável para arquitetura ARM
3. /data/system/usagestats/leecore.so, um arquivo ELF shared library
4. /data/system/usagestats/leejrc.so, um arquivo ELF shared library
5. /data/system/usagestats/leejar.jar, um módulo JAR
6. /data/system/usagestats/leejar.dex , o arquivo dex do Jar acima

Parte 2 – /sbin/adb_server

O script pm do sistema do Android é substituído por esse arquivo para permitir a função de Anti-desinstalação.

Parte 3 – meta_chk

A principal função é atualizar o arquivo de configuração, baixar e instalar apps em segundo plano. Seguem abaixo os arquivos relevantes:

1. /init.rc, o script de configuração para o booting do sistema Android que foi modificado pelo Oldboot
2. /sbin/meta_chk, (v1) um arquivo ELF executável para ARM arquitetura
3. /sbin/meta_chk, (v2) um arquivo ELF executável para ARM arquitetura
4. /sbin/adb_meta, um arquivo ELF executável para ARM arquitetura
5. /system/etc/.gprs.xml, arquivo de configuração criptografada

Parte 4 – agentsysline

Esse arquivo é escrito em C++ com arquitetura complexa, rodando em segundo plano para receber comandos enviados. Ele pode desinstalar o antivírus, deletar arquivos específicos e habilitar ou desabilitar a conexão com a internet. Abaixo seguem os arquivos relevantes:

1. /init.rc, o script de configuração para o booting do sistema Android que foi modificado pelo Oldboot
2. /sbin/agentsysline, um arquivo ELF executável para arquitetura ARM

Aprofundando o Oldboot.B

Parte 1 – boot_tst

Parecido com outros membros da família Oldboot, o arquivo boot_tst é executado automaticamente devido a entrada de inicialização adicionada no script de configuração de booting do sistema do Android. As linhas abaixo serão adicionadas ao arquivo init.rc:

Imagem.

Esse é o fluxo do boot_tst:

Imagem.

Como mostrado acima, ele pode ser dividido em duas partes, uma parte do código é executado no processo boot_tst enquanto que a outra, o código injetado, no processo system_server. Uma vez que a inserção é completada, as duas partes do código se comunicam via socket.

Entenda o fluxo de execução do código no processo boot_tst:

1. Extrai o arquivo ELF embedado para o arquivo /data/system/usagestats/leecore.so e o carrega para a memória. Este arquivo será deletado após carregado na memória e o usuário não conseguirá acha-lo no sistema.
2. A função main da biblioteca leecore.so é chamada.
3. Extrai a outra biblioteca para o arquivo /data/system/usagestats/leejrc.so
4. Injeta o arquivo /data/system/usagestats/leejrc.so no processo system_server do sistema Android.
5. Captura o número da porta utilizada pelo socket – adb6 – registrado no script init.rc, ouvir a comunicação desse socket continuamente, executar a ação apropriada de acordo com as instruções enviadas e retornar o resultado da operação, conforme o código abaixo:

Os comandos recebidos do socket adb6 podem ser divididos em dois grupos; a estrutura relevante dos dados é apresentada abaixo:

Os dois grupos de comandos são:

1. cmds recebe um array de comandos e, em seguida, executa-os com privilégios de root
2. netcmd recebe comandos de controle do módulo leejar.jar no processo system_server para abrir/fechar redes ou adquirir/liberar wakelock etc.

O código do arquivo leecore.so é baseado no código do libgooglekernel.so, do Oldboot. A diferença nesta nova versão é o uso das bibliotecas curl e cJSON para implementar a atualização e parseamento dos arquivos de configuração.

O código injetado no processo system_server começa a ser executado da função hook_thai_jrc_init exportada pelo leejrc.so. Veja o processo principal:

1-Extrai o arquivo jar embedado para /data/system/usagestats/leejar.jar

2-Carrega o leejar.jar no processo system_server através do DexClassLoader

3-Chama o método estático leeJrcInit da classe lee.main.main localizada no arquivo eejar.jar

4-leeJrclnit irá criar um socket local para ouvir na porta 9096, receber comandos enviados do boot_tst e executá-los para em seguida retornar os resultados pelo socket – adb6.

Abaixo seguem os comandos que o processo boot_tst pode enviar para o socket server criado pelo leejar no system_server.

1. openNetwork
2. closeNetwork
3. getVerCode
4. getCurNetworkType
5. getAppInstallPath
6. getSDCardAvaildSize
7. getSystemAvaildSize
8. isSafeMode
9. unzip
10. getSysInfo
11. sendLauncherMsg
12. acquireWakeLock
13. releaseWakeLock

Parte 2 – /sbin/adb_server

O arquivo meta_chk também altera o script init.rc para adicionar um outro item de inicialização. A maior diferença entre as duas versões do meta_chk é que uma registra um socket com nome adb2 no script init.rc e escuta esse socket no código; já a outra, irá criar um socket server e escutar a porta local 23332. Veja o fluxo de execução do meta_chk:

1-Inicia o UpdateNoService usando o comando am.

2-Checa se o caminho de execução é /sbin/meta_chk; se não for, não fará nada malicioso.

3-Deleta o /sbin/meta_chk para que nem o usuário nem o antivírus consigam ler e escrever esse arquivo, evitando, efetivamente, de ser detectado e limpo, porque não existe arquivo, na verdade. Como o arquivo meta_chk está localizado no ramdisk, uma vez deletado, não irá impedir que o Trojan seja executado, além de permitir que ele continue rodando, automaticamente, no próximo boot. Esse é o truque do malware para ficar invisível.

4-Extrair um arquivo ZIP para /system/lib/libkey.so, usar a biblioteca open source – MinZip – para extrair o arquivo axel e copiá-lo no /sbin/adb_meta para, em seguida, dar permissão de executável para ele. O /sbin/adb_meta (axel) é uma ferramenta de download open source HTTP/FTP que suporta múltiplas conexões, sendo similar ao wget/curl, usado pelo meta_chk para baixar arquivos do servidor.

5-Carregar o arquivo de configuração /system/etc/.gprs.xml para usar o código subsequente. O /system/etc/.gprs.xml é um arquivo criptografado de configuração, com 12,508 bytes, que tem um formato personalizado e contém uma grande quantidade de campos, sendo o ‘AZD\0’ o cabeçalho do arquivo. Este arquivo de configuração tem os seguintes campos:

• URL do C&C utilizado pelo Trojan
• Uma lista de package names dos antivírus para serem desabilitados
• O package name de alguns aplicativos a serem promovidos e o path local para download
• Flag para indicar quando se o cache do browser deve ser limpo
• Flag para indicar se a homepage padrão do browser deve ser alterada e a URL que deverá ser configurada como padrão
• Lista de comandos para executar
• A última vez que a atividade maliciosa foi executada

6-Ler o conteúdo do arquivo /system/etc/hosts e checar se o nome de algum domínio poderia ser utilizado para baixar apps hijacked, como zkl90.com, 177.net, 188.net, etc. Uma vez com o app que sequestra dados, o meta_chk irá substituir todo o conteúdo do arquivo hosts com o conteúdo padrão do arquivo de hosts (127.0.01 localhost) para garantir que os downloads subsequentes possam ser executados corretamente.

7-Baixar um arquivo com vírus em /system;lib;libdowntemp.so usando a ferramenta adb_meta (axel), renomear como /system/bin/chk e torna-lo executável para finalmente rodar o arquivo /system/bin/chk.

8-Baixar o arquivo de configuração e substituir o arquivo /systema/etc/.gprs.xml com isso o conteúdo baixado.

9-Baixar o APK e instalá-lo em segundo plano. Para garantir que o app possa ser baixado e instalado com sucesso, antes de iniciar a instalação silenciosa, o arquivo meta_chk usa o comando ‘pm disable’ para, temporariamente, desativar o antivírus. Após a instalação do app será utilizado o comando ‘pm enable’ para ativar o antivírus. Enquanto isso, o meta_chk usará a ferramenta sqlite para modificar, diretamente, a base de dados da configuração de apps do Android – settings.db – para permitir a a instalação de apps de fontes desconhecidas.

10-Cria uma thread que irá escutar o socket e executar comandos enviados por outros programas. Os comandos recebidos pelo meta_chk podem ser divididos em cinco grupos. O ‘opengprs’ e o ‘closegprs’ podem ligar e desligar a conexão com a internet; O ‘setdb’ pode diretamente modificar a base de dados para modificar várias configurações na parte de ‘Configuração’ do Android; O ‘check?c=’ e o ‘zxly2?=c’ podem executar comandos arbitrários com privilégios root e retornar os resultados.

É interessante que o meta_chk verifica a assinatura RSA do App cliente que está conectando ao socket server. Ele executará o comando somente se a assinatura tiver o mesmo conteúdo do dado hard-coded no meta_chk. Alguns antivírus ou ferramentas de remoção utilizam alguma funcionalidade que o Trojan fornece para exluí-lo, e esse mecanismo de autenticação torna este método ineficaz.

Parte 3 – meta_chk

O arquivo do sistema – /system/bin/pm – será substituído pelo adb_server para hookear o comando pm uninstall. Se esse arquivo percebe que um dos apps que está sendo desinstalado, pelo usuário ou por alguma ferramenta de remoção, é um dos que o Oldboot precisa, o adb_server não desinstala, mas envia uma mensagem falsa de ‘Sucesso’. É assim que funciona a função de anti-desinstalação.

O adb_server existe no ramdisk do bootimg assim como outros membros da família Oldboot. Diferente dos outros, esse não tem um ponto de inicialização no script init.rc. O meta_chk (descrito abaixo) irá copiar ele e substituir o /system/bin/pm por ele. O processo de substituição é mostrado abaixo:

Quando o usuário ou um programa executa o comando pm, na verdade é o adb_server que é executado. Após iniciado, o adb_server precisa de uma pequena inicialização, como configurar o uid e o gid para root, checando a variável de ambiente LD_LIBRARY_PATH e se o processo pai e shell.

Em seguida, o adb_server checará se o sub-comando é ‘desinstalar’. Se for, ele obterá o próximo parâmetro, por exemplo, do nome do pacote que deseja desinstalar, e irá compará-lo com o item da lista de nome do pacote built-in, um por um; Se o nome do pacote de desinstalação for achado na lista de nome do pacote built-in, ele irá retornar diretamente e mostrar uma falsa mensagem de ‘Sucesso’.

Parte 4 – agentsysline

Dependendo dos parâmetros de input, o agentsysline pode fazer diferentes coisas. Ele pode agir como um programa SU ao chamar o shell para executar vários comandos com permissão Root ( os autores do Trojan não implementaram essa parte da função totalmente, então não pode ser usada corretamente); O agentsysline também pode rodar como daemon service, recebendo os comandos enviados do servidor remoto ou programas locais e executando eles em segundo plano.

O agentsysline é um programa multi-thread escrito em C++ com a função principal encapsulada utilizando classes C++. Também tem uma boa arquitetura, mesmo com no mínimo 15 threads criadas pelo próprio agentesysline, a sincronização de tópicos é muito boa. Quanto ao código, podemos dizer que o autor do Trojan é desenvolvedor sênior de Linux.

A função principal do agentsysline está acondicionada em 6 classes C++, veja:

1. O Frame classe single instance, controlando a execução do programa
2. O NetManager e o TcpSession controlam a conexão de rede
3. SocketCmdManager cria um canal e envia/recebe dados, além de enviar comandos recebidos para o CmdHandler para executar
4. CmdHandler recebe os comandos do SocketCmdManager, analisa e cria novas threads para executarem esses comandos
5. Logger implementa a funcionalidade de registro

A relação entre essas classes de C++ é apresentada abaixo:

O fluxo de execução do agentsysline:

1. Inicialização; define o resource limit e signal handler e escreve o seu próprio PID no arquivo /data/system/sys.server.id
2. Chama SocketCmdManager para criar um servidor socket e escuta continuamente
3. Chama NetManager para conectar à internet e atualizar o arquivo de configuração
4. Executa um loop infinito – chama SocketCmdManager para receber comandos e executá-los (as instruções suportadas são apresentadas abaixo) – a menos que um sinal especial seja recebido e a flag bTerminate seja definida para 1
5. Chama cada classe destrutora e sair

Veja o código desassemblado:

A defesa e as tendências

Comparado ao Oldboot.A (imei_chk), a nova variação da família Oldboot teve diversas mudanças, em especial na defesa contra antivírus, proteção anti-debugging e ferramentas de análise automática, que são particularmente importantes assim como as seguintes:

1. A habilidade de se esconder no sistema do Trojan Oldboot é muito aprimorada. Por um lado, após iniciado, o meta_chk irá deletar ele mesmo no arquivo do sistema, deixando somente o processo em si. Como sabemos, os antivírus populares não suportam o escaneamento de memória na plataforma Android, não sendo possível detectar ou deletar o Trojan Oldboot que reside na memória. Por outro lado, o boot_tst usa a técnica de injeção remota para inserir um arquivo SO e um JAR no processo do system_server. Como a técnica de injeção na plataforma Android já está madura, pode-se esperar que os autores utilizem essas duas técnicas em conjunto, criando um “no process, no file” Trojan. Talvez este Trojan já até exista, mas ainda precisamos identifica-lo.
2. O código do arquivo ELF do Oldboot Trojan não é claro, mas criptografado, e o código descritivo no início da principal rotina irá decodificar toda a criptografia e executá-la. Enquanto isso, quase todas as strings que o programa utiliza são criptografada A configuração também é criptografada. O uso extensivo dessa técnica dificulta o processo de análise, além de aumentar o tempo necessário para analisa-lo.
3. O Trojan usa alguns truques contra a análise dinâmica, como adicionar alguns códigos sem sentido e acionar aleatoriamente alguns procedimentos.
4. O Oldboot checa alguns atributos do ambiente na hora de rodar. Por exemplo, o meta_chk checa o path na hora de rodar e fecha se o path é esperado. Ele também checa o SIM card e não realiza determinado procedimento se não tiver um SIM card. Devido a essas verificações, o sandbox ou o emulador podem não obter resultados úteis, além de um falso positivo.
5. O Trojan verifica se existe um antivírus e pode desinstalá-lo antes de fazer qualquer coisa maliciosa. Ou ele pode pará-lo utilizando o comando ‘pm disable’ antes de instalar um app que ele deseja e, em seguida, reativá-lo utilizando o comando ‘pm enable’. Claro que a segunda opção mantém o usuário sem saber, sendo mais sutil.
6. O Oldboot utiliza a técnica Esteganografia para esconder o arquivo de configuração baixado do servidor C&C. Esteganografia é uma técnica poderosa que esconde informações em um formato e jeito que dificultada que seja detectada por quem não saiba que ele está ali. Foi descoberto que o meta_chk irá baixar um arquivo do servidor C&C. Pela aparência, o arquivo é uma imagem. No entanto, após algumas análises, descobriu-se que a configuração do meta_chk está escondida nesta imagem, que contém um comando que irá executar o meta_chk e outra informação.
7. A arquitetura do Trojan é muito complexa, com um alto nível de flexibilidade e muitos procedimentos podem ser configurados e controlados pelo servidor C&C do Trojan. O arquivo de configuração meta_chk claramente prova este ponto. Ele tem 12,508 bytes e quase todo byte tem um significado diferente. Completar a análise de um Trojan controlado remotamente é uma tarefa difícil. Como o comando emitido pelo servidor C&C é diferente, o procedimento desencadeado pode ser diferente.

A análise de correlação

O nome do domínio que o meta_chk irá se conectar é az.o65.org (o servidor está desativado no momento). Através de algumas pesquisas sobre esse domínio percebeu-se que o IP dele é 61.160.248.67. Também se descobriu que existem muitos domínios com nome similar no mesmo servidor. Através do cache do motor de busca percebeu-se que todos têm um string ‘ZKL90’ como conteúdo da homepage. Por isso é certo que todos esses domínios são do servidor do meta_chk. O meta_chk, como um único componente da família Oldboot, tem inúmeros nomes de domínio. Um nome de domínio requer um recurso humano e financeiro considerável, por isso acredita-se que o tamanho do time por trás deste Trojan é grande.

Soluções

A PSafe está liberando a primeira ferramenta de detecção e remoção do Oldboot no mundo. Você pode baixar no link abaixo:

https://msoftdl.360.cn/mobilesafe/shouji360/360safesis/OldbootKiller_v2.apk

Essa ferramenta irá escanear profundamente o Android para encontrar o Oldboot e suas variáveis. Foi desenvolvido um novo método de verificação e exclusão que pode, efetivamente, limpar os aparelhos Android mais populares do Oldboot.

Se o seu aparelho não é suportado no momento, veja as sugestões a seguir:

1. Verifique com frequência a atualização das ferramentas, pois irá contemplar mais modelos em breve;
2. Você pode tentar restaurar a configuração de fábrica. Após isso o Oldboot deverá ter sido removido;

Discussão

Como o primeiro Bootkit da plataforma Android, o Oldboot tem um valor significativo. Na guerra entre Antivírus e Trojans, ele traz um novo campo de batalha e inicia uma nova era.

A popularização da internet de alta velocidade representa um importante papel no crescimento dos smartphones. A plataforma Android está presente na maior parte dos celulares, estando conectado à internet a maior parte do tempo. Os autores de Trojan perceberam isso e estão pondo mais e mais informação na rede, sendo que esses apps ou arquivos ELF instalados nos aparelhos só realizam funções básicas, como mexer na configuração de internet ou executar comando com privilégio ROOT etc. O que o Trojan realmente faz é controlar o aparelho pelo servidor C&C dele. A família do Oldboot Trojan é a mais significativa demonstração dessa tendência.

Baseado no Trojan descoberto, a família Oldboot é usada principalmente para promover apps altamente flexíveis e configuráveis. Isso pode ser provado nos aspectos a seguir:

1. Primeiro de tudo, o número de domínios e servidores onde o arquivo de configuração está armazenado é alto e o domínio muda frequentemente para assegurar que Oldboot possa ter as últimas atualizações necessárias para promoção ou contra a defesa do antivírus;
2. Segundo, o arquivo de configuração é extremamente complexo e muitas coisas são configuráveis, incluindo o link de download do app, o caminho de armazenamento após o download e nome de pacote etc;
3. Terceiro, os autores levam em conta inúmeras circunstancias, por exemplo, se o endereço do servidor foi sequestrado no arquivo host ou se a defesa contra antivírus está ativa ou se o usuário deseja desinstalar o app utilizado para promover o ‘pm uninstall’ etc; e claro, o Oldboot usa a tecnologia bootkit podendo formatar as configurações do Android e, automaticamente, começar com o Android usando o sistema como um serviço nativo.

Com base nos pontos acima, podemos dizer que o Oldboot tem feito a ‘melhor’ abordagem de aplicativos maliciosos.

O Oldboot é, essencialmente, um Trojan Bootkit que pode controlar o telefone Android remotamente. Dependendo dos comandos enviados do servidor C&C, ele pode fazer diferentes coisas, como enviar mensagens SMS falsas ou ataques phishing, e por ai vai.

Feito para obter lucro, ele muda rapidamente para reagir a qualquer situação. A PSafe continuará acompanhando o desenvolvimento desse tipo de ataque e fornecendo soluções de segurança.