Análise da mais recente onda do Mirai que explora dispositivos TBK DVR com CVE-2024-3721

O uso indevido de falhas de segurança conhecidas para implementar bots em sistemas vulneráveis é um problema amplamente reconhecido. Muitos bots automatizados pesquisam constantemente a web em busca de vulnerabilidades conhecidas em servidores e dispositivos conectados na Internet, especialmente aqueles que executam serviços populares. Geralmente, esses bots carregam exploits de Execução Remota de Código (RCE) direcionados aos serviços HTTP para permitir que os invasores integrem comandos Linux em requisições GET ou POST.

Observamos recentemente o uso do CVE-2024-3721 em tentativas de implantação de um bot em um de nossos serviços honeypot. Essa variante de bot acabou fazendo parte do infame botnet Mirai que tinha como alvo sistemas de monitoramento baseados em DVR. Os dispositivos DVR são projetados para gravar dados de câmeras, são amplamente usados por muitos fabricantes e podem ser gerenciados remotamente. Neste artigo, descreveremos os novos recursos do bot Mirai e seu vetor de infecção reformulado.

Exploração

Durante uma análise dos registros em nosso sistema honeypot Linux, notamos uma linha de requisição incomum vinculada a um CVE-2024-3721. Essa vulnerabilidade permite a execução de comandos do sistema em dispositivos TBK DVR sem a devida autorização como ponto de entrada, usando uma requisição POST específica:

A requisição POST contém um comando malicioso que é um script de shell de linha única que baixa e executa um binário ARM32 na máquina comprometida.

Normalmente, as infecções por bots envolvem scripts de shell que examinam inicialmente a máquina alvo para determinar sua arquitetura e selecionar o binário correspondente. Entretanto, neste caso, como o ataque é direcionado especificamente aos dispositivos compatíveis apenas com binários ARM32, o estágio de reconhecimento é desnecessário.

Implante de malware – variante Mirai

O código-fonte do botnet Mirai foi publicado na Internet há quase uma década e, desde então, foi adaptado e modificado por vários grupos de criminosos virtuais para criar botnets de larga escala focados principalmente em DDoS e sequestro de recursos.

O bot DVR também é baseado no código-fonte do Mirai, mas inclui recursos diferentes, como criptografia de strings com uso de RC4, verificações antiVM e técnicas antiemulação. Já falamos sobre o Mirai em muitos posts, então, vamos nos concentrar nos novos recursos dessa variante específica.

Descriptografia de dados

A rotina de descriptografia de dados nesta variante é implementada como um algoritmo RC4 simples.

A chave RC4 é criptografada com XOR. Após a descriptografia da chave, conseguimos obter seu valor: 6e7976666525a97639777d2d7f303177.

A chave RC4 descriptografada é usada para descriptografar as strings. Depois que cada pedaço de dados é descriptografado, ele é inserido em um vetor de uma estrutura DataDecrypted, que é uma lista de strings:

Rotina de descriptografia de dados

A lista encadeada global com os dados descriptografados é acessada sempre que o malware precise de strings específicas.

Adição de strings descriptografadas na lista global

AntiVM e antiemulação

Para detectar se está sendo executado dentro de uma máquina virtual ou QEMU, o malware lista todos os processos até encontrar qualquer menção ao VMware ou QEMU-arm. Listar os processos em execução é simplesmente uma questão de abertura do diretório /proc, que é um sistema de arquivos de processos no Linux.

Cada ID do processo (PID) tem sua própria pasta contendo as informações úteis, como cmdline, que descreve o comando usado para iniciar o processo. Munido com essas informações, o malware verifica se há algum processo com VMware ou QEMU-arm em sua linha de comando.

Verificação de processo

O implante também verifica se o processo do bot está sendo executado fora de um diretório esperado de acordo com uma lista codificada de processos permitidos:

Diretórios permitidos

Depois que essas verificações forem concluídas com sucesso, o Mirai continuará a execução normal para preparar o dispositivo com vulnerabilidade para receber comandos do operador.

Estatísticas de infecção

De acordo com nossos dados de telemetria, a maioria das vítimas com infecção está localizada em países como China, Índia, Egito, Ucrânia, Rússia, Turquia e Brasil. É desafiador determinar o número exato de dispositivos vulneráveis e infecções em escala global. No entanto, ao analisar fontes públicas, identificamos mais de 50 mil dispositivos DVR expostos on-line, o que indica que os invasores têm inúmeras oportunidades de atingir dispositivos com vulnerabilidades e sem patches.

Conclusão

A exploração de falhas de segurança conhecidas em dispositivos e servidores de IoT que não receberam patches, juntamente com o uso generalizado de malware direcionado aos sistemas baseados em Linux, leva a um número significativo de bots que pesquisam constantemente a Internet em busca de dispositivos para que sejam infectados.

O principal objetivo desses bots é realizar ataques que sobrecarregam sites e serviços (ataques DDoS) pelos invasores. A maioria desses bots não permanece ativa após o reinício do dispositivo porque alguns firmwares do dispositivo não permitem alterações no sistema de arquivos. Para se proteger contra infecções como essas, recomendamos atualizar os dispositivos vulneráveis assim que os patches de segurança estiverem disponíveis. Outro fator a considerar é uma redefinição de fábrica se o dispositivo estiver realmente vulnerável e exposto.

Todos os produtos da Kaspersky detectam a ameaça como HEUR:Backdoor.Linux.Mirai e HEUR:Backdoor.Linux.Gafgyt.

Indicadores de comprometimento

Baseado em host (hashes MD5)
011a406e89e603e93640b10325ebbdc8
24fd043f9175680d0c061b28a2801dfc
29b83f0aae7ed38d27ea37d26f3c9117
2e9920b21df472b4dd1e8db4863720bf
3120a5920f8ff70ec6c5a45d7bf2acc8
3c2f6175894bee698c61c6ce76ff9674
45a41ce9f4d8bb2592e8450a1de95dcc
524a57c8c595d9d4cd364612fe2f057c
74dee23eaa98e2e8a7fc355f06a11d97
761909a234ee4f1d856267abe30a3935
7eb3d72fa7d730d3dbca4df34fe26274
8a3e1176cb160fb42357fa3f46f0cbde
8d92e79b7940f0ac5b01bbb77737ca6c
95eaa3fa47a609ceefa24e8c7787bd99
96ee8cc2edc8227a640cef77d4a24e83
aaf34c27edfc3531cf1cf2f2e9a9c45b
ba32f4eef7de6bae9507a63bde1a43aa
IPs
116.203.104[.]203
130.61.64[.]122
161.97.219[.]84
130.61.69[.]123
185.84.81[.]194
54.36.111[.]116
192.3.165[.]37
162.243.19[.]47
63.231.92[.]27
80.152.203[.]134
42.112.26[.]36