Resumo: deteção de skimmers digitais no checkout
- A monitorização avisa tarde: A maior parte das ferramentas de segurança client-side afirma detetar skimmers digitais, mas apenas inspecionam os scripts depois de o navegador já os ter carregado, o que significa que o alerta chega exatamente no mesmo momento em que os dados do cartão do utilizador saem da página.
- A cside bloqueia antes de renderizar: O agente JavaScript first-party da cside observa o comportamento em tempo de execução (runtime) de cada script de terceiros no navegador — leituras de DOM, chamadas de rede, mutações — e bloqueia o comportamento de skimmer antes que o payload malicioso consiga renderizar o formulário de cartão falso, sem amostragem e com bloqueio autónomo adicional.
- Onde recai a responsabilidade: Antes de os auditores do PCI DSS 4.0 começarem a questionar os scripts de terceiros nas suas páginas de pagamento, decida se ferramentas apenas de monitorização, que alertam depois da execução, transferem realmente a responsabilidade da sua conta de comerciante.
Sem tempo? Veja o bloqueio de Magecart e skimmers no navegador da cside. Cobre tudo o que se segue numa única implementação.
Recentemente, soubemos de uma nova e significativa campanha de ciberataques que teve como alvo centenas de lojas online, explorando vulnerabilidades em scripts e plugins de terceiros.
Este é um exemplo perfeito de um 'skimmer digital'.
Os skimmers digitais são fragmentos de código injetados maliciosamente em sites legítimos. Visam informações pessoais e de cartões de crédito.
Este problema está a aumentar e é parte da razão pela qual o cside foi criado. A cside consegue detetar este código malicioso e impedir que afete os utilizadores nos sites.
Este código é carregado do lado do cliente (o navegador) do utilizador, em vez de no servidor do site. Isto torna-o especialmente difícil de detetar, uma vez que a maioria dos sites não tem uma ferramenta como o cside implementada para proteger a experiência client-side dos seus utilizadores.
A maioria dos nossos concorrentes verifica este código depois de já ter sido carregado no navegador do utilizador, não impedindo o ataque, apenas alertando o site em causa. Nós carregamos primeiro todos os scripts num proxy e, só depois de considerados seguros, os entregamos ao utilizador. Também otimizamos os scripts sempre que possível, para os servir mais rapidamente do que uma Rede de Distribuição de Conteúdo (CDN), mitigando quaisquer problemas de latência. Na verdade, muitas vezes até aumentamos a velocidade de entrega destes scripts.
O que aconteceu neste ataque
Este ataque foi divulgado pela MalwareBytes e foi, até agora, o mais recente de uma série de ataques executados em sites de comércio eletrónico que utilizam Magento.
Não noticiámos este caso porque nenhum dos nossos utilizadores utiliza atualmente o Magento.
Noutras notícias, reparámos recentemente que Malwarebytes(.)fr foi configurado como uma página de venda de domínio, com um registador de IP. Este enviava depois esses dados para um webhook do Discord. Foi rapidamente eliminado ou banido do Discord. Leia aqui porque os domínios expirados podem ser um problema enorme e são frequentemente usados neste tipo de ataques.
Aqui está a evidência desse webhook:
Voltando à história.
Um ataque à cadeia de fornecimento web como este acontece porque os atacantes comprometem o Magento (ou um plugin do Magento) e inserem remotamente uma simples linha de JavaScript. Na maioria destes casos, e de facto também neste mais recente, os atacantes alteram um script legítimo para permanecerem sem serem detetados o máximo tempo possível.
O código também é ofuscado para dificultar ainda mais a compreensão exata do que está a ser executado. Esta é uma forma legítima de proteger código, e as empresas utilizam-na constantemente para proteger o seu código de ser copiado ou adulterado.
A partir daí, o ataque é bastante simples. O código carrega uma função que recolhe informações desse site, que são inseridas e submetidas em todo o tipo de formulários. O domínio dentro do código malicioso recebe-as, e os atacantes ficam então com essa informação.
Neste ataque, o alvo eram os dados de cartões de crédito de pessoas desprevenidas que faziam compras online. Há muito pouco que essas pessoas possam fazer, mas os sites onde o ataque ocorre são responsabilizados e recebem frequentemente coimas do PCI DSS e, por vezes, processos judiciais.
Neste caso, o fluxo de pagamento foi interrompido durante o checkout. Foi inserida uma frame falsa de métodos de pagamento e as pessoas preencheram este formulário em vez do real. Isto foi feito através de uma simples tag de imagem inserida numa única linha de JavaScript.
Isto teria o seguinte aspeto: {domain}.{shop|online)/img/
Os domínios maliciosos encontrados nestes ataques até agora incluem:
- codcraft(.)shop
- codemingle(.)shop
- datawiz(.)shop
- deslgnpro(.)shop
- happywave(.)shop
- luckipath(.)shop
- pixelsmith(.)shop
- salesguru(.)online
- statlstic(.)shop
- statmaster(.)shop
- trendset(.)website
- vodog(.)shop
- artvislon(.)shop
- statistall(.)com
- analytlx(.)shop
Este é mais um ataque que demonstra por que razão as empresas precisam de proteger a experiência client-side dos seus utilizadores. Se os sites tivessem instalado uma ferramenta como o cside, os seus utilizadores teriam estado protegidos.
A regulamentação chegou
Até março de 2025, o PCI DSS 4.0 exige que os sites com checkouts online monitorizem os scripts de terceiros nas suas páginas de pagamento.
Defendemos a monitorização e proteção destes scripts para estar completamente seguro. Escrevemos aqui sobre o risco de proteger apenas as páginas de pagamento e não o site inteiro. Os atacantes vão simplesmente adaptar-se, e com uma rápida reação, os ataques continuarão provavelmente a ocorrer.
Saiba que, ao usar o cside, todo o seu site fica protegido.
Pode começar gratuitamente e ficar seguro em minutos.
