Xurum: Nova campanha contra a Magento descoberta

O comércio digital é um setor muito visado para os criminosos virtuais em geral, mas a popularidade generalizada da Magento infelizmente a tornou um alvo especialmente atraente (e lucrativo). O ataque específico mais notável é o Magecart,  no qual os invasores pretendem implantar skimmers baseados em JavaScript para adquirir ilicitamente informações confidenciais do usuário. Esses agentes de ameaças Magecart aproveitam as conhecidas vulnerabilidades da web para obter essa aquisição.

Há pelo menos sete grupos de ameaças que têm como alvo as lojas Magento desde 2015, o que demonstra a proeminência da plataforma e o sucesso que os agentes de ameaças obtiveram com essa exploração.

No início de 2022, a vulnerabilidade CVE-2022-24086 surgiu, permitindo que os invasores explorassem o mecanismo de modelo da Magento e executassem o código PHP arbitrário em alvos suscetíveis. A exploração opera por meio de várias etapas, com vetores de ataque comuns envolvendo o abuso do processo de check-out ou da funcionalidade da lista de desejos. Desde sua divulgação, essa vulnerabilidade surgiu como um ponto de entrada principal para vários atores Magecart que visam as lojas vulneráveis Magento 2.

Nos últimos meses, a Akamai vem monitorando de perto uma campanha focada que visa especificamente um número relativamente pequeno de implantações Magento. Apelidamos de campanha Xurum para fazer referência ao nome de domínio do servidor C2 utilizado pelos invasores.

Durante a campanha em andamento, observamos invasores tentando executar duas cargas úteis distintas de um total de quatro endereços IP (Figura 1). Esses IPs estão associados à infraestrutura de dois provedores de hospedagem: Hetzner na Alemanha e Shock Hosting nos Estados Unidos.

Durante nossa investigação sobre o servidor xurum.com, ficou evidente que ele está fisicamente localizado na Holanda (Figura 4) e hospedado pela empresa de hospedagem russa chamada VDSina.ru (Figura 5).

Como há várias iterações desse ataque, optamos por chamá-lo de xurum para distinguir esta campanha de outras.

Frequentemente, os invasores empregam convenções de nomenclatura distintas para seus domínios ou malware, que, inadvertida ou deliberadamente, servem como sua assinatura distinta. Durante nossa investigação sobre o possível significado de "xurum," encontramos duas interpretações em potencial.

A definição do Google Tradutor para xurum é "certo" em latim, o que implica "fazer o que é certo" (Figura 7). Por outro lado, o WordSense Dictionary indica que xurum é a palavra para "menino" em um idioma extinto falado na Guatemala (Figura 8).

Observe que, no momento da redação desta postagem no blog, os invasores retiraram o servidor xurum e fizeram a transição para outro que parece ainda estar na fase de garantia de qualidade.

O script PHP mal-intencionado que está sendo baixado do servidor xurum e executado na máquina vítima tem vários estágios de infecção.

Em primeiro lugar, ele coleta informações técnicas sobre a vítima, como:

• versão de PHP

• Se a exploração atingiu o diretório "/pub(estrutura de diretório comum na Magento)

• Se o arquivo "/var/www/html/vendor/magento/google-shopping-ads/registration.php"  existe e é gravável 

• O conteúdo do arquivo "env.php", que inclui informações cruciais do aplicativo da Magento, como configurações específicas do ambiente, mas também segredos como a chave de criptografia usada para proteger dados confidenciais, como senhas, detalhes de cartão de crédito e informações do cliente

Em seguida, ele decodifica um blob ofuscado de Base64 e o grava no arquivo "/var/www/html/vendor/magento/google-shopping-ads/registration.php(Figura 9).

O novo arquivo contém um conteúdo intrigante. Em vez de manter sua própria cópia de um web shell e hospedá-la em seu servidor C2, o código no novo arquivo aponta para um repositório público do GitHub de propriedade de um pesquisador de segurança chamado "Bad Advertiser" ou "e@0xbadad". Dentro desse repositório, há um web shell conhecido chamado wso-ng. No entanto, o que torna isso especialmente interessante é que o web shell não está sendo gravado no disco do servidor. Em vez disso, ele é pesquisado e executado apenas na memória quando a página "registration.php" recém-criada é acessada. Para proteger ainda mais contra o acesso não autorizado, os invasores também precisam da presença de um cookie "magemojo000" específico na solicitação para que o web shell seja executado com êxito.

Em seguida, o invasor registra a nova funcionalidade de web shell como um novo componente da Magento mascarado como "GoogleShoppingAds" (Figura 10).

Depois de instalar o backdoor, os atacantes recuperam informações sobre os métodos de pagamento de pedidos de vendas nos últimos 10 dias e exfiltram esses dados para a zona de descarte xurum.com, juntamente com as informações técnicas coletadas anteriormente (Figura 11).

Na etapa final, os invasores criam um usuário administrador de backdoor com o nome "mageworx" (ou "mageplaza" em algumas variações). Esses nomes correspondem a lojas de extensões populares da Magento 2, Mageworx e Mageplaza (Figura 12). Essa escolha de nomes parece ser uma tentativa de camuflar suas ações como algo legítimo relacionado a esses fornecedores de extensão respeitáveis.

Observe uma nuance interessante nos endereços de e-mail dos usuários do backdoor. Há um "z" duplo em "mageplazza" no endereço de e-mail developer@mageplazza.com, embora o domínio legítimo da loja tenha um único "z" em seu nome mageplaza.com, que parece um erro de digitação pelos invasores. Um erro de digitação semelhante foi feito no outro endereço de e-mail do usuário de backdoor: support@magaworx.com,  com um "a" em vez de um "e" como no nome original da loja Mageworx.

Um web shell é um script mal-intencionado ou um trecho de código que os invasores carregam e executam em um servidor da Web para obter acesso não autorizado e controle sobre o servidor e seus arquivos e dados subjacentes de forma persistente.

Nesta operação, os invasores estão aproveitando a avançada web shell chamada wso-ng, que, como mencionado acima, foi criada por um pesquisador de segurança há vários anos. Conforme declarado pelo autor, wso-ng é uma nova geração do WSO mais antigo e famoso (que significa Web Shell por Orb). 

Além da funcionalidade típica encontrada em web shells, como coleta de informações do sistema e gerenciamento de arquivos e SQL, o wso-ng tem outros recursos notáveis que fazem com que ele se destaque (Figura 13).

Um desses novos recursos é a página de login oculta. Ao acessar a página, ela responde com um código de status HTTP 404 Not Found, dando a impressão de uma página inexistente. O conteúdo visível parece estar em branco à primeira vista (Figura 14). No entanto, ao inspecionar o código-fonte da página, ele revela um formulário de login oculto.

O formulário é inteligentemente oculto do visualizador usando um truque CSS simples, onde é deslocado 1.000 pixels para a esquerda, efetivamente mantendo-o fora da área visível. Este formulário de login oculto foi projetado para aguardar o usuário digitar a senha.

Encontramos outra ferramenta interessante no arsenal dos atacantes no servidor xurum.com: uma exploração pública de uma CVE-2016-5195 mais antiga chamada Dirty COW para escalonamento de privilégios locais no Linux (Figura 15).

Como muitos de nossos clientes do web application firewall (WAF) efetivamente mitigaram esta campanha, não observamos diretamente outras ações tomadas pelos agentes de ameaça. No entanto, durante nossa investigação, notamos nomes de sites que estavam indiretamente relacionados a esta campanha e que mostraram no cabeçalho HTTP de origem/referencial da solicitação de exploração.

Pelo menos um desses sites foi infectado por um simples Web skimmer. O skimmer foi instalado na página principal e não aplicou nenhuma técnica de ofuscação. Ele coletava informações do cartão de crédito e as extraia para uma zona de descarte hospedada em "smileface.site" (Figura 16).

Na tentativa de acesso, esse site responde com uma mensagem fria "Saia!" (Figura 17).

As informações de IP mostram que o servidor está localizado em Moscou e hospedado pela empresa russa de hospedagem "reg.ru" (Figura 18).

Nossa investigação sobre essa campanha indica que ela remonta, pelo menos, ao final de janeiro de 2023. Os invasores mostraram uma abordagem meticulosa, visando instâncias específicas da Magento 2 em vez de pulverizar indiscriminadamente suas explorações na Internet. Eles demonstram um alto nível de especialização na Magento e investem um tempo considerável na compreensão de seus componentes internos, na configuração da infraestrutura de ataque e no teste de suas explorações em alvos reais.

Esta campanha serve como um exemplo prático de como as vulnerabilidades mais antigas continuam a ser exploradas anos após a divulgação, à medida que as empresas se esforçam para acompanhar os patches e as medidas de segurança.

Para evitar o acesso inicial ao servidor, os profissionais de segurança são aconselhados a se manter atualizados com os patches mais recentes e complementá-los com a implementação de um WAF, como o Akamai App & API Protector.

Como o objetivo primário desses agentes de ameaças Magecart é infectar páginas da Magento com Web skimmers e roubar informações de cartão de crédito dos clientes, soluções de segurança dedicadas adicionais são altamente recomendadas. Essas soluções devem fornecer visibilidade dos comportamentos de script do navegador e oferecer defesa contra ataques do lado do cliente.

Uma abordagem eficaz envolve a implantação de medidas de segurança mais próximas de onde ocorrem os ataques reais aos clientes. Isso inclui a identificação de tentativas de leitura de campos de entrada confidenciais e exfiltração de dados. Sugerimos a coleta imediata desses eventos para facilitar a mitigação rápida e eficiente com a ajuda de produtos de segurança, como o Akamai Page Integrity Manager,.

Durante nossa análise das recentes tentativas de exploração Magento CVE-2022-24086 em nossos clientes, descobrimos campanhas adicionais que estão sendo investigadas no momento. Continuaremos a investigar mais e compartilhar nossas descobertas com a comunidade de segurança. Para ver mais pesquisas de segurança inovadoras, siga-nos no Twitter.

Os seguintes indicadores de comprometimento (IOCs) são apresentados para ajudar a comunidade a detectar a atividade mal-intencionada descrita na postagem.