O píxel 1x1 que rouba cartões: o novo ataque Magecart em Magento

Uma operação de roubo de dados colocou em perigo cerca de uma centena de lojas online que funcionam com a plataforma Magento: o código malicioso que sustrae números de cartão está escondido em um pixel e disfarçado como um elemento Scalable Vector Graphics (SVG). A investigação que tirou à luz esta campanha a publicou a assinatura de segurança eCommerce Sansec, cujos técnicos detalham como os atacantes conseguem injetar e executar o skimmer sem deixar referências externas que muitas ferramentas de detecção se marcam.

A técnica é aparentemente simples e, ao mesmo tempo, engenhosa: o skimmer vive integralmente online dentro de um SVG de 1×1 píxel que inclui um atributo onload. Esse manejador contém a carga útil codificada em base64, decodificada comatob ()e executada depois por um temporizador; deste modo evita-se as marcas<script>externas e a maioria dos scanners automatizados não o detectam facilmente. Sansec descreve esta tática como uma forma de manter todo o malware “encapsulado” em um único atributo, sem referências a arquivos alheios ao site.

Na prática, quando um comprador legítimo carrega o botão de pagamento numa loja comprometida, um JavaScript malicioso intercepta essa ação e mostra uma janela emergente que simula ser um processo de pagamento seguro. A sobreposição inclui os campos habituais para os dados do cartão e da facturação e efectua verificações em tempo real - por exemplo, a verificação com o algoritmo de Luhn - para validar que os números apresentados parecem corretos. Os dados capturados são embalados em JSON, ofuscados com base64 e aplicam-se operações simples como XOR antes de serem enviados para o atacante.

Sansec rastreou a exfiltração até seis domínios que recebiam a informação e verificou que todos estavam hospedados em IncogNet LLC (AS40663) nos Países Baixos, com cada domínio recebendo dados de dez a quinze vítimas confirmadas. Em campanhas relacionadas aos atacantes, tinham usado mesmo WebRTC como canal de saída para evitar detecções baseadas em pedidos HTTP clássicos.

Os pesquisadores acreditam que a porta de entrada para essa onda foram explorações da vulnerabilidade conhecida como PolyShell, divulgada em meados de março; esta falha afeta instalações de Magento Open Source e Adobe Commerce em versões estáveis 2.x e permite a execução de código sem autenticar e a tomada de controle de contas. Por agora, a Adobe só incluiu a correção em uma versão pré-release (2.4.9‐alpha3+), pelo que muitas lojas em produção permanecem potencialmente vulneráveis. No contexto da gravidade e dos antecedentes destes ataques tipo “Magecart” pode ser consultada a entrada geral sobre o fenómeno Wikipédia.

Sansec indica uma série de sinais e ações concretas para administradores de lojas que podem ajudar a detectar e mitigar este ataque. Entre as faixas mais diretas está a presença de etiquetas SVG com um atributoonloadinvoqueatob (); essa cadeia é um bom ponto de partida para procurar injeções. Outra marca de compromisso para revisar no navegador é a existência da chave_mgx_ cvem localStorage, pois sua presença pode indicar que os dados de pagamento foram armazenados pela carga maliciosa. Recomenda-se também a monitorização e o bloqueio dos pedidos de rotas invulgares como/fb_metrics.phpou domínios que se façam passar por serviços de análise e, se necessário, filtrar tráfego para IP 23.137.249.67 e domínios relacionados.

Além destas detecções pontuais, há medidas operacionais que devem ser aplicadas sem demora. Se o site for vulnerável a PolyShell, é imprescindível aplicar todas as mitigações disponíveis imediatamente e, quando possível, atualizar à versão que inclui a correção ou se mover para um ramo seguro. Os administradores devem rever a integridade de arquivos no servidor comparando com cópias conhecidas limpas, auditar contas e credenciais administrativas, forçar a mudança de senhas e chaves APIs, e aplicar regras no WAF para bloquear padrões de injeção inline. Também é boa prática notificar os fornecedores de pagamento e preparar um plano de resposta para clientes se o roubo de dados for confirmado; a legislação PCI e as leis de proteção de dados obrigam a certos tipos de respostas coordenadas.

Para os compradores habituais há precauções simples que reduzem o risco: usar métodos de pagamento externos quando possível (por exemplo, serviços que tokenizam o cartão), preferir cartões virtuais ou de um único uso para compras online e monitorar movimentos no extrato bancário após comprar. Se ao pagar aparecer uma janela emergente que pede novamente os dados do cartão ou que parece “estranha” no fluxo da loja, convém fechar a operação e contactar o comércio por outro canal antes de tentar pagar novamente.

No plano institucional, este incidente sublinha a necessidade de os fornecedores de plataformas agirem rapidamente diante de vulnerabilidades críticas e de que as equipes de operações mantenham processos de detecção que não dependem apenas de assinaturas em arquivos externos. Ferramentas que inspecionam scripts inline, controles de integridade no servidor e uma estratégia de implantação que limite mudanças diretas em produção ajudam a reduzir a superfície de ataque.

Se você quiser aprofundar o relatório técnico original, a publicação de Sansec contém as amostras e diagramas do payload: Sansec — SVG onload Magecart skimmer. Para entender melhor o algoritmo que os skimmers usam para validar números de cartão em tempo real, a explicação do algoritmo de Luhn está disponível em Wikipédia. E para verificar as notas de versão e documentação do Adobe Commerce, consulte a seção de release notes da plataforma. Adobe Commerce release notes.

Este episódio é um lembrete de que as ameaças no comércio eletrônico nem sempre se escondem em arquivos evidentes ou em chamadas a domínios externos; às vezes a ameaça cabe em um píxel e depende da rapidez com que administradores e fornecedores apliquem adesivos e controles para que esse píxel deixe de ser uma armadilha.