O Brickerbot como variante do malware Mirai

O leitor pode se perguntar como que omalwareBrickerbot se encaixa no modelo genérico, previamente criado, para descrever o funcionamento de variantes do malware Mirai. Isso porque o Brickerbot parece ser muito mais independente do que o Mirai, não sendo neces-sário que umbot fique à espera de comandos externos para realizar a tarefa que incentivou a sua criação, pois cada bot sabe exatamente o que deve ser feito assim que a máquina alvo for infectada. Um Servidor de Comando e Controle, neste caso, consequentemente torna-se inútil, a não ser que se deseje manter um registro dos bots que foram infectados.

Estes dados, porém, seriam apenas utilizados com este propósito no servidor: registro.

Porém, perceba que remover o Servidor de Comando e Controle é assumir que os bots, assim que infectarem uma máquina, irão executar o código que danifica/reconfigura a máquina e irão reiniciar tal máquina logo em seguida. Como, portanto, propagar pela rede a infecção para que se propague também a destruição?

Tabela5.4:TabelacontendodescriçãoresumidadediversasvariantesdomalwareMirai. DescobertoporArquiteturaVulnerabilidadeexploradaFuncionalidadeAdaptávelaomodeloMiraiUtiliza-sedaassinatura "/bin/busybox..." MiraiMalwareMustDiecliente-servidorporta23noalvoliberada realizaçãodeataquesDDoSSimSim "/bin/busyboxECCHI"alvoexecutandoservidorTelnet usuárioadministradorcomsenhapadrãoconhecida Satori360Netlabcliente-servidor

amesmaexploradapeloMirai,incluindo maisnomesdeusuárioesenhasàlista padrãoutilizadainterferecomoperaçõesde mineraçãodecriptomoedas, substituindooendereçoda carteiradomineradorpelo endereçodacarteirado atacante

SimSim "/bin/busyboxSATORI" CVE-2014-8361,umavulnerabilidade presentenoserviçoSOAPoferecido porroteadoresRealtekSDK CVE-2017-17215,umavulnerabilidade presenteemroteadores HuaweiHG532e(zero-daynaépocaemque omalwareSatorifoiidentificadopela HajimeRapidityNetworksP2PamesmaexploradapeloMirai, incluindomaisnomesdeusuário esenhasàlistapadrãoutilizada

fecharnodispositivo asportasutilizadaspor malwaresparainvadir dispositivosIoT NãoSim "/bin/busyboxECCHI" IoT_reaper360Netlabcliente-servidor

vulnerabilidadesespecíficas dedispositivosDLink,Goahead, JAWS,Netgear,Vacron,Linksys eAVTECH realizaçaõdeataquesDDoSSimNão OMGFortinetcliente-servidoramesmaexploradapelo Mirai

realizaçãode ataquesDDoSSimSim "/bin/busyboxOOMGA" transformaodispositivo invadidoemumproxy SOCKSeHTTP BrickerbotRadwaredesconhecida,mas nãocliente-servidor

aquelaexploradapeloMirai originalmente,masextremamente específicaparacadatipode dispositivoinutilizaçãodosdispositivos invadidosSimNão vulnerabilidadesmétodoCGIutilizado porservidoresWeb vulnerabilidadesnosprotocolosSOAPeHNAP

O leitor poderia argumentar que é possível estabelecer que os bots da rede botnet devem se responsabilizar por varrer a rede por certo tempo e apenas depois devem se encarregam de danificar o dispositivo. Esta é uma alternativa. Perceba, porém, que é uma alternativa um tanto quanto limitante: não temos garantia que a varredura irá de fato expandir a rede significativamente se considerarmos que o estado de varredura se extingue após determinada quantidade de tempo. O método de infecção não é garantido, e, ao mesmo tempo que umbotpode identificar outras máquinas vulneráveis rapidamente, ele pode também, demorar muito tempo para identificar apenas uma. Passamos então a considerar o caso em que, antes de danificar/reconfigurar a máquina, um bot precisa invadir uma quantidade mínima de máquinas vulneráveis. Neste caso, temos que de fato o modelo apresentado na Figura 5.1 não se adequaria aomalwareBrickerbot. O Servidor de Comando e Controle, neste novo modelo, poderia ser retirado sem que a rede botnet como um todo se perdesse. O ServidorLoader, porém, neste caso, deveria continuar existindo, se um bot ainda tiver a intenção de eliminar os seus rastros logo quando começar a executar, como ocorre com o malware Mirai.

Contudo, o Servidor de Comando e Controle pode ter sua necessidade restabelecida.

Imagine uma rede botnet que tem como objetivo inicial apenas se expandir, como ocorre com o malware Mirai. O Servidor de Comando e Controle, em contato com todos os nós desta rede em expansão, é capaz de determinar o tamanho total da rede botnet. Os bots pertencentes à rede, preocupam-se em: apagar os próprios rastros, varrer a rede à procura de novas máquinas vulneráveis, comunicar o ServidorLoader para que este infecte os novos alvos encontrados, e, finalmente, coletar informações sobre a máquina onde ele foi instalado. Enquanto a rede se expande, estas se mantêm as únicas responsabilidades dos bots. Em certo ponto, quando o criador domalware julgar adequado, um comando é enviado para todos os bots compondo a rede, para que estes comecem a realizar a tarefa de danificar/reconfigurar a máquina onde eles estão executando. Temos que neste caso, omalware Brickerbot se adequaria ao modelo presente na Figura 5.1. Há um Servidor de Comando e Controle que mantém registro dosbotse se comunica com um cliente desejando realizar um ataque PDoS (Permanent Denial of Service) em todos os dispositivos IoT infectados. Este cliente pode ser o próprio criador da rede botnet, mas isso não afeta em nada o quanto o modelo se adequa ou não à nossa situação de exemplo. O Servidor Loader, aqui, exercita a função de infectar dispositivos após receber informações de bots, que, por sua vez, trabalham independentemente até receberem o comando do Servidor de Comando e Controle para realizar a tarefa para qual eles foram designados. Todos os componentes existem e interagem da mesma forma que o modelo. Em contraste, porém, com o malware Mirai, temos que aqui os alvos são os própriosbots, que realizam a tarefa da auto-destruição.

Sabe-se, porém, que o exemplo dado acima não é o real. O malware Brickerbot foi identificado pela primeira vez em um honeypot da empresa Radware [90]. Esta mesma empresa fez um relatório descrevendo aquilo que já havia sido descoberto sobre o malware até aquele momento, e um dos pontos alegados por ela foi que nem todos os vetores de ataque puderam ser identificados pois o malware Brickerbot não tenta baixar um arquivo binário em um dispositivo invadido [91]]. Em outras palavras, não há infecção, apenas invasão. Um dispositivo invadido não executa o código de um bot. É possível, portanto, que a rede botnet associada a este malware, se existir, não existe para que os bots danifiquem as máquinas onde eles próprio habitam, mas sim, para invadir outras máquinas e danificar estas, que não fazem parte da rede botnet.

Independente da forma como a rede Brickerbot é organizada, temos que o ponto im-portante aqui é o seguinte: é possível, a partir do modelo domalwareMirai, criar uma rede botnet que executa a mesma funcionalidade que omalware Brickerbot. Nós já sabemos o poder de expansão do Mirai, e, portanto, podemos apenas especular que, em um ambiente real, se o mesmo código fosse utilizado, mas levemente alterado para ter como ataque base a realização de PDoS em dipositivos IoT, os resultados seriam tão catastróficos quanto a realização de um ataque DDoS a um servidor alvo qualquer. Um dos motivos para tal se dá pelo fato de que muitos dos dispositivos invadidos por uma possível variante do Brickerbot seriam roteadores, que podem ser uma parte crucial de redes internas que não podem se ver desconectadas do núcleo.

Diz-se em um ambiente real pois a adequação deste malware ao modelo genérico do Mirai já foi comprovada quando esta foi implementada, para o ambiente de simulação cri-ado, a partir de alterações no código fonte original (referenciar seção 3.3.1). Um malware criado para não agir como uma rede botnet teve seu código incorporado ao de outro que age. Aqui temos, portanto, como o modelo genérico criado pode ser utilizado para ex-pandir o escopo e a área de atuação de diversos malwares já existentes na rede. Não seria exagerado afirmar que o Mirai foi apenas o início de muitas variantes que vêm pela frente.