Attacco Magecart mascherato da Google Tag Manager
È stata scoperta una nuova e sofisticata campagna di web skimming Magecart su diversi siti web di e-commerce. Gli attacchi Magecart sono un tipo di crimine informatico che prende di mira principalmente i retailer online. Questi attacchi consistono nell'iniettare, nelle pagine di pagamento dei siti web, codice JavaScript dannoso che acquisisce le informazioni sensibili dei clienti non appena vengono inserite e le invia al server del malintenzionato. Tali informazioni possono includere numeri di carte di credito e dati personali.
L'attacco recente mirava a rubare informazioni sensibili ai visitatori nelle pagine relative ai pagamenti e nei moduli. Gli autori degli attacchi hanno iniettato un codice JavaScript inline dannoso nei siti web presi di mira, sfruttando una vulnerabilità. Lo skimmer si è spacciato per un fornitore di terze parti legittimo, come Google Tag Manager, e ha nascosto il codice dannoso tramite la codifica Base64.
L'attacco prosegue su alcuni siti web e ricorda il recente attacco al più grande retailer di bevande alcoliche del Canada.
Panoramica degli attacchi
Impersonificazione di un codice di fornitore noto
Lo skimmer inietta un codice dannoso come script inline (uno script incorporato all'interno del linguaggio HTML e non aggiunto da un file esterno) che assomiglia a un frammento di codice Google Tag Manager (Figura 1). Ciò consente al malintenzionato di mascherare il codice dannoso da script legittimo nascondendolo dietro un fornitore noto. Abbiamo già incontrato in precedenza molteplici campagne Magecart che avevano impiegato questa tecnica evasiva, che ne rende complicato il rilevamento.
Inoltre, lo skimmer utilizza la codifica Base64 per offuscare qualsiasi URL o parola chiave che possa rivelare il codice dannoso. Ciò aiuta ulteriormente a nascondere la presenza dello skimmer.
Figura 1. Frammento falso di Google Tag Manager
Uso di WebSockets e della funzione eval
In questo caso, il frammento inline serve solo da caricatore e non è il codice di attacco effettivo. Il caricatore include una condizione che attiva l'attacco solo sulle pagine di pagamento, consentendo allo skimmer di operare in modo discreto e di caricare il codice dannoso completo solo sulle pagine sensibili rilevanti per l'attacco.
Una volta decodificata la codifica Base64 del codice caricatore, il codice JavaScript rivelato è breve e semplice ed esegue due soli passaggi: crea una nuova connessione WebSocket con il server di comando e controllo (C2) del malintenzionato e configura una funzione listener che eseguirà il codice ricevuto dal server C2 con la funzione "eval" (Figura 2).
Figura 2. Codice codificato nascosto all'interno del frammento di Google Tag Manager.
L'uso di WebSockets e della funzione "eval" negli attacchi Magecart è considerata una tecnica avanzata in quanto consente di eseguire il codice dannoso all'interno del contesto della pagina come script di prima parte, rendendone più difficile il rilevamento da parte di ricercatori, servizi di sicurezza e scanner che possono essere in funzione sul sito web preso di mira (Figura 3). Questo metodo aiuta gli autori di attacchi a rimanere nascosti mentre svolgono le loro attività e ad essere meno rilevabili rispetto alle richieste XHR o ai tag HTML tradizionali.
Figura 3. Un'altra variante del caricatore dallo stesso skimmer con l'uso di WebSockets
Esecuzione di verifiche del codice
L'avvio della connessione socket consente al browser e al server C2 di scambiare dati in qualsiasi momento. Il primo messaggio inviato dal server C2 del malintenzionato alla pagina (Figura 4) contiene il codice JavaScript che viene seguito immediatamente da una funzione listener specificata nel codice del caricatore.
Il codice esegue due verifiche.
- Verifica che è stata eseguita una connessione WebSocket tramite una variabile globale definita nel codice del caricatore.
- Determina se si tratta di una pagina di pagamento contenente il pulsante di invio.
Se queste verifiche vengono superate, il codice del malintenzionato invia un messaggio al server C2 contenente l'URL della pagina corrente. Come risposta, il server C2 restituisce il codice dannoso appropriato e personalizzato per quella pagina specifica.
Il fatto che il server C2 attenda una pagina URL prima di restituire il codice di attacco suggerisce che questa campagna operi tramite un modello dinamico in grado di eseguire e supportare contemporaneamente numerosi siti e pagine web.
Figura 4. Connessione WebSocket con il server C2 dello skimmer
Offuscamento del codice
La Figura 5 illustra il codice di attacco effettivo ottenuto dal server C2 dopo la convalida dell'URL. Il codice è fortemente offuscato, rendendo difficile determinare la sua logica sottostante e la progressione dell'attacco. Gli skimmer Magecart impiegano spesso delle tecniche di offuscamento per rendere difficile agli esperti di sicurezza decifrare il codice di attacco e comprenderne l'intero flusso.
Figura 5. Codice di attacco offuscato inviato dal server C2 tramite la connessione WebSocket
Pulizia del codice
L'uso di uno strumento di offuscamento rende la situazione più chiara e rivela l'intenzione dell'attacco. Come mostrato nella Figura 6, il codice contiene una vasta gamma di parole chiave ideate per identificare campi sensibili sulla pagina presa di mira e per creare un modulo di pagamento contraffatto sotto il controllo del malintenzionato.
L'obiettivo finale dell'autore dell'attacco è quello di rubare informazioni personali da visitatori ignari che interagiscono con la pagina infettata e riempiono un modulo falso iniettato dal codice del malintenzionato.
Figura 6. Codice di attacco dopo il deoffuscamento
Inserimento di moduli falsi per fornitori di terze parti
Alcuni negozi presi di mira esternalizzano la loro procedura di pagamento a un fornitore terzo. Quando i clienti forniscono i loro dati personali, vengono reindirizzati al fornitore terzo per inserire le informazioni sulla carta di credito e completare la transazione. Lo skimmer non può accedere al fornitore terzo per ottenere le informazioni sulla carta di credito dell'utente finale.
Crea, invece, un modulo per la carta di credito falso sulla pagina prima che il cliente venga reindirizzato al fornitore terzo (Figura 7). Quando l'utente fa clic su "Pagamento" o sul pulsante "Invia" falso, lo skimmer invia tutti i dati raccolti al suo server C2 e consente all'utente di continuare con il flusso di pagamento legittimo reindirizzandolo alla vera pagina di pagamento del fornitore terzo.
Figura 7. Modulo falso creato dallo skimmer
Se il sito web preso di mira non reindirizza l'utente a una pagina di pagamento di terze parti, lo skimmer non crea un nuovo modulo. Piuttosto, aggiunge i listener JavaScript a tutti gli inserimenti di dati personali nella pagina e nei moduli di pagamento. Una volta che l'utente ha inviato le informazioni, lo skimmer estrae i dati e li invia al server C2 usando i messaggi WebSockets.
In entrambi i casi, lo skimmer crittografa i dati estratti per rendere difficile ai ricercatori e ai servizi di sicurezza rilevare eventuali attività insolite sulla rete avviate dallo skimmer (Figura 8).
Figura 8. Esempio del messaggio crittografato dallo skimmer e inviato dalla connessione WebSocket
Somiglianze tra gli attacchi
Durante l'indagine, abbiamo individuato diversi siti web vittime dell'attacco. Non possiamo confermare che tutti questi attacchi siano correlati alla stessa campagna, ma abbiamo notato delle somiglianze tra i casi che suggeriscono l'uso dello stesso modello Magecart. In alcune istanze, su diversi siti web colpiti sono stati trovati indicatori che il caricatore inline dell'attacco era travestito da Google Tag Manager falso, con parametri codificati che nascondevano segni dello skimmer.
I domini usato dall'autore dell'attacco cambiavano da sito web a sito web e, nella maggior parte dei casi, l'effettivo codice di attacco veniva recuperato dal codice del caricatore sulle pagine interessate solo per rendere l'attacco più discreto e difficile da individuare.
Riepilogo delle tecniche e capacità degli autori di attacchi
Impersonificazione del frammento di un codice fornitore noto, come Google Tag Manager
Uso della codifica Base64 per nascondere eventuali indicatori dell'attacco, come URL e domini
Uso di WebSockets per tutte le comunicazioni tra il browser e il server C2, scaricando il codice di attacco ed esfiltrando i dati
Esecuzione del codice di attacco con la funzione "eval" per fare in modo che lo script somigliasse a uno script di prima parte naturale
Uso delle tecniche di offuscamento per rendere difficile ai ricercatori comprendere il codice
Iniezione di moduli falsi per raccogliere i dati prima che l'utente venga reindirizzato alle pagine di pagamento di terze parti legittime
Proteggetevi con Akamai Page Integrity Manager
Il nostro ha testato il recente attacco Magecart con Akamai Page Integrity Manager e l'attacco è stato immediatamente riconosciuto e mitigato, inoltre sono state fornite informazioni dettagliate per la risoluzione del problema (Figura 9).
Page Integrity Manager è stato concepito appositamente per difendere da attacchi web skimming, form jacking e Magecart. Offre visibilità del comportamento dell'esecuzione degli script di una pagina web e raccoglie informazioni sui diversi script in esecuzione sulla pagina, incluse le loro azioni e le loro relazioni con altri script.
Combinando questi dati con un approccio al rilevamento su più livelli, inclusi analisi euristica, punteggio di rischio, intelligenza artificiale e altri fattori, Page Integrity Manager è in grado di rilevare rapidamente e difendere dalle minacce lato client.
Figura 9. Informazioni dettagliate sulla risoluzione del problema offerte da Akamai Page Integrity Manager
Conclusione
Gli skimmer Magecart sono in costante evoluzione e stanno diventando sempre più sofisticati. L'uso da parte degli skimmer di metodi di evasione e offuscamento avanzati, descritti in questo post, evidenziano quanto sia difficile rilevare questi tipi di attacchi.
Il gioco continuo tra gatto e topo richiede una soluzione di sicurezza completa per rilevare e prevenire gli attacchi. La mancata implementazione di una tale soluzione può causare seri danni ai clienti, la cui privacy può essere compromessa, e provocare danni alla reputazione di un'azienda, nonché multe salatissime.
In base ai nuovi requisiti contenuti nell'ultimo Payment Card Industry Data Security Standard (PCI DSS v4.0), adesso qualsiasi azienda che elabori carte di pagamento online ha l'obbligo assoluto di implementare soluzioni di sicurezza in-browser.
Ulteriori informazioni
Akamai Page Integrity Manager può aiutarvi a soddisfare questi nuovi requisiti fornendo un inventario di tutti gli script in esecuzione sul vostro sito web, la visibilità del comportamento di questi script e sistemi di difesa dai più sofisticati attacchi basati su script.
IOC
I seguenti indicatori di compromissione (IOC) sono forniti per aiutare la comunità a individuare le attività e gli skimmer dannosi descritti nel blog:
yachtbars[.]fun
app-stat[.]com
Magento-cdn[.]net
nebiltech[.]shop
Rithdigit[.]cyou
Antohub[.]shop
Okqtfc1[.]org
jquery-node[.]com
Ulteriori informazioni su come ottenere visibilità nel comportamento degli script e proteggervi dagli attacchi lato client con Akamai Page Integrity Manager.
