O diretório /loadere o Servidor Loader

O Servidor Loader é o servidor responsável pela automatização do processo de infecção de dispositivos vulneráveis. Os dados repassados para saída padrão de uma máquina pelo Servidor ScanListen tem o propósito de serem consumidos pelo Servidor Loader, para que este, munido do código que o permite fazer isto, seja capaz de invadir novamente os dispositivos vulneráveis e transformá-los em bots. O loader, como aqui chamaremos este servidor, é de fato uma ferramenta que tem o propósito único de aplicar sobre o sistema do malware como um todo a automatização do processo de infecção. Isto porque temos que ainda seria possível infectar bots sem ele. Porém, se este fosse o caso, temos que seria necessário realizar tal tarefa de forma manual, e, considerando a taxa real de crescimento verificada para a rede botnet Mirai e dadas todas as threads dos vários bots que varrem a rede, é possível confirmar que isso não seria algo simples de se fazer. Por este motivo é que o loader se faz útil. O código associado a ester servidor está escrito na linguagem C.

• main.c: este arquivo é o arquivo que, mais uma vez, possui a função que inicializa o programa como um todo, a função main. Dentro de main temos que, como pri-meira operação relevante, diversos arquivos executáveis são recuperados e têm seu conteúdo armazenado em memória, após a chamada de uma das funções implemen-tadas em binary.c. Estes arquivos são arquivos que contém código executável que

implementa a mesma funcionalidade que o programaWget. Mais sobre estes arqui-vos será detalhado na seção que segue esta. Depois desta recuperação, temos que asthreads que serão responsáveis por tratar de infecções de dispositivos vulneráveis são criadas, e valores cruciais para a sua correta execução são inicializados. Como última operação, temos que um laço é iniciado de forma a nunca parar de executar.

Este laço recupera dados na entrada padrão e envia tais dados para outros módulos, para que eles possam ser corretamente interpretados e utilizados, caso possuam o formato correto.

• includes.h: possui a definição de macros e a declaração de variáveis que são utili-zados por outros módulos do código. Neste arquivo é que encontramos as definições deTOKEN_QUERY eTOKEN_RESPONSE, dois valores utilizados extensivamente pelo lo-ader para que dados por ele recebidos quando se comunicando com o dispositivo a ser infectado sejam corretamente consumidos.

• util.c/util.h: como os arquivos de mesmo nome em/mirai/bot (referenciar se-ção 3.1.3), temos que o código aqui presente contém funções que realizam operações auxiliares, como o tratamento de buffers de bytes, a criação de sockets, o envio de mensagens por meio destes, e a conversão de sequências de valores hexadecimais para formato ASCII.

• binary.c/binary.h: contém as funções responsáveis por encontrar, recuperar e armazenar em uma estrutura local os arquivos que contém código executável res-ponsável por implementar as mesmas funcionalidades do programa Wget.

• telnet_info.c/telnet_info.h: contém as funções e estruturas de dados a elas associadas que são responsáveis por realizar o parsing da entrada sendo consumida pelo Servidor Loader em main. Os dados processados aqui são armazenados em variáveis que representam o seu verdadeiro formato como, por exemplo, endereços IP, que, antes em formato string, são convertidos para um inteiro de 4 bytes. Este novo armazenamento permite que outros módulos doloader utilizem os dados para realizar outras tarefas essenciais.

• server.c/server.h: semelhantemente ao código implementado em /mirai/bot/

scanner.c (mais sobre este código pode ser lido na seção 3.1.3), temos que esta parte do código loader é a que se responsabiliza por de fato invadir e infectar o bot.

O código presente aqui, porém, é muito mais extenso do que aquele implementado em /mirai/bot/scanner.c, pois o processo de infecção involve muito mais do que apenas descobrir um nome de usuário e uma senha. Já em posse destes dados, as funções aqui implementadas seguem uma sequência de estados que definem as

seguintes etapas para um processo de invasão e infecção: acesso ao dispositivo como usuário administrador, utilizando as credenciais enviadas por umbotpara o Servidor ScanListen; ativação do shell sh, para que possam ser a executados comandos a serem processados pelo sistema operacional do alvo; descoberta de diretórios deste que possuem permissões de escrita; criação de um arquivo com todas as permissões liberadas neste diretório; identificação da arquitetura de hardware do dispositivo alvo; utilização do programaWget, ou de um cliente TFTP, ou do código executável recuperado e armazenado localmente pelas funções debinary.c, para que possa ser realizada a comunicação com um servidor remoto e recuperarado outro arquivo executável compilado para a arquitetura em questão; passagem do conteúdo do arquivo recuperado remotamente para o arquivo criado localmente; e, finalmente, execução deste arquivo. Perceba o que está acontecendo com esta sequência de passos: o servidor loader acessa o dispositivo e cria nele um arquivo que, após ser configurado corretamente, é executado. Ele nada mais está fazendo do que recuperando o código executável de um bot, armazenado remotamente, e forçando este a ser executado por um dispositivo alvo, transformando-o assim em um novo bot. Assim se completa mais um ciclo do processo de expansão da rede botnet.

Vale mencionar que, como no caso de scanner.c, temos que existe um laço sendo executado para garantir que a falta de consumo e processamento de dados em uma única iteração cause o fim do processo de infecção. Existem certas respostas a comandos shell, enviados do loader para o alvo, que são extensas e exigem que mais de uma leitura do conteúdo nosocket da conexão seja feita para que elas possam ser completamente tratadas. O código, porém, mostra que este laço não precisa executar incessantemente, a demora de processamento ou a falta de resposta por parte do correspondente encerrando o processo e infecção precipitadamente caso necessário.

Encontra-se aí uma possível vulnerabilidade do próprio código domalware, que pode vir a encerrar uma conexão tendo criado arquivos no alvo e não os tendo removido, o que faz com que ele deixe ali a marca de sua invasão.

• connection.c/connection.h: o código presente neste arquivo é um código que complementa aquele presente em server.c e server.h. Enquanto nas funções de server.c temos o envio de comandos para o alvo, nas funções de connection.c temos o consumo dos dados enviados como resposta para tal comando. Portanto, temos queserver.c chama as funções de connection.c constantemente, cada vez que um novo estado do processo de infecção se inicia. Os dois módulos coordenam um com o outro por meio da utilização dasstrings TOKEN_QUERYeTOKEN_RESPONSE.

A primeira contém um comando shell, que, quando utilizado em qualquershell que reconhece o programaBusybox, gera uma resposta de erro característica. A segunda

string é justamente esta resposta. Toda vez que server.c envia uma sequência de comandos para o alvo vulnerável, ele encerra esta sequência enviando o valor TOKEN_QUERY. Desta forma, as funções deconnection.c, ao consumirem os dados, são capazes de identificar quando que a resposta para o comando sendo processado por elas naquele instante se encerra. Assim, dados a mais recuperados do socket não são incorretamente descartados e dados que precisam ser processados não são considerados incorretamente pelas funções. Este "trabalho em grupo"realizado pelas funções de server.c econnection.c é uma das características mais marcantes do processo de infecção do malware Mirai.