{"id":12787,"date":"2015-05-20T19:00:11","date_gmt":"2015-05-20T22:00:11","guid":{"rendered":"https:\/\/www.psafe.com\/blog\/?p=12787"},"modified":"2022-05-18T11:00:47","modified_gmt":"2022-05-18T14:00:47","slug":"oldboot-b-trojan-ataca-plataforma-android","status":"publish","type":"post","link":"https:\/\/www.psafe.com\/blog\/oldboot-b-trojan-ataca-plataforma-android\/","title":{"rendered":"Oldboot.B: Bootkit Trojan ataca plataforma Android"},"content":{"rendered":"\n

Em abril a PSafe, desenvolvedora do dfndr, principal aplicativo antiv\u00edrus do Brasil, detectou o primeiro Bootkit Trojan da plataforma Android, o Oldboot.A. <\/p>\n\n\n\n

Tamb\u00e9m foi a primeira companhia de seguran\u00e7a digital a lan\u00e7ar uma ferramenta de detec\u00e7\u00e3o e remo\u00e7\u00e3o desse trojan. Nos \u00faltimos dias a PSafe descobriu uma nova variante desse malware, nomeada de Oldboot.B<\/p>\n\n\n\n

O que faz<\/h2>\n\n\n\n

Esse \u00e9 um malware poderoso, pois consegue instalar apps sem o conhecimento do usu\u00e1rio e inserir m\u00f3dulos maliciosos no sistema. Al\u00e9m disso, ele tamb\u00e9m modifica a p\u00e1gina inicial do navegador e impede desinstala\u00e7\u00e3o de apps. No entanto, a pior atividade dele \u00e9 desabilitar e\/ou desinstalar programas de antiv\u00edrus, deixando o aparelho mais vulner\u00e1vel ainda.<\/p>\n\n\n\n

O Oldboot.B \u00e9 bem parecido com seu antecessor, tanto no c\u00f3digo quanto na funcionalidade, como voc\u00ea pode ver na imagem abaixo. Do lado esquerdo \u00e9 representado o Oldboot.A; o imei_chk<\/em> executa, automaticamente, durante a inicializa\u00e7\u00e3o do sistema os outros dois arquivos \u2013 GoogleKernel.apk<\/em> e libgooglekernel.so<\/em>. Ele consegue isso ao registrar um servi\u00e7o no init.rc<\/em> script e colar os dois arquivos maliciosos.<\/p>\n\n\n\n

Do lado direito est\u00e1 o mais recente, o Oldboot.B, que, assim como o outro, tem um ponto de in\u00edcio no init.rc<\/em> script, por\u00e9m, dessa vez, s\u00e3o mais componentes como ponto de in\u00edcio. Esse trojan coloca ele mesmo no initrd<\/em> e introduz um ponto de entrada no init.rc<\/em> script, para em seguida acessar o boot.img<\/em> do Android.<\/p>\n\n\n\n

O que tem de diferente<\/h2>\n\n\n\n

Especialmente, alguns bin\u00e1rios ELF da nova variante t\u00eam seu c\u00f3digo execut\u00e1vel e sequ\u00eancias de caracteres criptografados, e o arquivo de configura\u00e7\u00e3o baixado do servidor C&C est\u00e1 oculto usando esteganografia. Isso significa que ele tem a habilidade de se manter fora do radar dos antiv\u00edrus. O Oldboot \u00e9 muito bem organizado, onde cada componente deleta seus arquivos do disco ap\u00f3s serem executados, ficando o registro somente na mem\u00f3ria do processo.<\/p>\n\n\n\n

Essa fam\u00edlia de trojan foi desenvolvida por programadores profissionais, promovido por empresas comerciais e tem evolu\u00eddo constantemente, mas a PSafe t\u00eam uma ferramenta para delet\u00e1-lo efetivamente.<\/p>\n\n\n\n

Como funciona<\/h2>\n\n\n\n

De acordo com a funcionalidade, o Oldboot.B pode ser dividido em 4 partes:<\/p>\n\n\n\n

Parte 1 \u2013 boot_tst<\/em><\/h4>\n\n\n\n

A principal funcionalidade \u00e9, remotamente, inserir c\u00f3digos no \u2018system_server\u2019<\/em> do sistema do Android, continuamente ouvir a comunica\u00e7\u00e3o do sistema e executar os comandos enviados. Abaixo seguem os arquivos relevantes:<\/p>\n\n\n\n

  1. \/init.rc<\/em>, o script de configura\u00e7\u00e3o para o booting do sistema Android que foi modificado pelo Oldboot<\/li>
  2. \/sbin\/boot_tst<\/em>, um arquivo ELF execut\u00e1vel para arquitetura ARM<\/li>
  3. \/data\/system\/usagestats\/leecore.so<\/em>, um arquivo ELF shared library<\/li>
  4. \/data\/system\/usagestats\/leejrc.so<\/em>, um arquivo ELF shared library<\/li>
  5. \/data\/system\/usagestats\/leejar.jar<\/em>, um m\u00f3dulo JAR<\/li>
  6. \/data\/system\/usagestats\/leejar.dex<\/em> , o arquivo dex do Jar acima<\/li><\/ol>\n\n\n\n

    Parte 2 – \/sbin\/adb_server<\/em><\/h4>\n\n\n\n

    O script pm do sistema do Android \u00e9 substitu\u00eddo por esse arquivo para permitir a fun\u00e7\u00e3o de Anti-desinstala\u00e7\u00e3o.<\/p>\n\n\n\n

    Parte 3 \u2013 meta_chk<\/em><\/h4>\n\n\n\n

    A principal fun\u00e7\u00e3o \u00e9 atualizar o arquivo de configura\u00e7\u00e3o, baixar e instalar apps em segundo plano. Seguem abaixo os arquivos relevantes:<\/p>\n\n\n\n

    1. \/init.rc<\/em>, o script de configura\u00e7\u00e3o para o booting do sistema Android que foi modificado pelo Oldboot<\/li>
    2. \/sbin\/meta_chk<\/em>, (v1) um arquivo ELF execut\u00e1vel para ARM arquitetura<\/li>
    3. \/sbin\/meta_chk<\/em>, (v2) um arquivo ELF execut\u00e1vel para ARM arquitetura<\/li>
    4. \/sbin\/adb_meta<\/em>, um arquivo ELF execut\u00e1vel para ARM arquitetura<\/li>
    5. \/system\/etc\/.gprs.xml<\/em>, arquivo de configura\u00e7\u00e3o criptografada<\/li><\/ol>\n\n\n\n

       Parte 4 \u2013 agentsysline<\/em><\/h4>\n\n\n\n

      Esse arquivo \u00e9 escrito em C++ com arquitetura complexa, rodando em segundo plano para receber comandos enviados. Ele pode desinstalar o antiv\u00edrus, deletar arquivos espec\u00edficos e habilitar ou desabilitar a conex\u00e3o com a internet. Abaixo seguem os arquivos relevantes:<\/p>\n\n\n\n

      1. \/init.rc<\/em>, o script de configura\u00e7\u00e3o para o booting do sistema Android que foi modificado pelo Oldboot<\/li>
      2. \/sbin\/agentsysline<\/em>, um arquivo ELF execut\u00e1vel para arquitetura ARM<\/li><\/ol>\n\n\n\n

        Aprofundando o Oldboot.B<\/h3>\n\n\n\n

        Parte 1 \u2013 boot_tst<\/em><\/h4>\n\n\n\n

        Parecido com outros membros da fam\u00edlia Oldboot, o arquivo boot_tst<\/em> \u00e9 executado automaticamente devido a entrada de inicializa\u00e7\u00e3o adicionada no script de configura\u00e7\u00e3o de booting do sistema do Android. As linhas abaixo ser\u00e3o adicionadas ao arquivo init.rc<\/em>:<\/p>\n\n\n\n

        Imagem. <\/p>\n\n\n\n

        Esse \u00e9 o fluxo do boot_tst<\/em>:<\/p>\n\n\n\n

        Imagem. <\/p>\n\n\n\n

        Como mostrado acima, ele pode ser dividido em duas partes, uma parte do c\u00f3digo \u00e9 executado no processo boot_tst<\/em> enquanto que a outra, o c\u00f3digo injetado, no processo system_server<\/em>. Uma vez que a inser\u00e7\u00e3o \u00e9 completada, as duas partes do c\u00f3digo se comunicam via socket.<\/p>\n\n\n\n

        Entenda o fluxo de execu\u00e7\u00e3o do c\u00f3digo no processo boot_tst<\/em>:<\/p>\n\n\n\n

        1. Extrai o arquivo ELF embedado para o arquivo \/data\/system\/usagestats\/leecore.so<\/em> e o carrega para a mem\u00f3ria. Este arquivo ser\u00e1 deletado ap\u00f3s carregado na mem\u00f3ria e o usu\u00e1rio n\u00e3o conseguir\u00e1 acha-lo no sistema.<\/li>
        2. A fun\u00e7\u00e3o main da biblioteca leecore.so<\/em> \u00e9 chamada.<\/li>
        3. Extrai a outra biblioteca para o arquivo \/data\/system\/usagestats\/leejrc.so<\/em><\/li>
        4. Injeta o arquivo \/data\/system\/usagestats\/leejrc<\/em>.so<\/em> no processo system_server<\/em> do sistema Android.<\/li>
        5. Captura o n\u00famero da porta utilizada pelo socket \u2013 adb6 \u2013 registrado no script init.rc<\/em>, ouvir a comunica\u00e7\u00e3o desse socket continuamente, executar a a\u00e7\u00e3o apropriada de acordo com as instru\u00e7\u00f5es enviadas e retornar o resultado da opera\u00e7\u00e3o, conforme o c\u00f3digo abaixo:<\/li><\/ol>\n\n\n\n

          Os comandos recebidos do socket adb6 podem ser divididos em dois grupos; a estrutura relevante dos dados \u00e9 apresentada abaixo:<\/p>\n\n\n\n

          Os dois grupos de comandos s\u00e3o:<\/p>\n\n\n\n

          1. cmds<\/em> recebe um array de comandos e, em seguida, executa-os com privil\u00e9gios de root<\/li>
          2. netcmd<\/em> recebe comandos de controle do m\u00f3dulo leejar.jar<\/em> no processo system_server<\/em> para abrir\/fechar redes ou adquirir\/liberar wakelock etc.<\/li><\/ol>\n\n\n\n

            O c\u00f3digo do arquivo leecore.so<\/em> \u00e9 baseado no c\u00f3digo do libgooglekernel.so<\/em>, do Oldboot. A diferen\u00e7a nesta nova vers\u00e3o \u00e9 o uso das bibliotecas curl e cJSON para implementar a atualiza\u00e7\u00e3o e parseamento dos arquivos de configura\u00e7\u00e3o.<\/p>\n\n\n\n

            O c\u00f3digo injetado no processo system_server<\/em> come\u00e7a a ser executado da fun\u00e7\u00e3o hook_thai_jrc_init<\/em> exportada pelo leejrc.so<\/em>. Veja o processo principal:<\/p>\n\n\n\n

            1-Extrai o arquivo jar embedado para \/data\/system\/usagestats\/leejar.jar<\/em><\/p>\n\n\n\n

            2-Carrega o leejar.jar<\/em> no processo system_server<\/em> atrav\u00e9s do DexClassLoader<\/p>\n\n\n\n

            3-Chama o m\u00e9todo est\u00e1tico leeJrcInit da classe lee.main.main<\/em> localizada no arquivo eejar.jar<\/em><\/p>\n\n\n\n

            4-leeJrclnit ir\u00e1 criar um socket local para ouvir na porta 9096, receber comandos enviados do boot_tst<\/em> e execut\u00e1-los para em seguida retornar os resultados pelo socket \u2013 adb6.<\/p>\n\n\n\n

            Abaixo seguem os comandos que o processo boot_tst<\/em> pode enviar para o socket server criado pelo leejar<\/em> no system_server<\/em>.<\/p>\n\n\n\n

            1. openNetwork<\/li>
            2. closeNetwork<\/li>
            3. getVerCode<\/li>
            4. getCurNetworkType<\/li>
            5. getAppInstallPath<\/li>
            6. getSDCardAvaildSize<\/li>
            7. getSystemAvaildSize<\/li>
            8. isSafeMode<\/li>
            9. unzip<\/li>
            10. getSysInfo<\/li>
            11. sendLauncherMsg<\/li>
            12. acquireWakeLock<\/li>
            13. releaseWakeLock<\/li><\/ol>\n\n\n\n

              Parte 2 – \/sbin\/adb_server<\/em><\/h4>\n\n\n\n

              O arquivo meta_chk<\/em> tamb\u00e9m altera o script init.rc<\/em> para adicionar um outro item de inicializa\u00e7\u00e3o. A maior diferen\u00e7a entre as duas vers\u00f5es do meta_chk<\/em> \u00e9 que uma registra um socket com nome adb2 no script init.rc<\/em> e escuta esse socket no c\u00f3digo; j\u00e1 a outra, ir\u00e1 criar um socket server e escutar a porta local 23332. Veja o fluxo de execu\u00e7\u00e3o do meta_chk<\/em>:<\/p>\n\n\n\n

              1-Inicia o UpdateNoService usando o comando am.<\/p>\n\n\n\n

              2-Checa se o caminho de execu\u00e7\u00e3o \u00e9 \/sbin\/meta_chk<\/em>; se n\u00e3o for, n\u00e3o far\u00e1 nada malicioso.<\/p>\n\n\n\n

              3-Deleta o \/sbin\/meta_chk<\/em> para que nem o usu\u00e1rio nem o antiv\u00edrus consigam ler e escrever esse arquivo, evitando, efetivamente, de ser detectado e limpo, porque n\u00e3o existe arquivo, na verdade. Como o arquivo meta_chk<\/em> est\u00e1 localizado no ramdisk, uma vez deletado, n\u00e3o ir\u00e1 impedir que o Trojan seja executado, al\u00e9m de permitir que ele continue rodando, automaticamente, no pr\u00f3ximo boot. Esse \u00e9 o truque do malware para ficar invis\u00edvel.<\/p>\n\n\n\n

              4-Extrair um arquivo ZIP para \/system\/lib\/libkey.so<\/em>, usar a biblioteca open source \u2013 MinZip \u2013 para extrair o arquivo axel e copi\u00e1-lo no \/sbin\/adb_meta<\/em> para, em seguida, dar permiss\u00e3o de execut\u00e1vel para ele. O \/sbin\/adb_meta<\/em> (axel) \u00e9 uma ferramenta de download open source HTTP\/FTP que suporta m\u00faltiplas conex\u00f5es, sendo similar ao wget\/curl, usado pelo meta_chk<\/em> para baixar arquivos do servidor.<\/p>\n\n\n\n

              5-Carregar o arquivo de configura\u00e7\u00e3o \/system\/etc\/.gprs.xml<\/em> para usar o c\u00f3digo subsequente. O \/system\/etc\/.gprs.xml<\/em> \u00e9 um arquivo criptografado de configura\u00e7\u00e3o, com 12,508 bytes, que tem um formato personalizado e cont\u00e9m uma grande quantidade de campos, sendo o \u2018AZD\\0\u2019 o cabe\u00e7alho do arquivo. Este arquivo de configura\u00e7\u00e3o tem os seguintes campos:<\/p>\n\n\n\n

              • URL do C&C utilizado pelo Trojan<\/li>
              • Uma lista de package names dos antiv\u00edrus para serem desabilitados<\/li>
              • O package name de alguns aplicativos a serem promovidos e o path local para download<\/li>
              • Flag para indicar quando se o cache do browser deve ser limpo<\/li>
              • Flag para indicar se a homepage padr\u00e3o do browser deve ser alterada e a URL que dever\u00e1 ser configurada como padr\u00e3o<\/li>
              • Lista de comandos para executar<\/li>
              • A \u00faltima vez que a atividade maliciosa foi executada<\/li><\/ul>\n\n\n\n

                6-Ler o conte\u00fado do arquivo \/system\/etc\/hosts<\/em> e checar se o nome de algum dom\u00ednio 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<\/em> ir\u00e1 substituir todo o conte\u00fado do arquivo hosts com o conte\u00fado padr\u00e3o do arquivo de hosts (127.0.01 localhost) para garantir que os downloads subsequentes possam ser executados corretamente.<\/p>\n\n\n\n

                7-Baixar um arquivo com v\u00edrus em \/system;lib;libdowntemp.so<\/em> usando a ferramenta adb_meta<\/em> (axel), renomear como \/system\/bin\/chk<\/em> e torna-lo execut\u00e1vel para finalmente rodar o arquivo \/system\/bin\/chk<\/em>.<\/p>\n\n\n\n

                8-Baixar o arquivo de configura\u00e7\u00e3o e substituir o arquivo \/systema\/etc\/.gprs.xml<\/em> com isso o conte\u00fado baixado.<\/p>\n\n\n\n

                9-Baixar o APK e instal\u00e1-lo em segundo plano. Para garantir que o app possa ser baixado e instalado com sucesso, antes de iniciar a instala\u00e7\u00e3o silenciosa, o arquivo meta_chk<\/em> usa o comando \u2018pm disable\u2019 para, temporariamente, desativar o antiv\u00edrus. Ap\u00f3s a instala\u00e7\u00e3o do app ser\u00e1 utilizado o comando \u2018pm enable\u2019 para ativar o antiv\u00edrus. Enquanto isso, o meta_chk<\/em> usar\u00e1 a ferramenta sqlite para modificar, diretamente, a base de dados da configura\u00e7\u00e3o de apps do Android \u2013 settings.db<\/em> \u2013 para permitir a a instala\u00e7\u00e3o de apps de fontes desconhecidas.<\/p>\n\n\n\n

                10-Cria uma thread que ir\u00e1 escutar o socket e executar comandos enviados por outros programas. Os comandos recebidos pelo meta_chk<\/em> podem ser divididos em cinco grupos. O \u2018opengprs<\/em>\u2019 e o \u2018closegprs<\/em>\u2019 podem ligar e desligar a conex\u00e3o com a internet; O \u2018setdb<\/em>\u2019 pode diretamente modificar a base de dados para modificar v\u00e1rias configura\u00e7\u00f5es na parte de \u2018Configura\u00e7\u00e3o\u2019 do Android; O \u2018check?c=<\/em>\u2019 e o \u2018zxly2?=c<\/em>\u2019 podem executar comandos arbitr\u00e1rios com privil\u00e9gios root e retornar os resultados.<\/p>\n\n\n\n

                \u00c9 interessante que o meta_chk<\/em> verifica a assinatura RSA do App cliente que est\u00e1 conectando ao socket server. Ele executar\u00e1 o comando somente se a assinatura tiver o mesmo conte\u00fado do dado hard-coded no meta_chk<\/em>. Alguns antiv\u00edrus ou ferramentas de remo\u00e7\u00e3o utilizam alguma funcionalidade que o Trojan fornece para exlu\u00ed-lo, e esse mecanismo de autentica\u00e7\u00e3o torna este m\u00e9todo ineficaz.<\/p>\n\n\n\n

                Parte 3 \u2013 meta_chk<\/em><\/h4>\n\n\n\n

                O arquivo do sistema – \/system\/bin\/pm<\/em> \u2013 ser\u00e1 substitu\u00eddo pelo adb_server<\/em> para hookear o comando pm uninstall<\/em>. Se esse arquivo percebe que um dos apps que est\u00e1 sendo desinstalado, pelo usu\u00e1rio ou por alguma ferramenta de remo\u00e7\u00e3o, \u00e9 um dos que o Oldboot precisa, o adb_server<\/em> n\u00e3o desinstala, mas envia uma mensagem falsa de \u2018Sucesso\u2019. \u00c9 assim que funciona a fun\u00e7\u00e3o de anti-desinstala\u00e7\u00e3o.<\/p>\n\n\n\n

                O adb_server<\/em> existe no ramdisk do bootimg assim como outros membros da fam\u00edlia Oldboot. Diferente dos outros, esse n\u00e3o tem um ponto de inicializa\u00e7\u00e3o no script init.rc<\/em>. O meta_chk<\/em> (descrito abaixo) ir\u00e1 copiar ele e substituir o \/system\/bin\/pm<\/em> por ele. O processo de substitui\u00e7\u00e3o \u00e9 mostrado abaixo:<\/p>\n\n\n\n

                Quando o usu\u00e1rio ou um programa executa o comando pm, na verdade \u00e9 o adb_server<\/em> que \u00e9 executado. Ap\u00f3s iniciado, o adb_server<\/em> precisa de uma pequena inicializa\u00e7\u00e3o, como configurar o uid e o gid para root, checando a vari\u00e1vel de ambiente LD_LIBRARY_PATH e se o processo pai e shell.<\/p>\n\n\n\n

                Em seguida, o adb_server<\/em> checar\u00e1 se o sub-comando \u00e9 \u2018desinstalar\u2019. Se for, ele obter\u00e1 o pr\u00f3ximo par\u00e2metro, por exemplo, do nome do pacote que deseja desinstalar, e ir\u00e1 compar\u00e1-lo com o item da lista de nome do pacote built-in, um por um; Se o nome do pacote de desinstala\u00e7\u00e3o for achado na lista de nome do pacote built-in, ele ir\u00e1 retornar diretamente e mostrar uma falsa mensagem de \u2018Sucesso\u2019.<\/p>\n\n\n\n

                \"Oldboot\"<\/figure>\n\n\n\n

                 Parte 4 \u2013 agentsysline<\/em><\/h4>\n\n\n\n

                Dependendo dos par\u00e2metros de input, o agentsysline<\/em> pode fazer diferentes coisas. Ele pode agir como um programa SU ao chamar o shell para executar v\u00e1rios comandos com permiss\u00e3o Root ( os autores do Trojan n\u00e3o implementaram essa parte da fun\u00e7\u00e3o totalmente, ent\u00e3o n\u00e3o pode ser usada corretamente); O agentsysline<\/em> tamb\u00e9m pode rodar como daemon service, recebendo os comandos enviados do servidor remoto ou programas locais e executando eles em segundo plano.<\/p>\n\n\n\n

                O agentsysline<\/em> \u00e9 um programa multi-thread escrito em C++ com a fun\u00e7\u00e3o principal encapsulada utilizando classes C++. Tamb\u00e9m tem uma boa arquitetura, mesmo com no m\u00ednimo 15 threads criadas pelo pr\u00f3prio agentesysline<\/em>, a sincroniza\u00e7\u00e3o de t\u00f3picos \u00e9 muito boa. Quanto ao c\u00f3digo, podemos dizer que o autor do Trojan \u00e9 desenvolvedor s\u00eanior de Linux.<\/p>\n\n\n\n

                A fun\u00e7\u00e3o principal do agentsysline<\/em> est\u00e1 acondicionada em 6 classes C++, veja:<\/p>\n\n\n\n

                1. O Frame<\/em> classe single instance, controlando a execu\u00e7\u00e3o do programa<\/li>
                2. O NetManager<\/em> e o TcpSession<\/em> controlam a conex\u00e3o de rede<\/li>
                3. SocketCmdManager<\/em> cria um canal e envia\/recebe dados, al\u00e9m de enviar comandos recebidos para o CmdHandler<\/em> para executar<\/li>
                4. CmdHandler<\/em> recebe os comandos do SocketCmdManager<\/em>, analisa e cria novas threads para executarem esses comandos<\/li>
                5. Logger<\/em> implementa a funcionalidade de registro<\/li><\/ol>\n\n\n\n

                  A rela\u00e7\u00e3o entre essas classes de C++ \u00e9 apresentada abaixo:<\/p>\n\n\n\n

                  O fluxo de execu\u00e7\u00e3o do agentsysline<\/em>:<\/p>\n\n\n\n

                  1. Inicializa\u00e7\u00e3o; define o resource limit e signal handler e escreve o seu pr\u00f3prio PID no arquivo \/data\/system\/sys.server.id<\/em><\/li>
                  2. Chama SocketCmdManager<\/em> para criar um servidor socket e escuta continuamente<\/li>
                  3. Chama NetManager<\/em> para conectar \u00e0 internet e atualizar o arquivo de configura\u00e7\u00e3o<\/li>
                  4. Executa um loop infinito \u2013 chama SocketCmdManager<\/em> para receber comandos e execut\u00e1-los (as instru\u00e7\u00f5es suportadas s\u00e3o apresentadas abaixo) \u2013 a menos que um sinal especial seja recebido e a flag bTerminate<\/em> seja definida para 1<\/li>
                  5. Chama cada classe destrutora e sair<\/li><\/ol>\n\n\n\n

                    Veja o c\u00f3digo desassemblado:<\/p>\n\n\n\n

                    A defesa e as tend\u00eancias<\/h3>\n\n\n\n

                    Comparado ao Oldboot.A (imei_chk<\/em>), a nova varia\u00e7\u00e3o da fam\u00edlia Oldboot teve diversas mudan\u00e7as, em especial na defesa contra antiv\u00edrus, prote\u00e7\u00e3o anti-debugging e ferramentas de an\u00e1lise autom\u00e1tica, que s\u00e3o particularmente importantes assim como as seguintes:<\/p>\n\n\n\n

                    1. A habilidade de se esconder no sistema do Trojan Oldboot \u00e9 muito aprimorada. Por um lado, ap\u00f3s iniciado, o meta<\/em>_chk<\/em> ir\u00e1 deletar ele mesmo no arquivo do sistema, deixando somente o processo em si. Como sabemos, os antiv\u00edrus populares n\u00e3o suportam o escaneamento de mem\u00f3ria na plataforma Android, n\u00e3o sendo poss\u00edvel detectar ou deletar o Trojan Oldboot que reside na mem\u00f3ria. Por outro lado, o boot_tst<\/em> usa a t\u00e9cnica de inje\u00e7\u00e3o remota para inserir um arquivo SO e um JAR no processo do system_server<\/em>. Como a t\u00e9cnica de inje\u00e7\u00e3o na plataforma Android j\u00e1 est\u00e1 madura, pode-se esperar que os autores utilizem essas duas t\u00e9cnicas em conjunto, criando um \u201cno process, no file\u201d Trojan. Talvez este Trojan j\u00e1 at\u00e9 exista, mas ainda precisamos identifica-lo.<\/li>
                    2. O c\u00f3digo do arquivo ELF do Oldboot Trojan n\u00e3o \u00e9 claro, mas criptografado, e o c\u00f3digo descritivo no in\u00edcio da principal rotina ir\u00e1 decodificar toda a criptografia e execut\u00e1-la. Enquanto isso, quase todas as strings que o programa utiliza s\u00e3o criptografada A configura\u00e7\u00e3o tamb\u00e9m \u00e9 criptografada. O uso extensivo dessa t\u00e9cnica dificulta o processo de an\u00e1lise, al\u00e9m de aumentar o tempo necess\u00e1rio para analisa-lo.<\/li>
                    3. O Trojan usa alguns truques contra a an\u00e1lise din\u00e2mica, como adicionar alguns c\u00f3digos sem sentido e acionar aleatoriamente alguns procedimentos.<\/li>
                    4. O Oldboot checa alguns atributos do ambiente na hora de rodar. Por exemplo, o meta_chk<\/em> checa o path na hora de rodar e fecha se o path \u00e9 esperado. Ele tamb\u00e9m checa o SIM card e n\u00e3o realiza determinado procedimento se n\u00e3o tiver um SIM card. Devido a essas verifica\u00e7\u00f5es, o sandbox ou o emulador podem n\u00e3o obter resultados \u00fateis, al\u00e9m de um falso positivo.<\/li>
                    5. O Trojan verifica se existe um antiv\u00edrus e pode desinstal\u00e1-lo antes de fazer qualquer coisa maliciosa. Ou ele pode par\u00e1-lo utilizando o comando \u2018pm disable<\/em>\u2019 antes de instalar um app que ele deseja e, em seguida, reativ\u00e1-lo utilizando o comando \u2018pm enable<\/em>\u2019. Claro que a segunda op\u00e7\u00e3o mant\u00e9m o usu\u00e1rio sem saber, sendo mais sutil.<\/li>
                    6. O Oldboot utiliza a t\u00e9cnica Esteganografia para esconder o arquivo de configura\u00e7\u00e3o baixado do servidor C&C. Esteganografia \u00e9 uma t\u00e9cnica poderosa que esconde informa\u00e7\u00f5es em um formato e jeito que dificultada que seja detectada por quem n\u00e3o saiba que ele est\u00e1 ali. Foi descoberto que o meta_chk<\/em> ir\u00e1 baixar um arquivo do servidor C&C. Pela apar\u00eancia, o arquivo \u00e9 uma imagem. No entanto, ap\u00f3s algumas an\u00e1lises, descobriu-se que a configura\u00e7\u00e3o do meta_chk<\/em> est\u00e1 escondida nesta imagem, que cont\u00e9m um comando que ir\u00e1 executar o meta_chk<\/em> e outra informa\u00e7\u00e3o.<\/li>
                    7. A arquitetura do Trojan \u00e9 muito complexa, com um alto n\u00edvel de flexibilidade e muitos procedimentos podem ser configurados e controlados pelo servidor C&C do Trojan. O arquivo de configura\u00e7\u00e3o meta_chk<\/em> claramente prova este ponto. Ele tem 12,508 bytes e quase todo byte tem um significado diferente. Completar a an\u00e1lise de um Trojan controlado remotamente \u00e9 uma tarefa dif\u00edcil. Como o comando emitido pelo servidor C&C \u00e9 diferente, o procedimento desencadeado pode ser diferente.<\/li><\/ol>\n\n\n\n

                      A an\u00e1lise de correla\u00e7\u00e3o<\/h3>\n\n\n\n

                      O nome do dom\u00ednio que o meta_chk<\/em> ir\u00e1 se conectar \u00e9 az.o65.org (o servidor est\u00e1 desativado no momento). Atrav\u00e9s de algumas pesquisas sobre esse dom\u00ednio percebeu-se que o IP dele \u00e9 61.160.248.67. Tamb\u00e9m se descobriu que existem muitos dom\u00ednios com nome similar no mesmo servidor. Atrav\u00e9s do cache do motor de busca percebeu-se que todos t\u00eam um string \u2018ZKL90\u2019 como conte\u00fado da homepage. Por isso \u00e9 certo que todos esses dom\u00ednios s\u00e3o do servidor do meta_chk<\/em>. O meta_chk<\/em>, como um \u00fanico componente da fam\u00edlia Oldboot, tem in\u00fameros nomes de dom\u00ednio. Um nome de dom\u00ednio requer um recurso humano e financeiro consider\u00e1vel, por isso acredita-se que o tamanho do time por tr\u00e1s deste Trojan \u00e9 grande.<\/p>\n\n\n\n

                      Solu\u00e7\u00f5es<\/h2>\n\n\n\n

                      A PSafe est\u00e1 liberando a primeira ferramenta de detec\u00e7\u00e3o e remo\u00e7\u00e3o do Oldboot no mundo. Voc\u00ea pode baixar no link abaixo:<\/p>\n\n\n\n

                      \nhttps:\/\/msoftdl.360.cn\/mobilesafe\/shouji360\/360safesis\/OldbootKiller_v2.apk\n<\/div><\/figure>\n\n\n\n

                      Essa ferramenta ir\u00e1 escanear profundamente o Android para encontrar o Oldboot e suas vari\u00e1veis. Foi desenvolvido um novo m\u00e9todo de verifica\u00e7\u00e3o e exclus\u00e3o que pode, efetivamente, limpar os aparelhos Android mais populares do Oldboot.<\/p>\n\n\n\n

                      Se o seu aparelho n\u00e3o \u00e9 suportado no momento, veja as sugest\u00f5es a seguir:<\/p>\n\n\n\n

                      1. Verifique com frequ\u00eancia a atualiza\u00e7\u00e3o das ferramentas, pois ir\u00e1 contemplar mais modelos em breve;<\/li>
                      2. Voc\u00ea pode tentar restaurar a configura\u00e7\u00e3o de f\u00e1brica. Ap\u00f3s isso o Oldboot dever\u00e1 ter sido removido;<\/li><\/ol>\n\n\n\n

                        Discuss\u00e3o<\/h2>\n\n\n\n

                        Como o primeiro Bootkit da plataforma Android, o Oldboot tem um valor significativo. Na guerra entre Antiv\u00edrus e Trojans, ele traz um novo campo de batalha e inicia uma nova era.<\/p>\n\n\n\n

                        A populariza\u00e7\u00e3o da internet de alta velocidade representa um importante papel no crescimento dos smartphones. A plataforma Android est\u00e1 presente na maior parte dos celulares, estando conectado \u00e0 internet a maior parte do tempo. Os autores de Trojan perceberam isso e est\u00e3o pondo mais e mais informa\u00e7\u00e3o na rede, sendo que esses apps ou arquivos ELF instalados nos aparelhos s\u00f3 realizam fun\u00e7\u00f5es b\u00e1sicas, como mexer na configura\u00e7\u00e3o de internet ou executar comando com privil\u00e9gio ROOT etc. O que o Trojan realmente faz \u00e9 controlar o aparelho pelo servidor C&C dele. A fam\u00edlia do Oldboot Trojan \u00e9 a mais significativa demonstra\u00e7\u00e3o dessa tend\u00eancia.<\/p>\n\n\n\n

                        Baseado no Trojan descoberto, a fam\u00edlia Oldboot \u00e9 usada principalmente para promover apps altamente flex\u00edveis e configur\u00e1veis. Isso pode ser provado nos aspectos a seguir: <\/p>\n\n\n\n

                        1. Primeiro de tudo, o n\u00famero de dom\u00ednios e servidores onde o arquivo de configura\u00e7\u00e3o est\u00e1 armazenado \u00e9 alto e o dom\u00ednio muda frequentemente para assegurar que Oldboot possa ter as \u00faltimas atualiza\u00e7\u00f5es necess\u00e1rias para promo\u00e7\u00e3o ou contra a defesa do antiv\u00edrus; <\/li>
                        2. Segundo, o arquivo de configura\u00e7\u00e3o \u00e9 extremamente complexo e muitas coisas s\u00e3o configur\u00e1veis, incluindo o link de download do app, o caminho de armazenamento ap\u00f3s o download e nome de pacote etc; <\/li>
                        3. Terceiro, os autores levam em conta in\u00fameras circunstancias, por exemplo, se o endere\u00e7o do servidor foi sequestrado no arquivo host ou se a defesa contra antiv\u00edrus est\u00e1 ativa ou se o usu\u00e1rio deseja desinstalar o app utilizado para promover o \u2018pm uninstall<\/em>\u2019 etc; e claro, o Oldboot usa a tecnologia bootkit podendo formatar as configura\u00e7\u00f5es do Android e, automaticamente, come\u00e7ar com o Android usando o sistema como um servi\u00e7o nativo. <\/li><\/ol>\n\n\n\n

                          Com base nos pontos acima, podemos dizer que o Oldboot tem feito a \u2018melhor\u2019 abordagem de aplicativos maliciosos.<\/p>\n\n\n\n

                          O Oldboot \u00e9, 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. <\/p>\n\n\n\n

                          Feito para obter lucro, ele muda rapidamente para reagir a qualquer situa\u00e7\u00e3o. A PSafe continuar\u00e1 acompanhando o desenvolvimento desse tipo de ataque e fornecendo solu\u00e7\u00f5es de seguran\u00e7a.<\/p>\n","protected":false},"excerpt":{"rendered":"

                          Chegou uma fam\u00edlia de Trojan que consegue atacar a plataforma Android. Entenda como ele funciona, como foi desenvolvido e como a PSafe te protege dele.<\/p>\n","protected":false},"author":114,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_crdt_document":"","ngg_post_thumbnail":0,"footnotes":""},"categories":[555],"tags":[30,182,6659,66],"class_list":["post-12787","post","type-post","status-publish","format-standard","hentry","category-ciberataques","tag-android","tag-malware","tag-noticia","tag-telefone-celular"],"_links":{"self":[{"href":"https:\/\/www.psafe.com\/blog\/wp-json\/wp\/v2\/posts\/12787","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.psafe.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.psafe.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.psafe.com\/blog\/wp-json\/wp\/v2\/users\/114"}],"replies":[{"embeddable":true,"href":"https:\/\/www.psafe.com\/blog\/wp-json\/wp\/v2\/comments?post=12787"}],"version-history":[{"count":0,"href":"https:\/\/www.psafe.com\/blog\/wp-json\/wp\/v2\/posts\/12787\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.psafe.com\/blog\/wp-json\/wp\/v2\/media?parent=12787"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.psafe.com\/blog\/wp-json\/wp\/v2\/categories?post=12787"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.psafe.com\/blog\/wp-json\/wp\/v2\/tags?post=12787"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}