Triada Android Trojan
A família do Triada Android Trojan é uma família de malware que chamou a atenção dos profissionais de segurança cibernética em 2016. Logo depois que surgiu, o Triada Android Trojan foi detectado em dispositivos produzidos por uma longa lista de marcas de telefones chinesas. Entre as marcas em questão estão iLife, Prestigio, Leagoo e Mito. Até agora, os pesquisadores de malware não foram capazes de determinar se os fabricantes dos dispositivos móveis estavam cientes da presença do Trojan Android Triada. No entanto, a explicação mais provável é o software de terceiros usado pelos fabricantes. Esse é um vetor de infecção excepcionalmente ameaçador, já que a maioria dos usuários nunca suspeitaria que o seu novo dispositivo teve um Trojan instalado antes de ser usado.
Apesar de ter surgido pela primeira vez em 2016, a Triada ainda está muito ativa. Em agosto de 2020, descobriu-se que milhares de clientes haviam vendido smartphones Tecno W2 infectados com Triada. A lista de países onde os clientes foram afetados inclui África do Sul, Etiópia, Camarões e Gana.
Geralmente, o Trojan Android Triada não causa muitos danos. É um Trojan modular e os módulos padrão do Triada Android Trojan apenas permitem que ele colete informações sobre o hardware e software do dispositivo comprometido. O Triada envia os dados coletados para um dos servidores de C&C (Comando e Controle) dos operadores do Trojan Android Triada. Quando isso é concluído, o Trojan Triada Android recebe uma identificação de vítima exclusiva para a máquina afetada. Além disso, o C&C envia uma lista de módulos que serão plantados no host comprometido. Esse recurso inteligente permite que os operadores do Trojan Android Triada expandam significativamente as capacidades dessa ameaça.
Uma das características mais proeminentes do Trojan Android Triada é sua capacidade de modificar o processo Android Zygote. Como o Zygote é o processo central do sistema operacional Android e é um modelo para todos os aplicativos, uma vez que o Trojan entra no Zygote, ele se torna essencialmente uma parte de cada aplicativo iniciado no dispositivo infectado. Isso também permite que o Trojan Triada Android gerencie como o dispositivo está lidando com os aplicativos recém-instalados.
História e Evolução do Triada
Inicialmente, a Triada instalou um tipo de arquivo binário de superusuário (su). Este binário su permitiu que outros aplicativos no dispositivo usassem permissões de root. O binário su que Triada usava exigia uma senha, por isso era diferente dos arquivos binários su regulares geralmente encontrados em sistemas Linux.
O binário de Triada aceita duas senhas, od2gf04pd9 e ac32dorbdq. A diferença era o que o binário fazia quando fornecido com cada um. O binário pode:
- Execute o comando fornecido como um argumento como root
- Combine todos os argumentos, execute a cadeia precedida por sh e, em seguida, execute-os como root.
De qualquer forma, o aplicativo precisava fornecer a senha correta para executar o comando como root.
A funcionalidade de enraizamento do Trojan Android Triada permitiu a instalação de aplicativos e a exibição de anúncios. Esta versão do trojan visava dispositivos de modelos mais antigos porque os exploits de root não funcionam nos dispositivos da geração atual. Portanto, o Triada aplicou um recurso de monitoramento de peso para determinar se os aplicativos instalados anteriormente devem ser excluídos para liberar espaço para novas instalações.
Este processo para atribuir um Peso aos aplicativos teve várias etapas e o objetivo era liberar espaço na partição do usuário da máquina infectada e partição do sistema. O Triada incluiu uma lista negra e uma lista branca de aplicativos. A primeira prioridade era remover todos os aplicativos de sua lista negra. Caso fosse necessário mais espaço livre, Triada removeria todos os outros aplicativos que não estavam na lista branca. Desta forma, a Triada liberou espaço enquanto certificava-se de que o telefone funcionava corretamente.
Todos os aplicativos na partição do sistema receberam números para representar seu peso. O peso foi calculado como a soma do número de outros aplicativos instalados na mesma data e o número de aplicativos assinados com o mesmo certificado. Como resultado, os aplicativos que foram instalados isoladamente (ou seja, não em uma data em que a imagem do sistema do dispositivo foi criada) e não foram assinados pelo OEM ou não vieram como parte de um pacote de desenvolvedor receberam o peso mais baixo número. Esses foram os aplicativos que Triada excluiu primeiro em seu processo de monitoramento de peso. Isso continuou até que houvesse espaço suficiente para o novo aplicativo que o Triada pretendia instalar.
Processo de Instalação do Triada - Fonte: security.googleblog.com
Os aplicativos instalados pelo Triada tinham um objetivo - exibir anúncios e gerar receita para os cibercriminosos. No entanto, Triada também injetou código malicioso em pelo menos quatro navegadores da Web: AOSP (com.android.browser), 360 Secure (com.qihoo.browser), Cheetah (com.ijinshan.browser_fast) e Oupeng (com.oupeng.browser. O objetivo da injeção de código era redirecionar URLs e alterar banners de anúncios em sites com anúncios que rendiam dinheiro para os autores de Triada.
Outra coisa que diferenciava o Triada era que ele usava uma estranha e complexa rotina de criptografia de comunicação. Ao enviar uma solicitação ao servidor C&C, ele criptografou os dados usando dois loops XOR com senhas diferentes. Por causa do funcionamento do XOR, se as senhas tivessem o mesmo caractere na mesma posição, esses caracteres não seriam criptografados. Após criptografar a solicitação, Triada salvou-a em um arquivo, que tinha o mesmo nome de seu tamanho. A última etapa foi compactar o arquivo usando zip e enviá-lo ao servidor de C&C no corpo da solicitação POST.
Ao longo dos anos, a Triada mudou em resposta às medidas de segurança do Google. Em meados de 2017, o Trojan foi transformado em um backdoor do framework Android pré-instalado. Para isso, Triada incluiu uma chamada na função de log do framework Android. Essa mudança resultou na execução de um código adicional sempre que o método de log era chamado. Como essas chamadas acontecem o tempo todo, o código adicional estava sendo executado constantemente. Além do mais, o código executado no contexto do aplicativo que chama o método de log. Isso permitiu que a Triada executasse código no contexto de qualquer aplicativo.
Os criadores do Triada surgiram com um novo formato de arquivo, que os pesquisadores de segurança do Google chamaram de MMD, por conta do cabeçalho do arquivo. O formato MMD é uma versão criptografada de um arquivo DEX executado no contexto do aplicativo. Os cibercriminosos usaram um loop XOR duplo implantando duas senhas diferentes, conforme mostrado abaixo.
Processo de Implantação da Senha em Formato de Arquivodo Triada - Fonte: security.googleblog.com
Cada arquivo MMD foi nomeado de acordo com o formato 36.jmd. Os criminosos usaram MD5 do nome do processo com o objetivo de ocultar o alvo da injeção. No entanto, o hash era fácil de reverter por causa do conjunto limitado de todos os nomes de processos disponíveis. Os pesquisadores de segurança do Google identificaram dois alvos: com.android.systemui (o aplicativo System UI) e com.android.vending (o aplicativo Google Play). Com.android.systemui foi injetado para obter a permissão GET_REAL_TASKS. Como uma permissão de nível de assinatura, é algo que os aplicativos Android comuns não podem conter.
Desde o Android Lollipop, o método getRecentTasks () está obsoleto para proteger a privacidade dos usuários. No entanto, se um aplicativo tiver a permissão GET_REAL_TASKS, ele ainda poderá obter o resultado dessa chamada de método. Para que um aplicativo tenha essa permissão, ele deve ser assinado com um certificado específico, o certificado de plataforma do dispositivo, que é propriedade do OEM. Como a Triada não pôde acessar este certificado, ela usou o aplicativo System UI, que tem a permissão GET_REAL_TASKS para executar código adicional.
O segundo aplicativo do Triada direcionado à injeção foi o Google Play. O código habilitou cinco comandos e respostas a eles. Os comandos suportados eram:
- Pedido de download
- Resultado do download
- Solicitação de instalação
- Resultado da instalação
- Pedido de ativação
- Resultado de ativação
- Solicitação para tirar
- Puxar os resultados
- Pedido de desinstalação
- Resultado da desinstalação
No aplicativo Triada e nos códigos de injeção, esses comandos estavam em chinês. Os comandos iniciam a ação correspondente no contexto do aplicativo Google Play. Ao fazer isso, Triada poderia fazer parecer que todas as instalações de aplicativos vieram do aplicativo Google Play, o que significava que o malware não precisava ativar a opção que permite a instalação de aplicativos de fontes desconhecidas.
A Triada baixou os aplicativos do seu servidor de C&C e criptografou a comunicação com o mesmo método de criptografia personalizado usando XOR duplo e zip. Os pacotes de aplicativos baixados e instalados pela Triada foram nomeados em homenagem a aplicativos impopulares encontrados no Google Play. Esses aplicativos não tinham nada a ver com o Triada, os cibercriminosos estavam apenas usando seus nomes.
A última parte importante de como o Triada funcionava era a comunicação entre a porta dos fundos da função de log e os aplicativos que foram instalados. Os aplicativos podem se comunicar com a porta dos fundos registrando uma linha com uma tag e mensagem predeterminadas específicas. A comunicação na outra direção era mais difícil. O backdoor se comunicava com os aplicativos usando propriedades Java para enviar mensagens. As propriedades em questão eram pares de valores-chave semelhantes às propriedades do sistema Android, exceto que estavam focadas em um processo específico. Modificar uma propriedade no contexto de um determinado aplicativo significa que ela não será detectada por outros aplicativos. Certas versões do Triada criaram essas propriedades em cada processo de aplicativo.
Processos de Criação das Propriedades do Malware Triada - Fonte: security.googleblog.com
Vetor de Infecção OEM
A forma como o Triada encontra seu caminho nos novos dispositivos é por meio de software de terceiros. Isso geralmente acontece quando os OEMs decidem incluir um recurso que não está disponível no Android Open Source Project. Nesses casos, os OEMs costumam recorrer a terceiros para criar o recurso que os OEMs estão procurando e enviar de volta uma imagem completa do sistema ao fornecedor para desenvolvimento. Os pesquisadores de segurança do Google suspeitaram que um fornecedor chamado Yehuo ou Blazefire pode ter infectado a imagem com Triada.
Processos de Infecção do Fornecedor do Triada OEM - Fonte: security.googleblog.com
O Google relatou que eles trabalharam com os OEMs afetados para fornecer atualizações do sistema e erradicar o Triada. No entanto, a partir de 2020 ainda existem casos de dispositivos infectados pelo Triada.
