O ataque cibernético à Segway explicado

Resumo: skimmer Magecart via favicon booctstrap na Segway

• Um payload num favicon: Um favicon devia servir pixéis, não payloads. Os atacantes da Segway esconderam um skimmer para Magento dentro de um ficheiro de favicon que apontava para booctstrap[.]com, e todos os threat feeds voltaram a chegar tarde.
• Inspeção do payload completo: O script malicioso apresentava-se como um falso texto de copyright no rodapé, enquanto carregava silenciosamente, a partir do favicon, um skimmer alojado em booctstrap[.]com para capturar os campos do cartão. A cside inspeciona o payload completo de cada script de terceiros antes de o navegador o executar.
• Verifique cada domínio: Se a sua loja Magento carrega algum script pelo nome de um parceiro de design ou de um plugin, verifique cada domínio hoje mesmo. Se não conseguir verificá-los todos, coloque análise de scripts em runtime à frente da loja antes que o próximo atacante esconda um skimmer num recurso de imagem.

Sem tempo? Veja o bloqueio de Magecart e skimmers no navegador da cside. Cobre tudo o que se segue numa única implementação.

Em janeiro de 2022, a loja virtual da Segway sofreu um ataque à cadeia de fornecimento web - também conhecido como ataque Magecart. Neste tipo de ataques, é adicionado código JavaScript malicioso que carrega a partir do lado do cliente, através dos chamados scripts de terceiros.

Muitas ferramentas comuns são scripts de terceiros. Coisas como analytics, captchas e mais. Mas esta via também pode ser usada para fins maliciosos, como foi o caso aqui.

Neste ataque à Segway, a loja está montada em Magento. Os atacantes visaram vulnerabilidades no próprio CMS ou num dos plugins instalados no site da Segway. Depois de violar o sistema, adicionaram o JavaScript que aparentava ser exibido como o copyright do site, mas que, na realidade, era usado para carregar um favicon externo.

Dentro desse ficheiro de favicon, foi colocado um domínio malicioso, 'booctstrap[.]com'. Como se pode ver nesta imagem da Malwarebytes, que revelou este ataque:

Esse domínio carregava o código JavaScript malicioso de terceiros, cujo objetivo era capturar os dados de cartão de crédito das pessoas.

Como visto mais recentemente no ataque ao Polyfill em 2024.

A forma errada de se proteger contra isto

Os threat feeds continuam a ser a solução mais utilizada para resolver este problema, mas defendemos que não é a abordagem preferível. No fundo, eles não sabem aquilo que não sabem. Os atacantes registam um novo domínio e, sem precisarem de reescrever qualquer código, o ataque volta a funcionar. Durante dias, ou por vezes semanas, até ser novamente detetado e os threat feeds atualizarem os seus registos.

A cside foi concebida para travar estes ataques à cadeia de fornecimento web antes de acontecerem.

Ao colocar estes scripts de terceiros num proxy e analisar o payload completo do código antes de este carregar, detetamos código malicioso como o deste exemplo. Bloqueamo-lo, impedindo que afete o utilizador, e alertamos o proprietário do site sobre o potencial ataque.

Também guardamos o código dos scripts para que o proprietário do site o possa consultar após o incidente e resolver o problema subjacente.

Estes ataques do lado do cliente recebem demasiado pouca atenção. Se outras medidas de segurança falharem, como aconteceu no caso da Segway, este ataque ainda assim poderia ter sido detetado. Monitorizar exatamente o que acontece no navegador do utilizador teria permitido detetar e travar a exfiltração de dados.

Regulamentação

Como se vê neste caso, o e-commerce é frequentemente um alvo. E a regulamentação está a acompanhar, com o PCI DSS 4.0, que agora exige a monitorização de scripts de terceiros nas páginas de pagamento (até março de 2025). Embora aplaudamos esta medida, recomendamos vivamente que o faça em todas as páginas de todo o seu site. Já em abril de 2024, explicámos em pormenor por que motivo não o fazer ainda coloca o seu site em risco significativo.

Além de outros problemas explicados nesse artigo, agentes maliciosos poderiam explorar scripts comprometidos no seu site para sequestrar sessões de utilizadores, fazer-se passar por eles e realizar ações não autorizadas, contornando potencialmente a autenticação de dois fatores e, dessa forma, continuando a contornar a proteção do seu portal de pagamento.

Pode usar a cside para monitorizar scripts em todas as páginas e estar em conformidade com essa parte do PCI DSS 4.0. E pode proteger o seu site contra este tipo de ataques com a cside.

Comece gratuitamente em minutos.