Dia zero (CVE-2023-34362) do MOVEit SQLi explorado pelo grupo de ransomware CL0P
Por Ori David, Sam Tinklenberg, Maxim Zavodchik e Ophir Harpaz
Resumo executivo
Em 31 de maio de 2023, a Progress Software começou a alertar os clientes sobre uma vulnerabilidade anteriormente desconhecida no MOVEit Transfer e no software MOVEit Cloud. A vulnerabilidade de SQLi (injeção de SQL), atribuída a CVE-2023-34362, foi ativamente explorada por invasores.
De acordo com um relatório da Mandiant, as tentativas de exploração desta vulnerabilidade foram detectadas a partir de 27 de maio de 2023. No mesmo dia, os pesquisadores da Akamai detectaram tentativas de exploração contra um dos clientes financeiros da Akamai, um ataque que foi bloqueado pelo Adaptive Security Engine da Akamai.
A campanha de ataque foi atribuída a um grupo de ransomware chamado CL0P. O grupo, que se acredita estar localizado na Rússia ou Europa Oriental, tem motivação financeira e é conhecido por extorquir suas vítimas por meio de exfiltração de dados.
Os invasores exploraram a vulnerabilidade do SQLi para implantar uma Web shell ASP.NET personalizada (LEMURLOOT) para obter persistência nas redes das vítimas e permitir outros ataques.
No momento em que este artigo foi escrito, os detalhes completos da exploração não estavam disponíveis publicamente. No entanto, a análise do Grupo de inteligência de segurança da Akamai e a colaboração com a equipe de segurança da Progress confirmam que o Adaptative Security Engine protegeu nossos clientes contra tentativas de exploração.
Linha do tempo
Fig. 1: Cronograma de eventos da campanha de exploração do MOVEit
Em 31 de maio de 2023, a Progress Software publicou um comunicado e começou a alertar seus clientes sobre uma vulnerabilidade de dia zero no MOVEit Transfer e na MOVEit Cloud, que estava sendo ativamente explorada por invasores para comprometer servidores voltados para a Internet (Figura 1).
Esse alerta surgiu após a identificação de uma campanha de exploração em massa que aproveitou essa vulnerabilidade para exfiltrar arquivos confidenciais armazenados em servidores vulneráveis. De acordo com a Mandiant, as tentativas de exploração da vulnerabilidade foram observadas a partir de 27 de maio de 2023. Uma análise técnica da vulnerabilidade foi realizada pela Huntress, que mostrou que a vulnerabilidade poderia realmente levar a uma execução remota completa de código no servidor.
A Microsoft oficialmente atribuiu este ataque ao grupo Lace Tempest em 2 de junho de 2023, e isso foi finalmente confirmado em 5 de junho, quando o CL0P publicou uma declaração sobre esta campanha em seu blog (Figura 2).
Fig. 2: O grupo de ransomware CL0P reconhece o envolvimento na campanha da MOVEit
Escopo dos ataques
No momento em que o ataque foi descoberto e investigado, o Shodan identificou aproximadamente 2.500 servidores voltados para a Internet executando o MOVEit (Figura 3).
Fig. 3: Uma consulta ao Shodan mostrou mais de 2.500 servidores voltados para a Internet executando uma versão vulnerável do MOVEit
A Progress Software informou que todos os servidores que executavam o MOVEit estavam vulneráveis e que não existia nenhum patch no momento do ataque intenso. Portanto, é seguro presumir que o número de vítimas é substancial. Já foi confirmada a violação de várias organizações e muitas outras provavelmente irão surgir nos próximos dias.
Cadeia de exploração
Muitas informações foram publicadas sobre essa vulnerabilidade. No entanto, os detalhes completos da exploração ainda não se tornaram públicos. Com base nas informações públicas, na análise feita pelo Grupo de inteligência de segurança da Akamai e nos dados vistos em nossos registros, temos uma ideia sólida de como o moveitisapi.dll está sendo usado para executar o SQLi.
Além disso, nossa equipe se reuniu com a equipe de segurança da Progress para uma sessão de compartilhamento de informações na qual compartilhamos nossa análise e outras informações relacionadas aos indicadores de comprometimento (IOCs). Com base nessa reunião, podemos confirmar que o Adaptive Security Engine da Akamai está protegido e continua a proteger nossos clientes mútuos contra esse ataque.
Podemos publicar mais detalhes sobre nossa cadeia de análise e exploração assim que tiver passado tempo suficiente para permitir a aplicação de patches.
Ocultação da operação
O grupo CL0P fez várias tentativas de permanecer indetectável e complicar a análise.
Primeiro, o nome do Web shell carregado era "human2.aspx", que é muito semelhante ao arquivo legítimo do MOVEit que implementa a interface da Web: chamado "human.aspx".
Segundo, acessar o Web shell exigia o envio de uma senha pelo cabeçalho "X-siLock-Comment". Se não houvesse cabeçalho ou a senha estivesse incorreta, o Web shell retornaria a seguinte resposta: erro 404 Not Found. Muitas vezes, a maneira mais fácil de encontrar um Web shell é enviar uma solicitação GET simples. Se a página não existir, será retornado o erro 404. O fato de o Web shell retornar um erro 404 apenas impede a forma mais fácil de descoberta. Com algumas etapas adicionais, você pode comparar a resposta do erro 404 do Web shell com a resposta 404 normal do servidor e ver a diferença entre as duas.
Terceiro, os cabeçalhos usados para controlar o Web shell e enviar explorações usavam nomes muito semelhantes aos nomes de cabeçalho originais da MOVEits. Por exemplo, "X-siLock-Comment" é usado para transmitir a senha do Web shell. Outras informações do banco de dados do MOVEit foram exfiltradas por meio de cabeçalhos de nomes semelhantes: “X-siLock-Step2" e "X-siLock-Step3".
Detecção de exploração
As tentativas de exploração podem ser identificadas de várias maneiras.
Indicadores conhecidos de comprometimento (IOCs)
A Progress Software e a comunidade de segurança publicaram muitos indicadores baseados em host e rede de comprometimento , incluindo endereços IP, hashes de arquivos e regras YARA.
Os administradores de rede podem inspecionar o tráfego de rede e os registros do IIS e verificar ativos na rede para encontrar IOCs conhecidos e, assim, identificar máquinas exploradas.
Os clientes do Adaptive Security Engine podem inspecionar os registros do WAF em busca de sinais de exploração. Se os hosts do MOVEit foram visados, eles devem ver acionadores de grupo de ataque SQLi direcionados a "/moveitisapi/moveitisapi.dll".
Busca por ameaças
Os servidores que executam o software vulnerável devem ser investigados e verificados quanto a comportamento irregular, mesmo que IOCs conhecidos não tenham sido detectados neles. Por exemplo, depois de inspecionar a carga útil usada pelos invasores, vemos que ela resultou em um Web shell aspx que foi transferido para o diretório raiz do servidor em <DriveLetter>: \MOVEitTransfer\wwwroot\. O Web shell implantado na campanha de ataque original foi nomeado human2.aspx, mas este indicador pode facilmente mudar.
Em vez de depender apenas de IOCs estáticos, recomendamos o uso de métodos de busca de ameaças baseados em anomalias em servidores vulneráveis. Nesse caso específico, uma abordagem poderia ser verificar o diretório raiz do servidor MOVEit para encontrar quaisquer arquivos aspx que foram criados recentemente. Os arquivos aspx são de natureza relativamente estática e geralmente não são modificados ou criados, portanto, uma nova adição pode ser suspeita e deve ser investigada. Caminhos de arquivo suspeitos adicionais foram publicados em um comunicado inicial da Progress e em um recente
comunicado da #StopRansomware.
Os clientes do Akamai Guardicore Segmentation podem usar a consulta Insight ilustrada na Figura 4 para localizar esses arquivos.
Fig. 4: Consulta Insight para localizar arquivos aspx que foram criados recentemente
Observe que a letra da unidade (C:\) e o caminho de instalação podem variar; essa consulta só cobrirá o caminho de instalação padrão.
O Akamai Hunt, serviço gerenciado de busca de ameaças da Akamai, realizou verificações completas dos ambientes dos clientes para detectar ativos vulneráveis, tentativas de exploração e IOCs associados à campanha de ataque. Nos casos em que os componentes do MOVEit foram encontrados, os pesquisadores da Hunt informaram as equipes relevantes e ajudaram a mitigar a ameaça imediatamente (Figura 5).
Fig. 5: Alerta do Hunt relacionado a uma tentativa de exploração do MOVEit detectada em um ambiente de cliente
Mitigação
Infelizmente, as vulnerabilidades de software são inevitáveis, mas as organizações podem fazer muito para se protegerem contra esse tipo de violação.
Mapear servidores voltados para a Internet
Antes de conseguir mitigar o ataque, os defensores primeiro precisam identificar quais aplicações sensíveis voltadas para a Internet estão sendo executadas. No caso do MOVEit, todos os clientes vulneráveis foram informados sobre a vulnerabilidade pela Progress. No entanto, ainda é essencial estar ciente de sua superfície de ataque externa e identificar todas as aplicações confidenciais que estão expostas à Internet. Depois de identificar essas aplicações, as seguintes etapas de mitigação podem reduzir o risco de comprometimento das aplicações.
Limitar o acesso à Internet
Reduzir a superfície de ataque deve ser a prioridade máxima. Se não houver motivo justificado para o acesso não autorizado à Internet para uma aplicação, ela deve ser protegida com controles de acesso baseados no usuário, que podem ser obtidos por meio de ZTNA (Acesso à rede Zero Trust) ou produtos VPN tradicionais.
Se for necessário acesso não autorizado à Internet para alguns casos de uso, recomendamos que você execute um servidor de aplicações externo separado, limite os dados armazenados nele ou acessíveis a partir dele e segmente os dados da rede interna o máximo possível. Dessa forma, mesmo que o servidor de aplicações seja violado, o raio da explosão será limitado.
Bloqueio de exploração com um WAF
As aplicações com interfaces da Web devem ser colocadas atrás de um WAF, pois ele pode bloquear solicitações irregulares e suspeitas e bloquear potencialmente a exploração de vulnerabilidades de dia zero anteriormente desconhecidas.
De acordo com o nosso conhecimento atual e compreensão da cadeia de exploração, o Akamai Adaptive Security Engine oferece proteção contra esse ataque com o grupo de ataques SQLi. Especificamente, identificamos instâncias em que o Adaptive Security Engine impediu que invasores explorassem a vulnerabilidade SQLi. As solicitações bloqueadas se originaram dos IPs listados nos IOCs conhecidos.
Evitar o movimento lateral com segmentação
Os servidores voltados para a Internet geralmente podem ser o ponto de entrada dos invasores na rede. Sabendo disso, esses servidores devem ser tratados de acordo e mantidos em um segmento separado, limitando a capacidade do invasor de executar o movimento lateral dentro da rede.
Por exemplo, uma regra pode ser criada para bloquear todas as conexões de saída de servidores voltados para a Internet através de portas de gerenciamento (Figura 6).
Fig.6: Um exemplo de regra no Akamai Guardicore Segmentation para bloquear tentativas de movimentação lateral
Dessa forma, se um invasor violar o servidor, seria impossível executar o movimento lateral nessas portas. Regras adicionais que abrangem aplicações confidenciais e outras portas de gerenciamento devem ser criadas para limitar a superfície de ataque desses servidores o máximo possível. Lembre-se de que essas regras também podem interromper operações normais de rede, portanto, você deve ter cuidado ao criar essas regras e adicionar exclusão ao tráfego existente necessário para operações diárias.
Até o próximo ataque?
O MOVEit é mais um caso de exploração de vulnerabilidade de dia zero de um serviço de transferência de arquivos gerenciados (MFT). Até o momento, o grupo de ransomware CL0P se tornou notório por esse tipo de atividade. Anteriormente, eles exploravam vulnerabilidades nos aplicativos GoAnywhere, SolarWinds Serv-Ue Accellion para roubar dados e extorquir as vítimas. Eles também exploravam vulnerabilidades adicionais em outros aplicativos voltados para a internet.
Na verdade, se qualquer uma das principais soluções MFT estiver instalada em sua rede, é bastante seguro afirmar que, ao ler essa frase, um hacker altamente qualificado e motivado em algum lugar do mundo esteja estudando esses aplicativos e tentando encontrar brechas de segurança. Parece ser apenas uma questão de tempo até que uma nova campanha de exploração seja lançada pelo grupo CL0P, e outros grupos provavelmente seguirão o mesmo caminho.
