PrestaShop hackerato: skimmer nel checkout, admin falsi e come accorgersene - init.d - sistemistica Linux, DevOps e sviluppo PrestaShop

# PrestaShop hackerato: skimmer nel checkout, admin falsi e come accorgersene

Alessandro Corbelli~4 min
Table of Contents

Un sito vetrina hackerato di solito si nota: redirect verso siti di spam, l'avviso rosso del browser, Google che lo segnala. Un negozio PrestaShop hackerato spesso no. L'attacco più redditizio contro un e-commerce non vuole farsi vedere: vuole restare nascosto nel checkout il più a lungo possibile, copiando i dati delle carte dei clienti mentre il negozio continua a vendere normalmente.

In questo articolo vediamo come funzionano questi attacchi, quali segnali li tradiscono, cosa fare nelle prime ore e come evitare che si ripetano.

Come entra un attacco in un negozio PrestaShop

Le porte d'ingresso sono quasi sempre le stesse:

  • moduli con vulnerabilità note e mai aggiornati, soprattutto quelli che ricevono dati dall'esterno (import, form, ricerca);
  • versioni vecchie di PrestaShop, con correzioni mancate da anni, come abbiamo visto parlando di chi resta su PrestaShop 1.7 o 8;
  • password del back office deboli o riusate, attaccate per tentativi;
  • area di amministrazione raggiungibile a un indirizzo facile da indovinare.

Un caso reale: nel luglio 2022 PrestaShop ha avvisato i commercianti di una campagna che sfruttava una SQL injection, cioè un modo per far eseguire al database comandi non previsti, presente in versioni vecchie e in un modulo diffuso. Gli attaccanti creavano un file nella radice del sito, prendevano il controllo del server e inserivano nel checkout un falso modulo di pagamento che inviava i dati delle carte a loro.

Che cos'è uno skimmer e dove si nasconde

Uno skimmer è un piccolo script che legge quello che il cliente scrive nei campi della carta e lo manda a un server esterno. Il nome viene dai dispositivi applicati di nascosto ai bancomat. In un negozio PrestaShop può stare:

  • in un file del tema o di un modulo, modificato aggiungendo poche righe;
  • nel database, dentro una configurazione o un blocco di contenuto che viene stampato nella pagina di pagamento;
  • in un modulo di pagamento falso, che si presenta come un metodo in più o sostituisce quello vero.

Spesso si attiva solo nella pagina di pagamento, solo per alcuni visitatori o solo da mobile, proprio per non farsi notare da chi gestisce il negozio.

I segnali da non ignorare

  • Clienti che segnalano addebiti strani dopo un acquisto: è spesso il primo segnale, e arriva tardi.
  • Il checkout cambia aspetto: un campo in più, un passaggio nuovo, un metodo di pagamento mai configurato.
  • Amministratori sconosciuti nel back office, o accessi da paesi in cui non lavora nessuno.
  • File PHP nuovi in cartelle che non dovrebbero contenerne, come quelle delle immagini o della cache.
  • Rallentamenti improvvisi senza un motivo apparente: possono avere mille cause innocue, ma anche codice estraneo che gira a ogni pagina.
  • Avvisi esterni: Google Search Console, il gestore dei pagamenti, l'hosting che segnala traffico anomalo.

Le prime ore: cosa fare e cosa non fare

Fare: un backup dello stato attuale prima di toccare qualsiasi cosa, perché serve a capire cosa è successo e da quando; cambiare tutte le password, back office, database, hosting, FTP; avvisare chi gestisce i pagamenti se c'è il sospetto che i dati delle carte siano stati letti.

Non fare: ripristinare di corsa un backup vecchio senza aver trovato la falla, perché l'attaccante rientra dalla stessa porta in pochi giorni; cancellare file a caso, perdendo le tracce; aspettare "per vedere se succede ancora". Se ci sono dati personali coinvolti, il GDPR prevede la notifica al Garante entro 72 ore da quando si viene a sapere della violazione, anche se il quadro non è ancora completo (la notifica si può integrare dopo), e in molti casi anche l'avviso ai clienti: ne abbiamo parlato in GDPR lato infrastruttura.

Chiudere la porta, non solo pulire

Togliere lo skimmer è metà del lavoro: è quello che facciamo nella rimozione malware PrestaShop, insieme alla ricerca del punto di ingresso. L'altra metà è trovare da dove è entrato e chiudere quel passaggio: aggiornare o sostituire il modulo vulnerabile, aggiornare PrestaShop, spostare e proteggere l'area di amministrazione, limitare i tentativi di accesso come si fa con fail2ban contro gli attacchi brute force. E avere backup che si ripristinano davvero, puliti e conservati altrove, per non dover scegliere tra un negozio infetto e uno vecchio di mesi.

In sintesi

Un negozio PrestaShop hackerato non sempre si vede: l'attacco più comune contro un e-commerce punta al checkout e resta nascosto. I segnali ci sono, dagli addebiti segnalati dai clienti agli amministratori sconosciuti. Quando succede, servono un backup dello stato attuale, password nuove, una pulizia di file e database e, soprattutto, la chiusura della falla da cui è entrato. Il resto lo fanno aggiornamenti regolari e un back office protetto.

Fonti

Tux versione Gandalf, mascotte del blog init.d

init.d è il team di Alessandro Corbelli, sistemista Linux e sviluppatore backend con oltre vent'anni di esperienza. Progetta e gestisce infrastrutture cloud (Google Cloud, AWS, Azure), server farm e architetture ad alta disponibilità, e sviluppa software su misura in Laravel/PHP e Vue - dalla piattaforma di food delivery Take2Me ai gestionali dei nostri clienti. Su questo blog condividiamo note tecniche su Linux, sistemistica, sviluppo, DevOps ed e-commerce.


Altri articoli