Foco de Ameaça: Aplicações web sob ameaça ativa de bugs Shellshock de 10 anos e mineradores

Os bugs Shellshock — existem seis designações CVE relacionadas — têm a classificação de severidade mais alta de 10. Eles existem na shell Unix Bash, que é a interface de linha de comando padrão em todos os sistemas operativos baseados em Linux, Unix e Mac. Se explorado com sucesso, o Shellshock pode permitir que um atacante faça com que o Bash execute comandos arbitrários e obtenha acesso não autorizado a muitos serviços voltados para a internet, como servidores web, que utilizam o Bash para processar pedidos.

Software vulnerável sob ataque ativo

As três principais vulnerabilidades atualmente visadas com ataques Shellshock estão no gráfico abaixo. Elas destacam como as vulnerabilidades podem permanecer durante anos sem serem detectadas na cadeia de fornecimento de software.

Um dispositivo pode estar a executar a versão mais recente do firmware, mas ainda assim ser vulnerável, porque as pessoas que criaram esse software não atualizaram as bibliotecas na sua cadeia de fornecimento.

CVE-2019-7481 é uma vulnerabilidade de injeção SQL classificada com 7.5 num serviço de segurança para o qual existe uma correção. CVE-2021-42071 é uma vulnerabilidade crítica classificada com 9.8 numa aplicação de ferramenta visual que pode permitir a um atacante não autenticado executar comandos remotamente.

Instalação de variantes do botnet Mirai

CVE-2019-7481 tem sido alvo desde pelo menos 2021 por atacantes que tentam instalar variantes do botnet Mirai. O botnet Mirai é composto por um vasto número de dispositivos conectados (IoT) hackeados e é utilizado predominantemente para lançar ataques DDoS.

Desde que o Mirai surgiu pela primeira vez em agosto de 2016, os investigadores têm observado múltiplas variantes aparecerem no cenário de ameaças. O Mirai tem como alvo principal dispositivos IoT baseados em Linux. A maioria dos ataques começa com o download de um script de shell que, em seguida, descarrega vários binários de malware específicos para diferentes plataformas e tenta executá-los. Uma vez infetado, o dispositivo torna-se parte da crescente botnet.

As duas primeiras variantes do Mirai que vimos nos nossos registos estavam a atacar a interface web LuCI para routers baseados em OpenWRT. Esta é uma interface de gestão que não deveria estar exposta à internet. Infelizmente, muitas vezes está, e os atacantes aproveitam-se disso.

A primeira variante foi utilizada por atacantes a tentar executar um script shell chamado "sorry.sh".

Este script já não está disponível. De acordo com URLhaus, foi reportado e retirado. No entanto, a análise no URLhaus deixa claro que isto faz parte de uma tentativa de infestação Mirai/Gafgyt. Uma descrição mais detalhada está disponível em VirusTotal.

A segunda variante ainda está ativa.

Os atacantes que utilizam esta variante apagam tudo no diretório raiz e, em seguida, descarregam um script shell em /tmp.

O script shell, quando executado, descarrega vários binários específicos da plataforma e, em seguida, executa-os por ordem.

O programador deste script específico parece ter sentido de humor. Os ficheiros descarregados são renomeados usando uma série crescente de insultos (devidamente censurados na captura de ecrã.)

Uma variante diferente do Mirai/Gafgyt estava a atacar uma vulnerabilidade de execução remota de comandos em routers Zyxel. A entrada URLhaus mostra que este era também um "infector" Mirai (huhu.mips) — embora agora esteja offline. Ao observar a entrada para o endereço IP, está atualmente a fornecer o malware com um novo nome (skyljne.mips.)

Infeções de cryptominer direcionadas a vulnerabilidades

Além do Shellshock, vimos atacantes a visar vulnerabilidades para instalar criptomineradores.

Em 2022, vimos cryptominers a tentar explorar a então nova vulnerabilidade do Atlassian Confluence. Em fevereiro de 2024, estamos a ver tentativas ativas de explorar vulnerabilidades antigas do ThinkPHP e instalar miners XMRig.

A primeira URL que vimos foi:

A decodificação parcial de base64 revela o seguinte comando:

Isto aparece em ANY.RUN como o minerador XMRig. No momento em que escrevemos este blog, o minerador ainda está online.

Outro exemplo disto é:

Isto descodifica para:

Uma análise deste script shell em ANY.RUN mostra que ele também descarrega o binário redtail.

Um terceiro exemplo disso é o mesmo IP 45.x a servir um script diferente:

Isto descodifica para:

De acordo com VirusTotal, isto é provavelmente um minerador também.

Um exemplo final do minerador é este:

Isto descodifica para:

O nome do minerador neste caso não está ofuscado e é diretamente identificável como XMRig. Atualmente está offline.

Todos os exemplos de mineradores visam vulnerabilidades mais antigas do ThinkPHP — vulnerabilidades de execução remota de código (RCE) de 2018 e 2020 que já deveriam estar corrigidas.

Manter as suas aplicações seguras

Esses tipos de ataques vêm e vão em ondas, com cada onda — tanto para o Mirai quanto para os cryptominers — a visar vulnerabilidades específicas em campanhas.

Há cerca de 10 anos, os atacantes procuravam principalmente e utilizavam vulnerabilidades mais recentes, como zero days, para tentar entrar na rede. Isto mudou para os atacantes trabalharem de forma mais inteligente, não mais árdua. Eles perceberam que as cadeias de fornecimento de software raramente são totalmente seguras e estão a usar vulnerabilidades mais antigas, mas ainda não corrigidas, a seu favor.

O problema de segurança na cadeia de fornecimento de software é bastante difícil de resolver — pode implementar a versão mais recente do seu software de transferência de ficheiros, mas por trás, esse software pode estar a usar uma versão vulnerável do Log4J. Assumimos que a nossa aplicação é segura, mas na verdade tem uma vulnerabilidade conhecida. E a única maneira de descobrir isso é realizando varreduras regulares de vulnerabilidades. No caso do Log4J, provavelmente está a fazer isso. Mas o que acontece se a vulnerabilidade estiver numa biblioteca relativamente desconhecida que é usada apenas neste único software?

O antigo conselho de defesa em profundidade continua relevante. Ter uma “cebola” defensiva para a sua rede e aplicações é crucial para prevenir ataques antes que possam atingir a sua aplicação. Esta abordagem também lhe dará tempo e cobertura para quando ainda não tiver conseguido corrigir um novo zero-day.

A proteção contra DDoS também continua a ser crítica. Os atacantes estão a usar vulnerabilidades antigas de anos para criar os seus botnets e realizar novos tipos de ataques DDoS, como o HTTP/2 Rapid Reset. Ter uma solução em vigor que possa parar ataques DDoS volumétricos mais antigos e ataques DDoS de aplicações mais recentes e subtis é essencial para a continuidade do negócio.

Se olharmos para as vulnerabilidades mencionadas acima e no nosso recente Spotlight de Ameaças de segurança de aplicações , vê-se que, quando se trata de aplicações, a cadeia de fornecimento de software é um elo fraco que precisa e merece uma camada protetora significativa.