Hacker explora vulnerabilidade no Magento através do Google Tag Manager

Há cerca de cinco dias, a Sucuri publicou um artigo sobre uma vulnerabilidade em sites Magento, onde o Google Tag Manager (GTM) foi usado para injetar um script malicioso – um skimmer de cartões de crédito – comprometendo dados sensíveis. Esse caso recente ressalta que, sem auditoria e monitoramento de scripts, até ferramentas robustas podem ser exploradas.

Primeiro de tudo, o que é um Skimmer?

Um skimmer é um tipo de malware que intercepta dados sensíveis em formulários de e-commerce, como números de cartões de crédito, durante o checkout. Esses scripts furtivos capturam as informações para fraudes financeiras, impactando a segurança e a credibilidade da empresa.

O Risco de Carregar Scripts Sem Saber o Que Está Fazendo

Eu sempre digo: o Google Tag Manager pode ser uma ferramenta poderosa, mas também pode causar grandes problemas. Muitas vezes, scripts de afiliados ou mídia programática são inseridos sem revisão, o que é perigoso. Essa prática expõe a importância de integrar marketing e tecnologia para garantir segurança.

O Perigo do Carregamento Encadeado de Scripts

Outro ponto crítico é o carregamento em cadeia de scripts, quando um script aciona outros em sequência, dificultando o controle e abrindo espaço para ameaças. Isso é comum em campanhas de mídia programática ou tags de conversão, onde um único script pode carregar outros sem supervisão.

Exemplo de Carregamento Encadeado de Scripts

Aqui está um exemplo prático de uma tag HTML personalizada no GTM que demonstra esse encadeamento:

<script>
  (function() {
    // Cria o primeiro script (scriptA) e define sua origem
    var scriptA = document.createElement('script');
    scriptA.src = 'https://example.com/scriptA.js';

    // Ao carregar scriptA, cria e carrega scriptB
    scriptA.onload = function() {
      var scriptB = document.createElement('script');
      scriptB.src = 'https://example.com/scriptB.js';

      // Ao carregar scriptB, cria e carrega scriptC
      scriptB.onload = function() {
        var scriptC = document.createElement('script');
        scriptC.src = 'https://example.com/scriptC.js';
        document.body.appendChild(scriptC);
      };
      document.body.appendChild(scriptB);
    };
    document.body.appendChild(scriptA);
  })();
</script>

Esse código mostra como um único script pode carregar outros em sequência, dificultando o rastreamento de scripts maliciosos.

E essa é a pratica adotada por um monte de scripts maliciosos para te confundir sobre aonde está o malware, tipo um aonde está Wally só que de programador, kkk.

Isso me fez lembrar inclusive de uns caso onde identificamos nesse encadeamento de script a manipulação de cookies de atribuição do Google Analytics 4, mudando completamente a maneira com que o Google Analytics identificava as sessões beneficio próprio do coleguinha de midia, vou deixar aqui alguns pontos inclusive de como voce identificar esse tipo de pratica.

Aqui está um exemplo esdrúxulo e com fins didáticos de um script encadeado que, ao ser carregado, manipula os cookies do Google Analytics 4 de forma irregular:

<script>
  (function() {
    // Cria o scriptA (inicial)
    var scriptA = document.createElement('script');
    scriptA.src = 'https://example.com/scriptA.js';
    
    // Ao carregar scriptA, injeta scriptB
    scriptA.onload = function() {
      var scriptB = document.createElement('script');
      scriptB.innerHTML = `
        document.cookie = '_ga=12345.67890; path=/;'; // Sobrescreve o cookie GA4 de forma tosca
        console.log('MUUAHAHAHAHAHA, sua atribuição é minha' );
      `;
      
      // Adiciona scriptB ao documento
      document.body.appendChild(scriptB);
    };
    
    // Adiciona scriptA ao documento
    document.body.appendChild(scriptA);
  })();
</script>

Esse script encadeado demonstra uma manipulação simples (e esdrúxula) do cookie

_ga

E é por isso que times programadores te odeiam e criam grupo para falar mal de você kkk

Por que no final quem vai ter que consertar um erro de uma tag que ele não fazia idéia que existia, de algo que ele nem sabia que o time de marketing tinha autonomia para fazer é ele.

Imagine que você é um analista de marketing cuidando de uma campanha de e-mail. De repente, as métricas despencam, mas ninguém te avisou que a equipe de TI trocou a ferramenta de envio sem avisar. Agora, você precisa descobrir sozinho o que aconteceu, corrigir e ainda lidar com o impacto nos seus relatórios. É exatamente esse tipo de frustração que os programadores sentem quando descobrem que uma tag misteriosa foi inserida sem controle ou alinhamento.

E tem solução? Bem o que temos não é bem uma solução e sim uma maneira de restringir quais tipos de tags podem ser implementadas dentro do nosso Google Tag Manager, mas é muito importante que antes disso a gente tenha um papel preventivo e não restritivo. Primeiro vamos ao preventivo:

Como evitar esse tipo de problema com auditoria constante e práticas preventivas

Para evitar que scripts maliciosos ou não autorizados sejam implementados, é fundamental estabelecer um processo de auditoria contínua. Aqui estão algumas práticas preventivas:

• Auditorias Periódicas: Revise todas as tags e scripts implementados no GTM regularmente.
• Revisões de Permissões: Garanta que apenas pessoas autorizadas possam adicionar ou editar tags.
• Documentação de Alterações: Mantenha um changelog detalhado de todas as atualizações no GTM.
• Integração entre Equipes: Promova reuniões regulares entre marketing e tecnologia para alinhar estratégias e evitar surpresas.

Essas medidas ajudam a manter um ambiente mais seguro e previsível, reduzindo o risco de problemas como os citados acima.

E ai do ponto restritivo qual é o tipo de solução? O Google Tag Manager tem um recurso de restrição de tags que é o gtm.blocklist que permite você restrigir la no código fonte o tipo de tags que você vai deixar habilitadas para o time de marketing utilizar, ou parceiros de mídia. O ponto importante que faz com que seja muito recomendado a abordagem preventiva é essa "restrição" é aplicada a todo o container e não a um usuário especifico, entende? Mas casos extremos precisam de medidas extremas, então vamos lá.

Como funciona gtm.blocklist?

O gtm.blocklist funciona restringindo a implantação de tags no Google Ta Manager através da propria camada de dados. Ele impede que determinados tipos de tags, variáveis ou acionadores sejam disparados, mesmo que estejam configurados no contêiner. A configuração é feita diretamente na

dataLayer

<script>
  window.dataLayer = window.dataLayer || [];
  dataLayer.push({ 
    'gtm.allowlist': ['tagA', 'tagB'], // Permitir apenas essas tags
    'gtm.blocklist': ['html', 'customScripts'] // Bloquear tags HTML personalizadas e scripts customizados
  });

</script>

• gtm.allowlist

  : Permite somente as tags listadas.

• gtm.blocklist

  : Bloqueia as tags especificadas.
• Prioridade: O

  gtm.blocklist

  tem prioridade sobre o

  gtm.allowlist

  .

E como evitar esse tipo de problema?

Como já falei acima não vou chover no molhado por aqui e falo sempre no podcast: " Se o pica pau tivesse chamado a policia nada disso teria acontedido"\

• Audite seus scripts periodicamente: A fim de Identificar e remover scripts suspeitos.
• Monitore comportamentos anômalos: Como múltiplas sessões ou spikes de eventos.
• Manter integração com o time de tecnologia: Unificar conhecimento entre marketing e TI e principalmente trazer ou disponibilizar um recurso no teu time que .

No fim, o Google Tag Manager é apenas uma ferramenta. Mas como qualquer ferramenta potente, seu uso descuidado pode gerar grandes problemas.