Sicurezza Magento 2: aggiornare, rilevare e bloccare ClickFix, PolyShell e CosmicSting

I negozi basati su Magento 2 e Adobe Commerce sono un bersaglio permanente delle campagne di sfruttamento automatizzate. Ogni nuova release 2.4.x introduce una serie di patch di sicurezza e gli attaccanti le analizzano nel giro di pochi giorni per costruire exploit funzionanti contro i negozi che non sono ancora stati aggiornati. Questo articolo descrive le minacce più rilevanti osservate negli ultimi mesi, come riconoscere le tracce che lasciano sul server e quali passaggi eseguire per eliminarle e prevenire la prossima intrusione.

Perché le installazioni 2.4.x non aggiornate sono il bersaglio principale

Adobe pubblica con cadenza regolare i bollettini di sicurezza per Magento Open Source e Adobe Commerce, e ogni bollettino elenca le vulnerabilità corrette in quella release. L'intervallo tra la pubblicazione di una patch e la comparsa di una proof of concept pubblica oggi si misura in ore, non in settimane. Un negozio che resta su un livello di patch più vecchio sta di fatto eseguendo vulnerabilità già pubblicate e armate. La prima contromisura è quindi sempre la stessa: aggiornare il core all'ultima versione sicura e applicare tutte le patch e gli hotfix ufficiali rilasciati per il proprio ramo.

ClickFix: la falsa casella di verifica umana

ClickFix è una tecnica di ingegneria sociale che non sfrutta direttamente Magento, ma abusa della fiducia che i visitatori ripongono in un'interfaccia familiare. Su un negozio compromesso la pagina di checkout o la landing page viene modificata per mostrare un falso widget Cloudflare con la scritta 'verifica di essere umano'. Il visitatore clicca la casella esattamente come farebbe su una pagina di verifica legittima e uno script viene copiato silenziosamente negli appunti. In quel momento non accade nulla di dannoso e la pagina può persino sembrare che continui normalmente.

Il pericolo arriva al secondo passaggio. La pagina falsa invita il visitatore ad aprire una finestra del terminale su macOS o Windows e a incollare il contenuto copiato per completare la verifica. Se il visitatore obbedisce, il comando incollato scarica ed esegue un payload di secondo stadio sulla macchina del client. La regola per gli utenti è semplice e assoluta: non incollare mai nel terminale comandi provenienti da una pagina web. La regola per gli amministratori è trovare lo script iniettato, rimuoverlo e chiudere il punto di ingresso che ha permesso la modifica.

Compromissione lato server: PolyShell, CosmicSting ed env.php

Diverse famiglie di vulnerabilità hanno dominato i rapporti sugli incidenti Magento 2. PolyShell sfrutta gli upload di file senza restrizioni tramite la REST API per collocare file poliglotta che sono contemporaneamente immagini valide e PHP valido. CosmicSting colpisce il motore di template e può portare all'esecuzione di codice remoto non autenticata. StyleSmuggler e BlockStrap seguono schemi simili di injection nei template e bypass dei filtri. Nei casi più gravi l'attaccante legge env.php, estrae le chiavi crittografiche memorizzate e falsifica token di amministratore validi, ottenendo un accesso persistente al backend anche dopo la chiusura del percorso vulnerabile.

Cercare codice offuscato in app, vendor e cache

Il codice malevolo raramente è evidente. Gli attaccanti lo nascondono dentro template .phtml standard, dentro i moduli del core e dentro i file generati nelle directory cache e var. Una ricerca testuale delle parole chiave più comuni spesso non restituisce nulla, perché il payload viene assemblato a runtime a partire da stringhe base64 o da più frammenti concatenati. Un caso recente riguardava un file .phtml infetto nella cartella vendor, modificato solo in minima parte, con la stringa malevola suddivisa tra diverse variabili.

Confronta l'installazione con una copia pulita della stessa versione. Usa un controllo di integrità dei file, esamina le date di modifica e ispeziona ogni file che differisce dal pacchetto ufficiale. Quando trovi un file infetto non limitarti a cancellare il payload: ripristina la versione originale dall'archivio ufficiale, poi aggiorna o blocca il percorso vulnerabile che ha consentito la scrittura.

pub/media non deve mai contenere PHP

La directory media è pensata per archiviare immagini, PDF e altre risorse statiche. Non esiste alcun motivo legittimo perché un file .php, .php7, .phtml o .phar si trovi sotto pub/media. Gli attaccanti continuano comunque a caricarli, e i nascondigli preferiti sono pub/media/custom_options/ e pub/media/custom_options/quote/, dove vengono salvati i file delle opzioni caricate. Analizza queste directory in modo ricorsivo, rimuovi ogni file eseguibile che trovi e verifica che la configurazione degli upload rifiuti le estensioni inattese.

Bloccare al perimetro con Cloudflare, Nginx e Apache

Pulire il server non basta se il punto di ingresso resta aperto. Blocca i percorsi vulnerabili prima che la richiesta raggiunga Magento. In Cloudflare puoi creare una regola WAF che nega le richieste a /pub/media/custom_options/ e a directory simili, oppure che applica una verifica a qualsiasi richiesta diretta a un file PHP nel percorso media. Sul server di origine aggiungi regole equivalenti in Nginx o Apache, così la protezione continua a funzionare anche quando il traffico aggira la CDN.

Ricorda che una regola al perimetro ferma solo le richieste che già conosci. Abbinala alla patch, al monitoraggio dei file e a un controllo periodico del codice.

Lista di controllo per la bonifica

Conclusione

La sicurezza di Magento è un ciclo, non un compito unico. Applica le patch rapidamente, verifica l'integrità dei file, tieni il codice eseguibile fuori dalla directory media e blocca i percorsi di cui non hai bisogno. Se sospetti un'iniezione ClickFix, avvisa subito i clienti: il modo più rapido per fermare i danni è assicurarsi che nessuno incolli nulla in un terminale.