Ataque Magecart disfarçado de Gerenciador de tags do Google
Uma nova e sofisticada campanha Magecart de web skimming foi descoberta em diversos websites de comércio eletrônico. Os ataques Magecart são um tipo de crime cibernético que visa especificamente os varejistas online. Esses ataques envolvem a injeção de código JavaScript mal-intencionado nas páginas de pagamento de websites, que captura as informações confidenciais dos clientes assim que são inseridas e as envia ao servidor do invasor. Essas informações podem incluir números de cartão de crédito e detalhes pessoais.
O ataque recente teve como objetivo roubar informações confidenciais de visitantes em páginas e formulários de pagamento. Os invasores conseguiram injetar um código JavaScript em linha mal-intencionado nos websites visados explorando uma vulnerabilidade. O skimmer usou técnicas como representar um fornecedor terceirizado legítimo, como o Gerenciador de tags do Google, e ocultar o código mal-intencionado por meio da codificação Base64.
O ataque está em andamento em alguns websites e se assemelha ao recente ataque ao maior varejista de bebidas alcoólicas do Canadá.
Visão geral dos ataques
Representação de um código de fornecedor conhecido
O skimmer injeta um código mal-intencionado como um script em linha (um script incorporado ao HTML, não carregado de um arquivo externo) que se assemelha a um snippet de código do Gerenciador de tags do Google (Figura 1). Isso permite que o invasor disfarce o código mal-intencionado como um script legítimo, ocultando-o atrás de um fornecedor conhecido. Encontramos anteriormente diversas campanhas Magecart que empregaram essa técnica evasiva, tornando a detecção mais desafiadora.
Além disso, o skimmer usa a codificação Base64 para ofuscar quaisquer URLs ou palavras-chave que possam revelar o código mal-intencionado. Isso ajuda ainda mais a esconder a presença do skimmer.
Fig. 1: Snippet impostor do Gerenciador de tags do Google
Uso de WebSockets e da função eval
Nesse caso, o snippet em linha serve apenas como um carregador e não como o código de ataque real. O carregador inclui uma condição que aciona o ataque somente em páginas de pagamento, permitindo que o skimmer opere discretamente e carregue o código mal-intencionado completo apenas em páginas visadas e confidenciais que são relevantes para o ataque.
Depois que a codificação Base64 do código do carregador é descriptografada, o código JavaScript revelado é curto e simples, realizando apenas duas etapas: criar uma nova conexão WebSocket com o servidor de comando e controle (C2) do invasor e configurar uma função de escuta que executará o código recebido do C2 com a função "eval" (Figura 2).
Fig. 2: O código codificado que estava escondido no snippet do Gerenciador de tags do Google.
O uso de WebSockets e da função "eval" em ataques Magecart é considerado uma técnica avançada, pois permite que o código mal-intencionado seja executado dentro do contexto da página como um script primário, dificultando a detecção pelos pesquisadores, serviços de segurança e scanners que podem estar operando no website visado (Figura 3). Este método ajuda os invasores a permanecerem ocultos em suas atividades e menos detectáveis do que as solicitações XHR tradicionais ou tags HTML.
Fig. 3: Outra variação do carregador do mesmo separador com o uso de WebSockets
Realização de verificações de código
O início da conexão socket permite que o navegador e o servidor C2 troquem dados a qualquer momento. A primeira mensagem enviada pelo servidor C2 do invasor à página (Figura 4) contém o código JavaScript que é imediatamente executado por uma função de escuta especificada no código do carregador.
O código realiza duas verificações.
- Verifica se uma conexão WebSocket foi estabelecida por meio de uma variável global definida no código do carregador.
- Determina se a página é uma página de pagamento que contém um botão de envio.
Se essas verificações forem aprovadas, o código do invasor enviará uma mensagem ao servidor C2 com o URL da página atual. Em resposta, o servidor C2 retorna o código mal-intencionado apropriado adaptado à página visada específica.
O fato do servidor C2 aguardar um URL de página antes de retornar o código de ataque sugere que esta campanha opera por meio de uma estrutura dinâmica capaz de executar e suportar vários websites e páginas de forma simultânea.
Fig. 4: Conexão WebSocket com o servidor C2 do skimmer
Ofuscação do código
A Figura 5 mostra o código de ataque real conforme obtido do servidor C2 após a validação do URL. O código é fortemente ofuscado, dificultando a determinação da lógica subjacente e da progressão do ataque. Os skimmers Magecart geralmente empregam técnicas de ofuscação para dificultar que os especialistas em segurança decifrem o código de ataque e compreendam todo o seu fluxo.
Fig. 5: O código de ataque ofuscado enviado pelo servidor C2 pela conexão WebSocket
Limpeza do código
O uso de uma ferramenta de desofuscação esclarece a situação e revela a intenção por trás do ataque. Como mostrado na Figura 6, o código contém uma grande variedade de palavras-chave projetadas para identificar campos confidenciais na página visada e estabelecer um formulário de pagamento falsificado controlado pelo invasor.
O objetivo final do invasor é roubar informações pessoais de visitantes desavisados que interagem com a página infectada e preenchem o formulário falso injetado pelo código do invasor.
Fig. 6: Código de ataque após desofuscação
Inserção de formulários falsos para provedores terceirizados
Algumas lojas visadas terceirizam o processo de pagamento para um provedor terceirizado. Quando os clientes fornecem informações pessoais, eles são redirecionados para o fornecedor terceirizado para inserir as informações do cartão de crédito e concluir a transação. O skimmer não consegue acessar o fornecedor terceirizado para obter as informações do cartão de crédito do usuário final.
Em vez disso, ele cria um formulário falso de cartão de crédito na página antes de redirecionar o cliente para o fornecedor terceirizado (Figura 7). Quando o usuário clica no botão "Finalizar" ou "Enviar pagamento" falso, o skimmer envia todos os dados coletados para seu servidor C2 e permite que o usuário continue com o fluxo de pagamento legítimo redirecionando para a página real de pagamento do fornecedor terceirizado.
Fig. 7: Formulário falso criado pelo skimmer
Se o website visado não redirecionar para uma página de pagamento de terceiros, o skimmer não criará um novo formulário. Em vez disso, ele adicionará ouvintes JavaScript a todas as informações confidenciais inseridas na página e nos formulários de pagamento. Assim que o usuário enviar as informações, o skimmer extrairá os dados e os enviará para seu servidor C2 usando as mensagens de WebSockets.
Em ambos os casos, o skimmer criptografa os dados extraídos para dificultar que os pesquisadores e os serviços de segurança detectem qualquer atividade de rede incomum iniciada por ele (Figura 8).
Fig. 8: Exemplo da mensagem criptografada do skimmer enviada pela conexão WebSocket
Semelhanças dos ataques
Durante a investigação, encontramos vários websites que foram vítimas do ataque. Não podemos confirmar que todos eles estejam relacionados à mesma campanha, mas semelhanças entre os casos sugerem o uso da mesma estrutura Magecart. Em alguns casos, indicadores como o carregador em linha do ataque disfarçado como um falso Gerenciador de tags do Google com parâmetros codificados que ocultavam quaisquer sinais do skimmer foram encontrados em vários websites vítimas.
Os domínios usados pelo invasor variaram de website para website e, na maioria dos casos, o código de ataque real foi obtido pelo código do carregador em páginas relevantes apenas para tornar o ataque mais discreto e difícil de detectar.
Resumo das técnicas e capacidades dos invasores
Representar um snippet de código de fornecedor conhecido, como o Gerenciador de tags do Google
Usar a codificação Base64 para ocultar quaisquer indicadores do invasor, como URLs e domínios
Usar WebSockets para toda a comunicação entre o navegador e o C2, extraindo o código de ataque e exfiltrando os dados
Executar o código de ataque com "eval" para fazer com que o script pareça um script primário orgânico
Usar técnicas de ofuscação para dificultar a compreensão do código pelos pesquisadores
Injetar formulários falsos para coletar dados antes de redirecionar para páginas legítimas de serviços de pagamento de terceiros
Obtenha proteção com o Akamai Page Integrity Manager
Nossa equipe testou o recente ataque Magecart em relação ao Akamai Page Integrity Manager, e o ataque foi imediatamente reconhecido e mitigado. Informações detalhadas foram fornecidas para a solução de problemas (Figura 9).
O Page Integrity Manager foi desenvolvido especificamente para proteger contra web skimming, formjacking e ataques Magecart. Ele fornece visibilidade do comportamento de execução de script de uma página da Web e coleta informações sobre os diferentes scripts em execução na página, incluindo as ações e os relacionamentos com outros scripts.
Ao combinar esses dados com uma abordagem de detecção multicamadas, incluindo heurística, pontuações de risco, inteligência artificial e outros fatores, o Page Integrity Manager é capaz de detectar e defender contra ameaças do lado do cliente de forma rápida.
Fig. 9: Informações detalhadas de solução de problemas do Akamai Page Integrity Manager
Conclusão
Os skimmers Magecart estão em constante evolução e se tornando cada vez mais sofisticados. O uso de métodos avançados de evasão e ofuscação pelo skimmer descrito nesta publicação destaca as dificuldades em detectar esses tipos de ataques.
O constante jogo de gato e rato exige uma solução de segurança abrangente para detectar e prevenir ataques. A não implementação dessa solução pode resultar em sérios danos aos clientes, cuja privacidade pode ser comprometida, e causar danos significativos à reputação de uma empresa, além de render multas consideráveis.
Os novos requisitos contidos no mais recente PCI DSS v4.0 (Payment Card Industry Data Security Standard, Padrão de Segurança de Dados da Indústria de Cartões de Pagamento) agora tornam a segurança no navegador uma necessidade absoluta para qualquer organização que processe cartões de pagamento online.
Saiba mais
O Akamai Page Integrity Manager pode ajudar você a atender aos novos requisitos fornecendo um inventário de todos os scripts em execução em seu website, visibilidade do comportamento de script e defesa contra os mais sofisticados ataques baseados em script.
IOCs
Os seguintes IOCs (Indicadores de comprometimento) são apresentados para ajudar a comunidade a detectar a atividade mal-intencionada e os skimmers descritos no blog:
yachtbars[.]fun
app-stat[.]com
Magento-cdn[.]net
nebiltech[.]shop
Rithdigit[.]cyou
Antohub[.]shop
Okqtfc1[.]org
jquery-node[.]com
Saiba mais sobre como obter visibilidade do comportamento de script e proteção contra ataques do lado do cliente com o Akamai Page Integrity Manager.
