StyleSmuggler evolve: Magento colpito da chronyd e da una seconda web shell

🛡️ Executive Summary

• StyleSmuggler evolve rapidamente: la backdoor Linux abbandona kworker, si maschera da fc-cache e chronyd e nasconde il C2 nel traffico NTP.
• Sansec individua un secondo attaccante che sfrutta la stessa zero-day Magento per installare una web shell PHP nascosta nella cache dei prodotti.
• Adobe conferma di lavorare a una patch ma senza ETA: fino al fix occorre cercare compromissioni già avvenute e valutare il blocco temporaneo di GraphQL.

La campagna StyleSmuggler contro Magento Open Source e Adobe Commerce sta cambiando mentre gli attacchi sono ancora in corso. Nel giro di poche ore la backdoor Linux associata alla zero-day è passata dal camuffamento come kworker a varianti denominate fc-cache e chronyd, con traffico di comando e controllo costruito per assomigliare alle normali sincronizzazioni NTP sulla porta UDP 123. Il 7 settembre Sansec ha inoltre individuato un secondo attaccante indipendente che sfrutta la stessa falla per installare una web shell PHP nella cache delle immagini dei prodotti. Adobe Enterprise Support ha confermato di essere al lavoro su una correzione, ma al momento non esiste ancora una data di rilascio.

La backdoor StyleSmuggler cambia nome da kworker a chronyd

La prima versione dell’impianto osservato dopo lo sfruttamento di StyleSmuggler utilizzava il nome [kworker/u:8:0], imitando un normale processo kernel Linux. L’analisi aggiornata pubblicata da Sansec mostra però un’evoluzione rapidissima dell’operazione: il 6 settembre sono apparse build x86-64 e arm64 che si presentano come fc-cache, copiano il binario in ~/.cache/fontconfig/fc-cache e impostano una persistenza tramite cron due volte ogni ora. Il 7 settembre un’altra variante ha iniziato a utilizzare il nome chronyd, lo stesso del demone normalmente impiegato dai sistemi Linux per la sincronizzazione dell’orologio. Il passaggio non è soltanto cosmetico: Sansec ha verificato che il nuovo implant conserva lo stesso identificatore dell’agente della variante precedente, indicando un aggiornamento della medesima famiglia di malware dalla versione 2.1.4 alla 2.1.5. In almeno un caso chronyd è riuscito inoltre a rilanciarsi senza alcuna voce cron visibile, con processo padre impostato a PID 1, rendendo insufficiente il semplice controllo di crontab -l per stabilire che un server sia pulito.

Leggi anche: StyleSmuggler buca Magento: zero-day RCE installa backdoor nei negozi online

Il traffico C2 imita NTP sulla porta UDP 123

La variante fc-cache e quella successiva chronyd cercano di sfruttare una delle assunzioni più comuni nella gestione delle reti: il traffico NTP proveniente da un processo chiamato chronyd tende a non essere considerato anomalo. L’impianto risolve domini come ntp.timesync.to e invia sulla porta UDP 123 pacchetti da 48 byte costruiti per sembrare risposte NTP. Soltanto i primi quattro byte corrispondono però realmente al protocollo; il resto contiene dati serializzati in MessagePack relativi all’agente compromesso, tra cui identificatore, hostname, username, versione del sistema operativo, memoria, spazio disco, uptime, privilegi root e versione del malware. Sansec ha osservato una sequenza di nove datagrammi ogni 60 secondi, emessi a pochi millisecondi di distanza e marcati come messaggi NTPv4 in modalità server, comportamento incompatibile con quello di un normale client chronyd. Al 7 settembre i domini principali utilizzati dal malware risolvevano verso 185.157.160.251, mentre le prime build avevano utilizzato anche il C2 99.84.67.186:443 attraverso WebSocket su TLS. L’attaccante sta quindi cercando di ridurre contemporaneamente la visibilità del processo e quella della comunicazione di rete, facendo apparire entrambe come attività ordinaria del sistema operativo.

Un secondo gruppo sfrutta StyleSmuggler per installare una web shell PHP

L’evoluzione più grave emersa il 7 settembre riguarda però un payload completamente differente. Sansec ha analizzato un dropper PHP di appena 485 byte che non condivide infrastruttura o codice con la backdoor Rust precedente, ma utilizza le stesse vittime e sfrutta StyleSmuggler come punto di ingresso. Il payload scarica codice da un server compromesso e crea una web shell nel percorso pub/media/catalog/product/cache/ss_<10hex>/sync_<10hex>.php, nascondendola all’interno delle directory hash generate normalmente dalla cache dei prodotti Magento. La shell utilizza inoltre una protezione elementare ma efficace contro scansioni casuali: senza uno specifico header X-Cache-Token restituisce semplicemente HTTP 404, mentre in presenza del token corretto esegue il codice PHP ricevuto attraverso il parametro POST task. Sansec ha recuperato il dropper all’interno di un header Store: registrato da Magento, confermando che anche questo secondo operatore è entrato attraverso la nuova zero-day. Il risultato cambia la valutazione dell’incidente: StyleSmuggler non è più soltanto la vulnerabilità utilizzata da una singola infrastruttura malware, ma è già diventata una porta d’ingresso condivisa da attori differenti, uno scenario già osservato in passato quando più gruppi criminali si sono contesi contemporaneamente negozi Magento compromessi per inserire skimmer e rubare dati di pagamento.

I controlli devono cercare processi, cron e PHP fuori dai percorsi attesi

Gli amministratori non possono quindi limitarsi alla ricerca del vecchio [kworker/u:8:0]. Gli indicatori aggiornati comprendono fc-cache, chronyd, directory temporanee sotto /tmp, il percorso ~/.cache/fontconfig/fc-cache e le precedenti installazioni in ~/.local/share/.gvfsd/. Particolare attenzione va riservata direttamente ai file dello spool cron, perché alcune varianti scrivono la persistenza senza passare dall’interfaccia crontab, mentre altre possono rilanciarsi senza cron. Un ulteriore segnale gratuito individuato da Sansec compare nei server dove l’utente web non dispone dei permessi per modificare il crontab: il malware continua a tentare l’operazione e genera ripetutamente nei log messaggi crontab command not allowed. Per il secondo attaccante diventa invece necessario controllare la presenza di file PHP dentro pub/media, posizione nella quale normalmente non dovrebbe comparire una web shell eseguibile. Restano validi anche gli indicatori già emersi nella prima analisi della campagna StyleSmuggler, tra cui improvvisi messaggi Payment Transaction Failed Reminder, marker sospetti nei report e attività GraphQL anomala; il link precedente non va però considerato un sostituto dell’analisi forense, perché gli attaccanti stanno già modificando processi, persistenza e infrastruttura.

Adobe lavora alla patch ma il prossimo bollettino non è ancora una garanzia

Il quadro resta aggravato dall’assenza, al momento della verifica del 7 settembre, di una patch ufficiale specifica. Sansec riferisce che Adobe Enterprise Support ha confermato di essere al lavoro su una correzione, senza però fornire un ETA. Il prossimo ciclo programmato di sicurezza Adobe Commerce è previsto per 8 settembre, ma non risulta ancora confermato che includerà StyleSmuggler. L’ultimo aggiornamento disponibile, APSB26-92 dell’11 agosto, aveva già corretto vulnerabilità capaci di produrre esecuzione arbitraria di codice, escalation dei privilegi e bypass delle funzioni di sicurezza, come ricostruito nel precedente ciclo di patch Adobe Commerce e Magento. StyleSmuggler resta però esterna a quel pacchetto: la prima vittima esaminata da Sansec utilizzava Magento 2.4.6-p15 con le patch di luglio e agosto installate e security:patch-status pulito, mentre la catena è stata riprodotta su installazioni pulite delle versioni 2.4.7, 2.4.8 e 2.4.9. Per chi non dispone di una protezione specifica, Sansec continua a indicare la disabilitazione temporanea di GraphQL come misura di contenimento fino alla disponibilità del fix ufficiale.

Continua con:

• Google Tag Manager usato per rubare dati delle carte di credito dai siti Magento
• Adobe corregge tre falle CVSS 10.0 e aggiorna Adobe Commerce

Installare la futura patch non basterà sui server già compromessi

L’evoluzione osservata tra il 4 e il 7 settembre mostra perché l’arrivo della patch Adobe, pur essendo fondamentale, non potrà chiudere automaticamente gli incidenti già avvenuti. Una correzione bloccherà il vettore di ingresso, ma non eliminerà backdoor Rust, processi chronyd fasulli, cron persistenti o web shell PHP installati prima dell’aggiornamento. La comparsa di un secondo attaccante indipendente rende inoltre possibile che lo stesso server abbia ricevuto più payload attraverso una sola vulnerabilità. Sansec raccomanda di ruotare le credenziali Magento quando viene individuato un processo sospetto e di verificare direttamente gli indicatori pubblicati durante l’indagine. Per gli e-commerce esposti dal 4 settembre in poi la priorità diventa quindi duplice: bloccare nuovi tentativi di sfruttamento e determinare se l’accesso sia già avvenuto. StyleSmuggler sta dimostrando in tempo reale la dinamica più pericolosa di una zero-day su una piattaforma Internet-facing: appena la catena funziona, l’intervallo tra scoperta, replica da parte di nuovi gruppi e diversificazione dei payload può ridursi a poche ore.