Xurum: rilevata una nuova campagna di Magento

L'e-commerce è un settore largamente preso di mira dagli attacchi dei criminali informatici in generale. Tuttavia, la diffusa popolarità di Magento l'ha reso sfortunatamente un bersaglio particolarmente allettante (e redditizio). Maggiormente degno di nota è l'attacco Magecart,  in cui i criminali mirano ad installare skimmer basati su JavaScript per acquisire in modo illecito informazioni sensibili sugli utenti. Gli autori di questi attacchi Magecart riescono a sfruttare le note vulnerabilità web per raggiungere il loro scopo.

Almeno sette gruppi di criminali hanno preso di mira gli store di Magento dal 2015a indicare l'importanza di questa piattaforma e il successo ottenuto dai criminali tramite il suo sfruttamento.

Agli inizi del 2022, è venuta alla luce la vulnerabilità CVE-2022-24086, che consente ai criminali di sfruttare il motore dei template di Magento e di eseguire codice PHP arbitrario sugli obiettivi più vulnerabili. L'exploit è costituito da più fasi, in cui i vettori di attacco più comuni riguardano l'abuso del processo di pagamento o della funzionalità della wishlist. Dal momento della sua divulgazione, questa vulnerabilità è emersa come principale punto di ingresso per i vari autori di attacchi Magecart, che mirano ai vulnerabili store di Magento 2.

Nei mesi scorsi, Akamai ha monitorato da vicino una campagna mirata specificamente ad un numero relativamente basso di installazioni di Magento. Questa campagna è stata soprannominata Xurum in relazione al nome del dominio del server C2 utilizzato dai criminali.

Durante questa campagna attualmente in corso, abbiamo osservato i criminali tentare di eseguire due distinti payload da un totale di quattro indirizzi IP (Figura 1). Questi indirizzi IP sono associati all'infrastruttura di due provider di hosting: Hetzner in Germania e Shock Hosting negli Stati Uniti.

Durante la nostra indagine, è risultato evidente che il server xurum.com è posizionato fisicamente nei Paesi Bassi (Figura 4) e che viene gestito dalla società di hosting russa VDSina.ru (Figura 5).

Considerando le varie iterazioni di questo attacco, abbiamo deciso di chiamarlo xurum per distinguere questa campagna da altri tipi di attacchi.

Spesso, i criminali impiegano diverse convenzioni di denominazione per i loro domini o malware, che inavvertitamente o deliberatamente sono la loro firma distintiva. Nel corso della nostra indagine sul possibile significato della parola "xurum," ci siamo imbattuti in due potenziali interpretazioni.

Google Traduttore traduce la parola "xurum" dal latino come "giusto" nell'accezione "fare la cosa giusta" (Figura 7). D'altro canto, il dizionario di WordSense indica che xurum significa "ragazzo" in una lingua ormai estinta che veniva parlata in Guatemala (Figura 8).

Si prega di notare che, al momento della stesura di questo blog, i criminali hanno reso inattivo il loro server xurum e sono passati ad un altro server, che si trova apparentemente ancora in una fase di controllo qualità.

Lo script PHP dannoso che viene scaricato dal server xurum ed eseguito sul computer preso di mira presenta diversi stadi di infezione.

Innanzitutto, raccoglie le informazioni tecniche sulla vittima, come:

• Versione PHP

• Se l'exploit è penetrato nella directory "/pub" (la comune struttura di directory in Magento)

• Se il file "/var/www/html/vendor/magento/google-shopping-ads/registration.php"  esiste ed è modificabile 

• I contenuti del file "env.php", che includono importanti informazioni sull'applicazione Magento, come le impostazioni specifiche dell'ambiente, ma anche informazioni riservate come la chiave di crittografia utilizzata per proteggere i dati sensibili, ad esempio password, dati delle carte di credito e informazioni sui clienti.

Quindi, il blob Base64 offuscato viene decodificato e scritto nel file "/var/www/html/vendor/magento/google-shopping-ads/registration.php" (Figura 9).

Il nuovo file include contenuti interessanti. Anziché mantenere la propria copia di una web shell e gestirla sul proprio server C2, il codice presente nel nuovo file punta ad un repository GitHub pubblico gestito da un ricercatore della sicurezza denominato "Bad Advertiser" o "@0xbadad”. All'interno di questo repository, è presente una nota web shell denominata wso-ng. L'aspetto che la rende particolarmente interessante, tuttavia, consiste nel fatto che la web shell non viene scritta nel disco del server, ma viene caricata ed eseguita soltanto in memoria una volta effettuato l'accesso alla pagina "registration.php" appena creata. Per proteggersi ulteriormente dagli accessi non autorizzati, bisogna considerare che i criminali inseriscono anche uno specifico cookie "magemojo000" nella richiesta per eseguire correttamente la web shell.

Quindi, il criminale registra la nuova funzionalità della web shell come un nuovo componente Magento e lo spaccia come "GoogleShoppingAds" (Figura 10).

Dopo aver installato la backdoor, i criminali recuperano le informazioni sui metodi di pagamento degli ordini di vendita utilizzati negli ultimi10 giorni ed esfiltrano questi dati nella zona di lancio del server xurum.com, insieme alle informazioni tecniche raccolte in precedenza (Figura 11).

Infine, i criminali creano un utente amministratore della backdoor denominato "mageworx" (o "mageplaza" in alcune varianti). Questi nomi corrispondono ai popolari store delle estensioni di Magento 2, Mageworx e Mageplaza (Figura 12). Questa scelta di nomi sembra un tentativo di camuffare le azioni dei criminali presentandole come legittime in quanto correlate a questi affidabili provider di estensioni.

Abbiamo notato anche una piccola differenza negli indirizzi e-mail degli utenti della backdoor. Si nota l'uso della doppia "z" in "mageplazza" nell'indirizzo e-mail developer@mageplazza.com, mentre il dominio dello store legittimo presenta una sola "z" nel suo nome (mageplaza.com), che sembra un errore di battitura commesso dai criminali. Un errore simile è stato notato nell'indirizzo e-mail dell'utente dell'altra backdoor, support@magaworx.com,  in cui si nota l'uso di una "a" anziché di una "e" come appare nel nome dello store originale (Mageworx).

Una web shell è uno script o un pezzo di codice dannoso che i criminali caricano ed eseguono su un server web per guadagnare l'accesso non autorizzato e per controllare in modo persistente il server insieme ai file e ai dati in esso contenuti.

In questa operazione, i criminali sfruttano una web shell molto avanzata, nota come wso-ng, che, come menzionato in precedenza, è stata creata da un ricercatore della sicurezza alcuni anni fa. Come indicato dal suo autore, wso-ng è la nuova generazione della famosa versione precedente, denominata WSO (Web Shell by Orb). 

Oltre alle tipiche funzionalità che si trovano nelle web shell, come la raccolta delle informazioni di sistema e la gestione di file e SQL, wso-ng presenta altre eccezionali funzioni che la distinguono dalla concorrenza (Figura 13).

Una di queste funzioni è rappresentata dalla pagina di accesso nascosta. Al momento di effettuare l'accesso, la pagina risponde con un codice di stato HTTP del tipo 404 Non trovato, dando l'impressione di essere una pagina non esistente. Il contenuto visibile appare a prima vista vuoto (Figura 14). Tuttavia, se si esamina il codice sorgente della pagina, si trova un modulo di accesso nascosto.

Questo modulo viene nascosto abilmente all'utente con un semplice trucco CSS, in cui 1.000 pixel vengono spostati a sinistra per allontanare il modulo dall'area visibile. Questo modulo di accesso nascosto è progettato per attendere l'immissione della password da parte dell'utente.

Abbiamo trovato un altro strumento interessante nell'arsenale dei criminali sul server xurum.com: un exploit pubblico di una precedente vulnerabilità CVE-2016-5195 denominato Dirty COW per le escalation dei privilegi locali di Linux (Figura 15).

Poiché molti dei clienti della nostra soluzione WAF ( Web Application Firewall ) hanno mitigato in modo efficace questa campagna, non abbiamo osservato direttamente altre azioni intraprese dai criminali. Tuttavia, durante la nostra indagine, abbiamo notato che i nomi dei siti web erano indirettamente correlati a questa campagna e apparivano nell'intestazione dell'origine/referer HTTP.

Almeno uno di questi siti web è stato infettato da un semplice web skimmer, che, installato sulla pagina principale senza applicare alcuna tecnica di offuscamento, raccoglie i dati delle carte di credito e li estrae in una zona di lancio gestita su "smileface.site" (Figura 16).

Quando si tenta di accedere, il sito web risponde con un messaggio di accesso sospetto (Figura 17).

Le informazioni sull'indirizzo IP indicano che il server è situato a Mosca ed è gestito dalla società di hosting russa "reg.ru" (Figura 18).

Dalla nostra indagine, è emerso che questa campagna risale almeno alla fine di gennaio 2023. I criminali hanno mostrato un approccio meticoloso, prendendo di mira specifiche istanze di Magento 2 anziché diffondere in modo indiscriminato i propri exploit sul web. Disponendo di un elevato livello di competenze su Magento, i criminali investono una quantità considerevole di tempo nella comprensione delle sue caratteristiche interne, nella configurazione dell'infrastruttura dell'attacco e nell'esecuzione di test dei propri exploit su obiettivi reali.

Questa campagna rappresenta un esempio pratico di come precedenti vulnerabilità continuano ad essere sfruttate anni dopo la loro divulgazione, mentre le aziende si impegnano nell'intento di tenersi aggiornate su misure di sicurezza e patch.

Per impedire l'accesso iniziale al server, si consiglia ai professionisti della sicurezza di tenersi al passo con le patch più recenti e di integrarle implementando una soluzione WAF, come Akamai App & API Protector.

Poiché l'obiettivo principale degli autori di questi attacchi Magecart è infettare le pagine di Magento con web skimmer e rubare i dati delle carte di credito dei clienti, si consiglia vivamente di aggiungere soluzioni per la sicurezza dedicate, che forniscono visibilità sul comportamento degli script del browser e offrono un sistema di difesa dagli attacchi lato client.

Un approccio efficace prevede l'implementazione di misure di sicurezza in posizioni più vicine al punto in cui si verifica l'effettivo attacco ai client, tra cui l'identificazione dei tentativi di lettura da campi di input sensibili e l'esfiltrazione di dati. Si consiglia vivamente di raccogliere questi eventi per facilitare una mitigazione rapida ed efficiente con l'aiuto di prodotti per la sicurezza, come Akamai Page Integrity Manager.

Durante la nostra analisi dei recenti tentativi di sfruttamento della vulnerabilità CVE-2022-24086 di Magento sui nostri clienti, abbiamo scoperto altre campagne che sono attualmente oggetto di indagine. Continueremo a condurre ulteriori indagini e a condividere i nostri risultati con la comunità della sicurezza. Per ulteriori ricerche sulla sicurezza, seguiteci su Twitter.

I seguenti indicatori di compromissione (IOC) sono forniti per aiutare la comunità a individuare le attività dannose descritte nel post.