ImageImageImageImageImageImageImageImageImageImageImageImageImageImageImageImageImage

Secondo una ricerca di Securi, una delle più note società di sicurezza informatica, è stata scoperta una campagna malware che colpisce milioni di siti e-commerce su piattaforma Magento, anch’esso noto CMS molto utilizzato anche in ambito aziendale. Dati Alexa rivelano che Magento è tra i principali attori nella creazione di siti dedicati all’e-commerce, piazzandosi con il 26% nella top 1M sites.

Ogni giorno milioni di persone acquistano online e purtroppo – soprattutto quando si trovano su siti fidati – per completare le transazioni lasciano con grande leggerezza i propri dati personali ed i numeri delle carte di credito, con la certezza che questi siano al sicuro.

In realtà non è sempre così, per quanto ci si sforzi nel mettere in sicurezza siti web e infrastrutture nel miglior modo possibile, esiste ed esisterà sempre una potenziale falla nei sistemi che non verrà rilevata e che potrebbe portare a un furto di dati.

Il ricercatore Peter Gramantik, di Securi, ha scoperto l’esistenza di una vulnerabilità, che sembrerebbe ancora non nota in Magento,  che permette di inserire del codice malevolo nel sito di commercio elettronico per carpire i dati delle transazioni tramite carta di credito prima che queste vengano criptate e messe al sicuro.

La portata di questa falla è evidente, se consideriamo che la protezione dei servizi legati all’e-commerce (dati dei clienti, delle carte di credito, etc…) per un’azienda che opera in rete e che tiene ai suoi clienti, è di vitale importanza.

Il che dimostra anche un’altra cosa: talvolta affidarsi ad applicazioni popolari come le principali piattaforme di e-commerce (la stessa Magento, ma anche sistemi come Prestashop o altri), può non bastare a mettersi al riparo da brutte sorprese.

Come risolvere (nei limiti del possibile) il problema? Aggiungere degli strati ulteriori a protezione del sistema di e-commerce, come un Intrusion Prevention System (IPS) o Web Application Firewal (WAF), potrebbe aumentare sensibilmente la sicurezza delle piattaforme utilizzate dalle nostre aziende.  Analizzare la rete per monitorare le notizie che riguardano le applicazioni ed i prodotti che fanno parte dei sistemi installati per la gestione del nostro sito di  e-commerce è un’altra buona pratica da non sottovalutare.

Fidarsi è bene ma non fidarsi è meglio, insomma. Il cybercrime ci sta insegnando che tecniche e tipologie di vulnerabilità continuano ad affinarsi e sempre più affidarsi a sistemi/CMS o ai maggiori provider di soluzioni e-commerce, può non essere sufficiente quando si tratta di proteggere il proprio business. In questo senso l’hacking non fa distinzione tra open source o soluzioni di codice customizzato ad hoc per l’attività di  e-commerce: nessuna azienda che rilascia software, d’altra parte, è obbligata a scrivere del codice sicuro.

Un penetration test sull’applicazione a volte può salvare il business: spendere qualche euro in più per pagare un professionista, a fronte del furto di migliaia di carte di credito dei clienti, potrebbe evitare non solo un data leak ma, in alcuni casi, anche il fallimento dell’iniziativa commerciale.

Insomma: la morale – solo apparentemente scontata –  del caso Magento è che le attenzioni verso la sicurezza non sono mai abbastanza. Non basta scegliere una soluzione nota o supportata, ma è necessario preoccuparsi di tenerla aggiornata, monitorare costantemente la rete a caccia di notizie che la riguardano, prevedere la presenza di sistemi specificatamente pensati per aumentare il livello di sicurezza del proprio sistema.

Ma, per chi volesse saperne di più, andiamo a vedere cos’è successo questa volta con Magento.

In dettaglio

Entriamo nel dettaglio di quanto è successo su Magento.

Magento1

Nell’immagine, si vede l’injection del file che in questo caso è una finta immagine .gif, nella quale vengono memorizzate le credenziali rubate per poi essere criptate. Lo script permette di carpire ogni transazione e inviare i dati passati da ogni POST nascondendoli nella finta immagine .gif.
Rilevare questo tipo di intrusione richiede un controllo costante della rete.

L’autore di questo attacco ha escogitato un sistema di controllo che gli permette di verificare se il sito è ancora vulnerabile.
Per effettuare la verifica della vulnerabilità basta infatti modificare il parametro USER-AGENT  con Visibot/2 […]  e senza passare alcun parametro in GET il sito risponderà con una pagina bianca con la scritta “PONG”.
Ben più difficile invece leggere i dati memorizzati nel finto file immagine, perché criptati con funzione openssl utilizzando la chiave pubblica presente nella variabile $k3 nell’immagine precedente solo l’autore in possesso della sua chiave privata può leggere il contenuto del file.
Mettendo in evidenza la chiave pubblica dalla ricerca effettuata da Securi, l’autore dello script sembra essere la stessa persona.

Varianti

Dalla ricerca di Securi sono state analizzate anche altre varianti che utilizzano però questa volta uno script offuscato:

 Magento2

Lo script malevolo parte dalla riga 20. Come possiamo osservare lo script è offuscato da un serie di concatenazioni di funzioni di codifica e compressione. Da questo codice è facile risalire al codice in chiaro.

Magento3

Il codice questa volta sembra essere molto più semplice. Come si può facilmente evincere gli autori di queste due varianti sono diversi. Il livello del linguaggio utilizzato nella creazione degli script è diverso, il primo utilizzava funzioni di encryption mentre il secondo quelle molto più blande di offuscamento.

Un codice base64 che transita sulla porta 80 o 433 viene segnalato dai più recenti IPS e WAF loggandolo o perlomeno mettendolo tra gli alert.
L’injection dello script questa volta viene fatto sul modulo di checkout di Magento e non sull’intero CMS come il suo predecessore. Questo significa che l’attaccante ha precedentemente analizzato a fondo l’applicazione scoprendo che la variabile $data viene passata alla funzione di salvataggio del pagamento chiamata SavePayment in chiaro e con tutti i dati necessari alla transazione.

Una volta che il codice intercetta una transazione questa viene inviata tramite email a [email protected] e [email protected].

©2025 Fondazione per la sostenibilità digitale

Tech Economy 2030 è una testata giornalistica registrata. Registrazione al tribunale di Roma nr. 147 del 20 Luglio 2021

Powered by DTILab  - Designed by Fattoria Creativa - Developed by EHT