Web shell in PrestaShop: cosa sono, dove si nascondono e come trovarle

Quando qualcuno entra in un negozio, la prima cosa che fa quasi mai è rubare. La prima cosa è assicurarsi di poter tornare. Per questo lascia una web shell: un file PHP che, richiamato da URL, gli permette di elencare cartelle, modificare file, lanciare query sul database o eseguire comandi sul server. Così, anche se correggi la vulnerabilità da cui è entrato e cambi tutte le password, lui resterà dentro.

Questo articolo spiega come sono, dove si infilano in PrestaShop e come cercarle senza perderti tra i falsi positivi.

Che cos'è esattamente una web shell

È un piccolo programma scritto nello stesso linguaggio del negozio, che gira con i permessi dell'utente web. Non deve sfruttare nient'altro: se il server esegue PHP in quella cartella, la shell funziona. Ce ne sono di molte dimensioni:

• Loader di una riga. Trenta o quaranta byte che si limitano a includere un altro file. Il codice malevolo sta in quell'altro file, che spesso ha l'estensione di un'immagine.
• File manager completi. Un'interfaccia per navigare nel server, modificare, caricare, rinominare e cancellare, protetta da una password scritta nel file stesso.
• Esecutori di comandi. Ricevono un parametro e lo passano al sistema operativo.
• Moduli interi. Una cartella con la struttura di un modulo PrestaShop, file principale impeccabile e il carico nascosto in un controller.

Dove si nascondono in PrestaShop

L'attaccante cerca posti in cui un file nuovo non dia nell'occhio. In PrestaShop ci sono alcuni classici:

File in più nei moduli nativi

Un ajax.php o un config.php dentro la cartella di un modulo ufficiale che, nel pacchetto originale, non ha quel file. Nessuno guarda dentro i moduli forniti con il negozio, e il nome sembra lì da sempre. L'unico modo per accorgersene è confrontare la cartella con il pacchetto pubblicato dal suo autore.

Moduli orfani

Cartelle di moduli disinstallati che restano sul disco. Non compaiono nel gestore dei moduli, nessuno le aggiorna e il loro PHP resta raggiungibile da URL. Sono un nascondiglio comodo e, allo stesso tempo, una porta d'ingresso.

Il core e vendor/

Una riga incollata in fondo a un file del core (le classi del prodotto, il dispatcher, l'autoloader) o di una libreria di vendor/. Molti scanner escludono vendor/ perché genera rumore, ed è proprio per questo un buon posto. In incidenti reali sono state trovate più di una decina di backdoor in file legittimi dello stesso negozio, tutte aggiunte in fondo e senza alcuna parola sospetta in vista.

Immagini con PHP dentro

Un JPEG o un PNG perfettamente valido, che si apre in qualsiasi visualizzatore, con codice PHP aggiunto in fondo. Da solo non viene eseguito; lo esegue un loader che lo include. Per questo, se ne trovi uno, cerca anche l'altro.

Cartelle di dati

upload/, download/, img/ o translations/ non dovrebbero mai contenere un .php eseguibile. Se ne compare uno, non c'è una spiegazione innocente.

Come si camuffano

Le shell che durano mesi non sono quelle che urlano eval(base64_decode(...)). Sono quelle che sembrano codice normale:

• Hanno l'intestazione di licenza di PrestaShop copiata da un altro file, con il suo blocco di commenti e il controllo di versione all'inizio.
• Si chiamano come qualcosa di innocuo: uninstall.php, index.php, cron.php, o con un titolo che parla di un lettore di codici QR.
• Compongono i nomi delle funzioni pericolose a runtime, prendendo singole lettere da una stringa lunga. Nel testo non compare nessuna funzione vietata.
• Rispondono 404 se non ricevono la chiave giusta, proprio come un URL che non esiste. Scandagliare il negozio richiedendo percorsi non le trova.
• Conservano la data di modifica del file originale, per non comparire quando si ordina per data.

Come cercarle con criterio

L'ordine conta. Vai dal più conclusivo ed economico al più costoso:

1. È identico a quello pubblicato dal suo autore? Confronta il core con lo ZIP ufficiale della tua versione esatta (quello della release, non il repository, che porta cartelle di sviluppo e produce centinaia di differenze false) e ogni modulo con il suo pacchetto. Un file identico byte per byte non è infetto.
2. Era nel pacchetto? Ciò che non c'era l'ha messo qualcuno dopo. Questa domanda trova file che nessun pattern rileverebbe, perché possono essere scritti in modo impeccabile.
3. È cambiato dall'ultima volta? Se hai una baseline di integrità di quando il negozio era pulito, qualsiasi modifica senza un aggiornamento alle spalle è una risposta.
4. Che cosa sa fare? Per ciò che non ha un riferimento: elencare directory e scrivere file con un percorso che arriva da parametro, eseguire comandi, leggere file di sistema, password confrontate con un hash salvato nel codice stesso.
5. Da dove si raggiunge? Un controller controllers/front/ di un modulo si richiama da Internet senza sessione; uno di controllers/admin/ richiede la sessione di un dipendente. Questo decide se bisogna intervenire stanotte o domani.

E una regola per il rumore: se segni qualcosa come sicuro, fallo tramite l'hash del contenuto, non tramite il percorso. Un'eccezione per percorso continuerà a coprire quel file il giorno in cui qualcuno lo sostituisce.

Perché non basta cancellarla

Cancellare la shell è l'ultimo passo, non il primo. Prima di toccarla:

• Salva una copia del negozio così com'è, per sapere che cosa ha fatto e da quando.
• Controlla se ha lasciato altre porte. Chiavi in authorized_keys degli account del server, nuovi dipendenti nel back office, account del webservice con permessi ampi e attività pianificate che scaricano ed eseguono qualcosa ogni pochi minuti. Cancellare un file non chiude una chiave SSH né un cron.
• Trova la via d'ingresso. Un modulo vulnerabile, una password FTP rubata, una versione di PrestaShop senza patch. Se non la chiudi, la shell torna nel giro di giorni.
• Cambia le credenziali dopo la pulizia, non prima: database, FTP, pannello, dipendenti e la chiave dei cookie se sospetti che abbiano letto la configurazione.

E una volta pulito, il solito: PrestaShop, PHP e moduli aggiornati. La stragrande maggioranza degli accessi sfrutta falle già corrette in versioni che il negozio non aveva installato.

Come risolverlo in PrestaShop

RKR Security Alert analizza i file del negozio alla ricerca di skimmer, backdoor e web shell, comprese quelle senza firme pericolose: riconosce le shell da ciò che sanno fare, i loader che includono un'immagine, il PHP nascosto dentro immagini valide e i file con nomi di funzione composti per indici. Confronta il core con lo ZIP ufficiale, indica per ogni risultato se è raggiungibile da URL e senza sessione, e mantiene una baseline di integrità che si costruisce solo quando dai per verificato il primo audit, per non considerare buona un'infezione precedente. Avvisa via Telegram, salva gli avvisi nel negozio e non invia nessun file fuori dal server. RKR Sentinel completa la sorveglianza avvisandoti di errori PHP, risposte 500 e pagamenti che non diventano ordini, spesso il primo sintomo visibile che qualcosa è stato toccato.