Sono chiamati attacchi Magecart e sebbene siano stati osservati fin dal 2016, i ricercatori di sicurezza informatica di Sucuri, durante le indagini su un negozio online compromesso legato alla piattaforma di e-commerce Magento open source, hanno scoperto una nuova tecnica di esfiltrazione basata sull’uso di immagini. Negli attacchi Magecart solitamente i criminali accedono a un negozio online attraverso una vulnerabilità o un punto debole e installano codice dannoso per rubare i dettagli della carta del cliente nel momento del pagamento. Durante la pandemia anche questo tipo di attacchi è in aumento, grazie al maggior utilizzo delle piattaforme di e-commerce online, considerate terreno fertile per esfiltrare i dati delle carte di pagamento che in seguito sono rivendute nel dark web.
Chi sono i gruppi Magecart
Magecart è il nome collettivo per una serie di gruppi criminali che prendono di mira aziende online di varie dimensioni, soprattutto e-commerce, per effettuare il furto di carte di credito digitali, scremando i moduli di pagamento online e raccogliere attraverso il browser le informazioni sensibili dell’utente finale. Magecart ha attirato l’attenzione dei media mainstream negli ultimi due anni anche a causa della tipologia di vittime illustri colpite: British Airways, Forbes, Equifax, Macy’s, per citarne solo qualcuno dei più noti. Alcuni attacchi Magecart sono rimasti inosservati per più di 6 mesi, come nel caso della violazione di British Airways, in cui gli aggressori sono stati in grado di rubare i dettagli della carta di credito di quasi 400.000 clienti in soli 15 giorni. L’esempio evidenzia come molte organizzazioni non sanno quando uno skimmer dannoso è in esecuzione sui loro siti web. Fino ad oggi centinaia di migliaia di clienti sono stati derubati dei dettagli della loro carta di credito.
Non tutti i gruppi Magecart adottano le stesse strategie per violare i siti web. Alcuni scelgono di violare direttamente il server della vittima, ma un altro modo di tipo indiretto consiste nell’infezione del codice che viene successivamente trasferito al server come parte del processo di compilazione. Tuttavia, la maggior parte persegue un attacco tramite terze parti, inserendo il codice dello skimmer dannoso in script di origine esterna, che le aziende eseguono sui propri siti web. Immediatamente dopo la compromissione del sito web, questi script iniziano presentare il web skimmer agli ignari acquirenti che visitano la pagina di pagamento.
Guardando alla crescita degli attacchi Magecart web skimming nel 2020, sembra che gli aggressori siano destinati a mantenere il sopravvento per tutto il 2021, perché le aziende di e-commerce appaiono ancora impreparate dal punto di vista della sicurezza. A titolo di esempio una campagna Magecart, scoperta durante il periodo natalizio, ha alterato il processo di pagamento nascondendo codice all’interno di iframe PayPal del tutto credibili. I dati di pagamento dei clienti sono tipicamente utilizzati per varie attività criminali, come frodi con carte di credito o campagne di phishing o spam verso vittime mirate.
Ultima tecnica di attacco
L’ultima delle tattiche usate negli attacchi Magecart è stata scoperta dai ricercatori di Sucuri durante un’indagine su un sito di e-commerce Magento v.2 compromesso e che veniva caricato dal dominio dannoso magecart [.] Net. Il dominio dannoso è stato registrato per la prima volta l’8 dicembre 2019, presumibilmente proprio da uno dei gruppi Magecart. Questi criminali hanno trovato un nuovo modo per nascondere la loro attività online, salvando i dati sottratti dalle carte di credito online in un file .JPG su un sito web iniettato da loro codice dannoso. Il processo è chiamato steganografia e implica nascondere il codice dannoso all’interno di un’immagine o nel codice sorgente di un file musicale. Tra i gruppi di hacker, la tecnica non è molto comune perché è difficile introdurre del testo all’interno del codice sorgente di un’immagine senza danneggiare il file immagine reale.
Luke Leal del team di ricerca sul malware di Sucuri ha spiegato che: “gli aggressori hanno iniettato codice PHP in un file chiamato ./vendor/magento/module-customer/Model/Session.php, e hanno utilizzato la funzione ‘getAuthenticates’ per caricare codice dannoso. Il codice ha anche creato un file .JPG, che gli aggressori hanno utilizzato per archiviare tutti i dati acquisiti dal sito compromesso” aggiungendo che “l’uso creativo del falso .JPG consente a un utente malintenzionato di nascondere e archiviare i dettagli delle carte di credito raccolte per un utilizzo futuro senza farsi notare troppo dal proprietario del sito Web”. Quindi i criminali hanno aggiunto un codice extra al file, registrando i dettagli della carta di pagamento inseriti dagli utenti nel modulo di checkout e salvandoli alla fine di un’immagine locale. Con questa tecnica i criminali hanno potuto accedere e scaricare facilmente le informazioni rubate a proprio piacimento, eludendo il rilevamento e nascondendo la loro attività.
Analisi di un classico caso di attacco di tipo Magecart
I ricercatori Akamai hanno analizzato in dettaglio uno degli attacchi classici di tipo Magecart effettuato verso una grande azienda internazionale di e-commerce, (il cui nome non è stato reso pubblico n.d.r.), che ha subito la compromissione di uno dei suoi siti web attraverso uno script dannoso. L’attacco, rilevato in automatico dal tool Page Integrity Manager, era un first-party JavaScript injection, incorporato nell’indice della pagina HTML. Non è chiaro esattamente come gli aggressori siano riusciti a infiltrarsi nell’ambiente first-party e intrufolarsi con il loro skimmer all’interno del sito web, ma tutti gli utenti che lo visitavano erano esposti a questo script efficace solo su pagine specifiche, come il modulo di checkout mobile e uno dei moduli di checkout web.
Caratteristica comune a queste tipologie di attacco è l’uso, per il server dell’attaccante, di un nome molto simile al brand del cliente compromesso, ma con un diverso dominio di primo livello, per riuscire ad ingannare l’occhio umano facendo sembrare il dominio legittimo. Quando un sito e-commerce viene compromesso nella pagina di checkout che contiene il modulo di pagamento, lo script malevolo tenta di leggere tutti gli input presenti (numero di carta di credito, nome del titolare della carta, cvv, data di scadenza), applicando l’algoritmo di cifratura e inviandolo al server dell’attaccante. Questo web skimming è molto difficile da individuare da parte dell’utente finale che lo subisce ed anche dall’azienda e-commerce che sicuramente subisce un doppio danno: di reputazione, perché il cliente non sentendosi più sicuro non tornerà più e un danno immediato per l’esigenza di rimuovere il codice malevolo e ripristinare il codice originale.
Alcuni software di sicurezza effettuano il rilevamento mediante analisi dell’integrità del codice e di anomaly detection sul codice dello script, evidenziando comportamenti non previsti in questo contesto di esecuzione del codice sulla base dei dati storici dell’applicazione (ad esempio la lettura di dati sensibili e il traffico in uscita).
Una volta avvisata l’azienda vittima con le informazioni del comportamento sospetto, il security team ha applicato la propria incident response policy, per proteggere le sessioni degli utenti in tempo reale, il che ha impedito che i dati sensibili fossero esfiltrati dai browser degli utenti finali verso i server dell’attaccante. Questo è avvenuto in parallelo all’aggiornamento dell’applicazione del cliente per non includere più lo script dannoso (che era uno 0-day).
La sicurezza dei siti web per e-commerce
Ogni azienda che eroga servizi di e-commerce mediante una piattaforma o un sito Web di e-commerce, dovrebbe assicurarsi che il contenuto del sito Web scaricato dai propri clienti sia quello corretto e non una versione alterata da script malevoli. In molti casi purtroppo né gli imprenditori né i team di sicurezza si rendono conto del problema se non quando il danno è già avvenuto. In parte può dipendere dall’abitudine dei team di security di concentrarsi sul lato server della sicurezza, “dimenticandosi” di ciò che accade sul lato client (ovvero il browser e l’ambiente in cui operano gli attacchi Magecart), ambito quindi che tende a passare ampiamente inosservato.
Le aziende dovrebbero assolutamente controllare il codice di terze parti e il livello di sicurezza dei loro fornitori. Tuttavia, questo aspetto passa spesso in secondo piano rispetto allo sviluppo del prodotto. Sembra quindi che i controlli siano demandati al lato client, che naturalmente può non essere affatto preparato. Inoltre, gli attacchi Magecart di web skimming stanno diventando più sofisticati con ogni iterazione. Le versioni recenti di Magecart utilizzano tecniche di rilevamento dei bot delle soluzioni di sicurezza per evitare di essere individuati, rendendo ancora più difficile fermare lo skimmer.
Pedro Fortuna un ricercatore di sicurezza ha indicato quindi l’esigenza di un approccio diverso basato sull’analisi comportamentale del codice: “invece di cercare una soluzione che prevenga le iniezioni di codice dannoso non prevenibili”, suggerisce il ricercatore, “le organizzazioni dovrebbero rilevare le code injection per bloccare rapidamente gli attacchi Magecart. La gestione e la convalida di terze parti è un buon inizio, ma non sufficiente. Gli script possono modificare il comportamento e ci si può fidare degli script se e solo se non cambiano il loro comportamento. Uno script di chat, ad esempio, non deve interagire in alcun modo con il modulo di pagamento. Uno script che non invia mai informazioni, non dovrebbe mai essere in grado di inviare dati a un dominio non controllato. Piuttosto che esaminare il codice, limitare questi comportamenti è ciò che garantisce una buona difesa”.
Luke Leal, di Sucuri, consiglia di adottare soluzioni capaci di “identificare nuovi file nell’ambiente e rilevare modifiche potenzialmente dannose, implementando servizi di monitoraggio del sito Web unitamente a controlli di integrità”.
Nicola Ferioli, Head of Engineering di Akamai, ha sottolineato come gli attacchi Magecart possano avere un impatto sull’utenza, sia che avvengano attraverso script malevoli iniettati attraverso l’hostname del Cliente sia attraverso risorse di terze parti, suggerendo anche come la protezione in-browser debba essere parte integrante di qualsiasi azienda che abbia una significativa presenza online.
