Il 22 Luglio 2022 è arrivato un avviso di PrestaShop riguardo a una vulnerabilità che permette a un malintenzionato di prendere il controllo del tuo ecommerce basato su questo CMS, allo stato attuale non sono ancora chiare tutte le dinamiche di questo exploit appena scoperto. Va subito premesso che la vulnerabilità non sembra riguardare le versione 1.7.8.2 e le versioni successive. Però se la tua versione è ancora una 1.6 o una 1.7 più datata è necessario metterla in sicurezza.

Come funziona l'attacco

Le dinamiche precise sono ancora sotto esame, ma l'attacco richiede che l'ecommerce sia vulnerabile a SQL injection exploits. Gli aggressori prendono di mira i negozi che  hanno moduli non aggiranti o con vulnerabilità già conosciute. Tra cui il modulo Wishlist (blockwishlist). È importante precisare che l'attacco sfrutta una vulnerabilità legata alla Cache Smarty salvata in MySQL, un'opzione raramente attivata in quanto i vantaggi rispetto la cache su file system sono spesso minimi se non peggiorativi.

Potete verificare se questa cache è attiva andando in Parametri Avanzati > Prestazioni

Il fatto che non sia attiva, non assicura d'essere al sicuro, in quanto sembra che gli aggressori riescano ad attivarla sfruttando altre vulnerabilità in moduli di terze parti. Non ritengo però che l'attacco effettuato in prima istanza via bot, vada poi a cancellare le tracce del suo passaggio. Quindi se la voce la trovate disabilitata molto probabilmente non siete stati compromessi, comunque dopo un exploit simile un controllo generale è d'obbligo. 

La procedura rilevata è la seguente:

  • Viene inviato un attacco tramite POST per controllare se l'obbiettivo è vulnerabile.
  • Subito dopo viene inviata una richiesta GET senza parametri alla home, che si traduce in un file PHP chiamato blm.php nella root della nostra installazione PrestaShop.
  • L'attaccante invia poi richieste al file creato e eseguire operazioni direttamente sul nostro ecommerce.

Una delle attività rilevate dopo che i criminali hanno preso il controllo del nostro negozio, è l'installazione in front-end di un modulo di pagamento falso. Così da rubare i dati delle carte di credito nei nostri clienti. Qui va sottolineato che in Europa con il 3D Secure questi attacchi sono meno devastanti. Questa però può essere solo una delle modalità usate, gli aggressori possono utilizzare un nome diverso da blm.php per per il file e inserendo codice dannoso altrove e con finalità diverse. Se l'attacco è andato a buon fine possono pure cancellare le loro tracce. 

Il problema è serio, ma la modalità ha successo solo in particolari situazioni. Occorre però mettersi in sicurezza, per aver la certezza di non essere vulnerabili.

Come mettersi al sicuro?

Prima di tutto come detto l'attacco sfrutta la cache smarty su mysql, se usate questa modalità passate alla cache su file system, quindi subito su Parametri Avanzati > Prestazioni, già ora che leggi questo mio articolo. Poi in attesa di una PATCH ufficiale, modificate il file config/smarty.config.inc.php come consigliato nell'avviso di PrestaShop. Si tratta di rimuovere o commentare una piccola porzione di codice, questa porzione di codice non serve a nulla se non usate la cache su mysql, quindi la modifica non servirà ripristinarla in futuro.

Questo codice lo trovate nella versione 1.6 alla riga 40-43 e nella 1.7 alla riga 43-46.

Basta solo commentare questo blocco quindi:

Una volta fatto, il vostro ecommerce è al sicuro da questo attacco, ma non lo è da altri attacchi e non è detto che non sia già stato compromesso. 

Torno a consigliare di tenere sempre tutti i moduli aggiornati, disinstallare quelli non usati e aggiornare PrestaShop, questo exploit non è l'unico ce ne sono di più gravi e di minori che affliggono molte versioni datate. Qui potete visionare le vulnerabilità conosciute: 

https://www.cvedetails.com/vulnerability-list/vendor_id-8950/Prestashop.html

È bene precisare che questo vale per tutti i CMS e Software, pure WordPress, Joomla, Magento ecc.. un sistema sicuro è uno aggiornato.

Come verificate se il vostro PrestaShop è compromesso?

Questo tipo di attacco rende più difficile capire se si è vittime, una volta preso il controllo come accennato, i criminali possono cancellare le loro tracce lasciando una backdoor ben nascosta e modifiche a file di moduli o del core del CMS. Le dinamiche sono simili alla vulnerabilità che riguardava PHPUnit (CVE-2017-9841). Nel caso specifico non trovare il file blm.php nella root o nei log non è garanzia di sicurezza che non si è già stati hackerati. 

Quindi si un controllo potete farlo, ma consiglio di verificare i file modificati o aggiunti di recente, cosa possibile da fare via SSH. Una cosa molto utile è controllare se c'è del codice criptato o codificato, per esempio in base64: la cui presenza è sempre sospetta. Tenete presente che per i moduli acquistati su Prestashop Addons è vietato usare questi sistemi, quindi un modulo che li usa non sarebbe presente a catalogo.

Alcuni tools presenti su cPanel e Plesk possono essere molto utili a identificare eventuali file infetti, per esempio ImunifyAV.

Ricordo comunque l'accesso SSH al proprio Hosting permette di usare il comando find per ottenere tutti i file modificati di recente, filtrandoli per estensione, quindi cercando modifiche principalmente a file .php e .tpl nel caso di PrestaShop. Esistono pure qui tools lato Server per cPanel e Plesk che permettono di tenere monitorate le modifiche a determinati file / cartelle.

Autore: Loris Modena

SENIOR DEVELOPER

Per Ind Loris Modena titolare di Arte e Informatica, inizia a lavorare nel settore informatico nel 1989 quale sistemista addetto alla manutenzione e installazione di sistemi informatici. Inizia a programmare per il web nel 1997 occupandosi di programmazione CGI in PERL e successivamente passando alla programmazione in PHP e JavaScript. In questo periodo si avvicina al mondo Open source e alla gestione di server Linux. 

prodotto aggiunto alla lista