L'arte dell'occultamento: una nuova campagna Magecart sta abusando delle pagine 404
Analisi riassuntiva
L'Akamai Security Intelligence Group ha rilevato una campagna di web skimming Magecart che sta prendendo di mira un cospicuo elenco di siti web, tra cui quelli di grandi aziende che operano nell'industria alimentare e nel settore del retail.
Questa campagna si distingue dalle altre per le tre avanzate tecniche di occultamento che utilizza, una delle quali mai vista prima d'ora (ossia, la manipolazione della pagina di errore 404 predefinita per nascondere codice dannoso), che crea problemi specifici per il rilevamento e la mitigazione.
Le altre due tecniche di offuscamento mostrano le sofisticate tattiche utilizzate dai criminali per evitare il rilevamento e per prolungare la catena degli attacchi.
Poiché gli attacchi di web skimming stanno diventando sempre più sofisticati, le aziende devono rimanere all'erta e scoprire metodi avanzati per proteggersi da queste minacce in continua evoluzione.
Introduzione
Una nuova, sofisticata e subdola campagna di web skimming Magecart sta prendendo di mira diversi siti web tramite Magento e WooCommerce. Alcune delle vittime di questa campagna sono associate a grandi aziende che operano nell'industria alimentare e nel settore del retail.
In base alle prove che abbiamo scoperto, questa campagna è attiva da un paio di settimane e, in alcuni casi, anche da più tempo. Questa campagna è riuscita a sorprenderci per la sua avanzata tecnica di occultamento che non avevamo mai visto in precedenza.
La nuova campagna
Gli attacchi Magecart, di solito, iniziano a sfruttare le vulnerabilità presenti nei siti web presi di mira o a infettare i servizi di terze parti utilizzati da questi siti web. In questa campagna, tutti i siti web presi di mira che abbiamo rilevato sono stati sfruttati direttamente con l'iniezione di uno snippet di codice dannoso in una delle loro risorse proprietarie.
In alcuni casi, il codice dannoso è stato inserito nelle pagine HTML, mentre, in altri casi, è stato occultato in uno degli script proprietari che era stato caricato come parte del sito web preso di mira.
Come in altre campagne Magecart, l'infrastruttura degli attacchi di questa campagna è costituita da tre parti principali: loader, codice di attacco dannoso ed esfiltrazione dei dati (Figura 1).
Loader : brevi snippet di codice JavaScript nascosti, che caricano il codice dannoso dell'attacco
Codice di attacco dannoso : il codice JavaScript principale che esegue l'attacco, rileva gli input sensibili, legge i dati, interrompe il processo di pagamento e inietta i moduli falsi
Esfiltrazione dei dati : il metodo utilizzato per trasmettere i dati rubati al server C2 (Command and Control) dell'autore dell'attacco
L'attacco viene separato in tre parti allo scopo di occultarlo, rendendolo, pertanto, più difficile da rilevare. In tal modo, il flusso completo dell'attacco viene attivato solo sulle pagine specificamente prese di mira; in altre parole, grazie alle misure di offuscamento utilizzate dal criminale, l'attivazione del flusso completo dell'attacco può verificarsi solo nelle posizioni in cui il criminale ha deciso di eseguirlo. In tal modo, l'attacco risulta più discreto e difficile da rilevare dai servizi di sicurezza e dagli strumenti di scansione esterni eventualmente implementati sul sito preso di mira.
Anche se le campagne Magecart sono simili tra loro per flusso e fasi degli attacchi, ciò che distingue una campagna dall'altra è rappresentato dalle varie tecniche di occultamento utilizzate dai criminali. Queste tecniche sono utilizzate per oscurare l'infrastruttura dell'attacco, occultare le tracce, complicare il rilevamento e il reverse engineering e, in definitiva, prolungare l'attacco.
Le tre varianti della campagna
Abbiamo rilevato tre diverse varianti di questa campagna a indicare l'evoluzione dell'attacco e i miglioramenti compiuti dai criminali nel corso del tempo per prevenire il rilevamento e la mitigazione della campagna stessa.
Le prime due varianti sono alquanto simili, poiché mostrano solo piccole differenze per quanto riguarda il loader.
La terza versione è esclusiva perché i criminali hanno utilizzato la pagina di errore 404 predefinita del sito web per nascondere il loro codice dannoso: una tecnica di occultamento creativa mai vista prima d'ora.
Analizziamo ora in modo più approfondito i dettagli tecnici delle tre varianti di questa nuova campagna.
Variante 1
La nostra ricerca è iniziata quando abbiamo notato degli snippet di codice sospetto, rilevati dai nostri strumenti dei monitoraggio dell'intelligence sulle minacce, che erano presenti sul sito web di un'importante azienda. Al momento di analizzare questi snippet, abbiamo notato che si trattava di loader JavaScript codificati in modo dannoso, che erano ancora presenti e attivi sul sito web. Questa scoperta ci ha condotto ad ulteriori indagini, che hanno rivelato l'intera campagna con le sue varianti e il suo impatto su numerosi siti web.
Loader della variante 1: la punta dell'iceberg
Lo skimmer ha iniettato un tag di immagine HTML errato con un attributo onerror nel sito web preso di mira (Figura 2). Questo attributo contiene uno snippet di codice del loader dannoso con codifica Base64. L'attributo src intenzionalmente vuoto del tag di immagine è stato progettato per impedire le richieste di rete e per attivare l'esecuzione di un callback onerror online, che contiene lo snippet di codice JavaScript dannoso offuscato.
L'utilizzo dei tag di immagine con lo scopo di eseguire il codice JavaScript è una tecnica meno comune e più sofisticata. Questa tecnica può aiutare lo skimmer a bypassare le misure di sicurezza, come gli scanner esterni, che, di solito, analizzano il traffico di rete e che non sono stati attivati in questo caso specifico. Il codice offuscato viene eseguito nel contesto della pagina come se si trattasse di uno script nativo proprietario avviato dalla stessa pagina.
Figura 2. Loader della variante 1: un tag di immagine HTML formattato in modo errato con un attributo onerror contenente codice dannoso del loader
Codice del loader decoficato: runtime
Una volta eseguito in fase di runtime, il codice con codifica Base64 si trasforma in un codice JavaScript semplice, che avvia un canale WebSocket (Figura 3). Questo canale funge da collegamento di comunicazione bidirezionale tra il browser e il server C2 del criminale.
L'utilizzo di WebSocket negli attacchi Magecart è stato osservato in varie campagne recenti. WebSocket è un metodo di comunicazione considerato più tranquillo e flessibile, che consente al criminale di utilizzare un solo canale di rete per vari scopi, tra cui l'invio di diverse parti dell'attacco dal server C2 al browser (e viceversa), nonché facilitare le attività di esfiltrazione dei dati in alcuni contesti.
Un altro importante aspetto del codice è il rilevamento dei bot, con cui si verifica se lo user agent sia automatizzato. In tal caso, il codice termina la sua esecuzione. Si tratta di un'intelligente tecnica anti-bot concepita con l'intento di eludere sandbox e scanner di sicurezza esterni che potrebbero potenzialmente rilevare l'attacco.
Figura 3. Il codice JavaScript decodificato in fase di runtime relativo al loader della variante 1
Flusso di comunicazione Websocket
Una volta stabilito il canale WebSocket, il primo messaggio viene inviato dal server C2 del criminale al browser. Questo messaggio viene trasmesso sotto forma di stringa con codifica Base64, contenente un comando JavaScript di una riga che richiede al browser di inviare nuovamente l'URL corrente della pagina.
Scopo di questa fase è consentire al server C2 di stabilire se la pagina corrente è una pagina di pagamento (sensibile) o meno. In tal modo, il criminale può modificare le fasi successive di conseguenza.
Questa verifica lato server diretta consente al criminale di attivare l'attacco solo sulle specifiche pagine prese di mira, evitando, pertanto, la potenziale esposizione di pagine non sensibili. Si tratta, quindi, di un altro esempio che evidenzia gli sforzi compiuti dallo skimmer per eludere il rilevamento da parte dei servizi di sicurezza e degli scanner esterni.
Se il server C2 identifica l'URL di una pagina di pagamento, il flusso procede con la fase successiva. In questa fase, viene inviato al browser un altro messaggio costituito da una lunga stringa con codifica Base64, che contiene l'intero codice dell'attacco. Una volta decodificato, risulta visibile un codice JavaScript lungo e offuscato (Figura 4).
Questo codice è responsabile dell'esecuzione di varie attività dannose sulle pagine sensibili del sito web preso di mira con l'obiettivo di leggere le informazioni personali e i dati della carta di credito dell'utente e di trasmettere tali dettagli al server C2 dello skimmer.
I successivi messaggi di esfiltrazione dei dati offuscati contenenti i dati sensibili rubati che sono stati raccolti dal codice dannoso vengono inviati dal browser al server C2. Come detto in precedenza, l'utilizzo dello stesso canale WebSocket per il caricamento del codice dannoso e per l'esfiltrazione dei dati rubati rende il processo più tranquillo e implica un minor numero di richieste di rete rispetto ai metodi di comunicazione tradizionali, come le richieste di recupero o risorse HTML oppure le richieste XHR.
Figura 4. Flusso WebSocket sulle pagine di pagamento
Variante 2
Loader della variante 2: cambia la forma, non la sostanza
La differenza principale tra la variante 1 e la variante 2 consiste nel componente del loader. Nella variante 2, lo skimmer inserisce uno script online con uno snippet di codice che somiglia molto al pixel di Meta, un notissimo servizio di monitoraggio delle attività dei visitatori di Facebook, con l'aggiunta di poche righe al suo interno (Figura 5).
Queste righe aggiunte sono la parte effettiva del loader, mentre ciò che circonda il pixel di Meta è una copertura fuorviante per farlo apparire come uno snippet di codice legittimo e non sospetto.
Questa tecnica di occultamento, che fa apparire snippet di codice dannosi come servizi famosi, tipo Google Tag Manager o Facebook, è diventata più popolare nelle recenti campagne Magecart, poiché consente agli skimmer di eludere le analisi statiche effettuate da ricercatori e scanner esterni.
Figura 5. Loader della variante 2: script online che si spaccia per lo snippet di codice del pixel Meta con un loader dannoso al suo interno
Richiesta di un'immagine
Quando abbiamo esaminato accuratamente le righe sospette all'interno del falso snippet di codice del pixel di Meta, ci è sembrato di recuperare un'immagine PNG dalla directory del sito web. La richiesta di rete sembrava la tipica richiesta di un'innocente immagine presente sul sito web. Tuttavia, quando abbiamo esaminato l'effettivo contenuto di questa immagine, ci è apparso chiaro che non era innocua come sembrava (Figura 6).
Figura 6. Richiesta di un'immagine di rete contenente codice dannoso che è stata manomessa dal criminale
Lo snippet di codice JavaScript dannoso nel file binario di un'immagine
I dati binari dell'immagine PNG contengono una stringa con codifica Base64 aggiunta alla fine del file binario dell'immagine (Figura 7). Questa stringa viene poi estratta, decodificata ed eseguita dallo snippet di codice del loader (Figura 8). La stringa decodificata rappresenta uno snippet di codice JavaScript identico a quello trovato all'interno dell'attributo onerror del loader nella variante 1.
Le fasi successive del flusso rimangono invariate. Questo snippet di codice si trasforma in un codice JavaScript semplice in fase di runtime, il codice avvia il canale WebSocket sul server C2 del criminale e il resto della sequenza segue la procedura descritta in precedenza.
Figura 7. I dati binari dell'immagine che contiene il codice dannoso nascosto
Figura 8. Il codice dannoso, che è stato inizialmente codificato in Base64 e nascosto all'interno dell'immagine, diventa visibile dopo la decodifica
Variante 3
Ora, passiamo alla parte migliore. Anche se abbiamo già visto attacchi simili, questo tipo di attacco è unico e ci ha davvero colti di sorpresa.
Loader della variante 3: sempre lo stesso, ma con una veste diversa
Al primo sguardo, questo loader sembra simile a quello della variante 2, ma vedrete (come abbiamo visto noi) che si tratta di un caso completamente diverso. In alcuni casi, questo loader si spaccia per lo snippet di codice del pixel Meta, come si è visto nella variante 2 (Figura 9), ma, in altri casi, viene iniettato all'interno di script online casuali sulla pagina (Figura 10).
Il primo importante aspetto di questo loader consiste nel fatto che si tratta di una richiesta di recupero inviata ad un percorso relativo denominato "icons".
Figura 9. Loader della variante 3: uno snippet di codice dannoso occultato in uno snippet di codice che imita l'aspetto del pixel Meta
Figura 10. Loader della variante 3: uno snippet di codice dannoso occultato in uno script online arbitrario
Un errore 404? Davvero?
Una volta eseguito il loader, l'attacco invia una richiesta di recupero al percorso relativo /icons, che, in realtà, non esiste. Questa richiesta ha portato ad un errore "404 - Pagina non trovata" (Figura 11). Una volta analizzato, l'HTML restituito nella risposta sembrava simile alla pagina 404 predefinita del sito web (Figura 12), il che ci ha confuso facendoci chiedere se lo skimmer non fosse più attivo sui siti web presi di mira da noi individuati.
Figura 11. Richiesta avviata dal loader ad un percorso non esistente che restituisce un messaggio di errore 404
Figura 12. HTML della pagina di errore predefinita
Mai sottovalutare il loader
Facendo un passo indietro e ripetendo l'analisi del loader, abbiamo trovato il pezzo mancante del rompicapo. Il loader conteneva un'associazione regex per la stringa "COOKIE_ANNOT", la cui esecuzione era prevista sulla pagina di errore 404 restituita dopo la richiesta delle icone.
Pertanto, abbiamo effettuato una ricerca per questa stringa all'interno della pagina HTML 404 restituita... et voilà! Abbiamo scoperto un commento nascosto verso la fine della pagina contenente la stringa "COOKIE_ANNOT" (Figura 14). Accanto a questa stringa, era concatenata una lunga stringa con codifica Base64, che rappresenta l'intero codice dell'attacco JavaScript offuscato. Il loader estrae questa stringa dal commento, lo decodifica ed esegue l'attacco concepito con l'intento di rubare le informazioni personali immesse dagli utenti.
Abbiamo simulato altre richieste su percorsi non esistenti, che hanno tutte restituito la stessa pagina di errore 404 contenente il commento con il codice dannoso codificato. Questi controlli confermano che l'autore dell'attacco è riuscito a modificare la pagina di errore predefinita per l'intero sito web, occultando il codice dannoso al suo interno!
Figura 13. Loader della variante 3: associazione regex per la stringa "COOKIE_ANNOT".
Figura 14: Il commento codificato dannoso che era nascosto nell'HTML della pagina di errore
Esfiltrazione dei dati
Modulo falso
A differenza delle varianti 1 e 2, nella variante 3 i criminali hanno impiegato un'altra comune tecnica di esfiltrazione dei dati: l'iniezione di un modulo falso (Figura 15). Questa tecnica viene solitamente utilizzata quando lo skimmer non può accedere ai dati sensibili,
ad esempio, nel caso in cui un sito web utilizza un servizio di pagamento di terze parti che implementa il modulo di pagamento all'interno di un iframe di terze parti o in una pagina esterna. Per bypassare queste situazioni, il criminale crea un modulo falso che somiglia molto al modulo di pagamento originale, a cui lo sovrappone: una tecnica questa che sta diventando sempre più comune. Ecco quindi esattamente come i dati rubati vengono esfiltrati nella variante 3.
Figura 15. Il modulo falso iniettato dal codice dannoso
Quando l'utente inserisce i dati nel modulo falso del criminale, viene visualizzato un messaggio di errore e il modulo falso viene nascosto, quindi viene visualizzato il modulo di pagamento originale e all'utente viene richiesto di inserire nuovamente i suoi dati relativi al pagamento (Figura 16).
Figura 16. Il modulo falso è nascosto e all'utente viene richiesto di inserire nuovamente i suoi dati
Richiesta di immagine con i dati rubati
L'invio del modulo falso avvia una richiesta di rete di un'immagine al server C2 del criminale contenente tutti i dati sulle carte di credito e le informazioni personali rubate sotto forma di una stringa con codifica Base64 nel parametro della query (Figura 17). Una volta decodificata, questa stringa rivela lo scopo reale della richiesta e l'intero flusso dell'attacco diventa chiaro.
Figura 17. Richiesta di rete di un'immagine con i dati rubati inclusi come parametro della query per la stringa con codifica Base64
Lezioni apprese dalla variante 3: il caso del messaggio 404
Questa tecnica di occultamento è altamente innovativa e il suo utilizzo non è stato da noi mai osservato in precedenti campagne Magecart. L'idea di manipolare la pagina di errore 404 predefinita sul sito web preso di mira può offrire agli autori di attacchi Magecart varie opzioni creative per migliorare le tecniche di occultamento ed elusione.
In alcuni dei casi che abbiamo identificato, il loader dannoso è stato già rimosso dalle pagine dei siti web coinvolti nell'attacco al momento della stesura di questo articolo. Tuttavia, il commento dannoso presente nella pagina 404 predefinita è rimasto, consentendo potenzialmente allo skimmer di riattivare facilmente l'attacco. Ciò evidenzia la complessità di rilevare e l'importanza di mitigare questo approccio.
La richiesta al percorso proprietario che porta alla pagina 404 è un'altra tecnica di elusione che può bypassare le intestazioni delle policy di sicurezza dei contenuti e altre misure di sicurezza che potrebbero analizzare attivamente le richieste di rete sulla pagina. Tutto ciò rende questa tecnica indubbiamente una delle strategie Magecart più sofisticate che abbiamo osservato di recente.
La lotta tra Akamai Client-Side Protection & Compliance e lo skimmer
Nell'ambito della nostra ricerca su questa campagna, abbiamo condotto una simulazione dell'attacco sferrato da questo skimmer contro Akamai Client-Side Protection & Compliance, la nostra soluzione che analizza il comportamento dell'esecuzione di JavaScript runtime per difendere dalla minacce JavaScript e mitigare gli attacchi lato client.
La soluzione ha rilevato lo skimmer sofisticato e ha attivato un evento di alta gravità per un'immediata mitigazione del problema. In una situazione reale in cui Client-Side Protection & Compliance è attivato su una particolare pagine web, la Figura 18 mostra l'avviso che il proprietario del sito web riceve in modo da poter esaminare rapidamente la minaccia e rispondere in tempo reale con varie opzioni di mitigazione del problema.
Figura 18. Avviso della simulazione di Client-Side Protection & Compliance dopo il rilevamento dello skimmer
Conclusione
Questa campagna avvalora la tesi secondo cui le tecniche di web skimming sono in costante evoluzione. Diventando più sofisticate, rendono, infatti, sempre più difficile eseguire il rilevamento e la mitigazione tramite analisi statiche e scansioni esterne. I criminali presenti in questo dominio trovano costantemente metodi migliori con cui occultare i loro attacchi all'interno dei siti web presi di mira ed eludere le varie misure di sicurezza in modo da renderli visibili.
Il livello di complessità evidenziato in questa ricerca dovrebbe ricordare alle organizzazioni di rimanere vigili e attente agli attacchi di web skimming e di cercare attivamente nuovi metodi avanzati per affrontare questi tipi di attacchi.
IOC
Pmdresearch[.]com
secures-tool[.]com
adsometric[.]com
cngresearch[.]com
