SQL injection nei moduli PrestaShop: come scoprire gli amministratori falsi

Apri l'elenco dei dipendenti nel back office e vedi account che non hai creato. A volte uno, a volte diversi di fila, con email simili e tutti con il profilo di superamministratore. Nessuno è entrato con la tua password: li ha scritti un programma direttamente nel database, sfruttando un modulo con una falla di SQL injection.

È uno degli schemi di attacco più ricorrenti contro PrestaShop. Vediamo come funziona, come rilevarlo e cosa fare.

Che cos'è una SQL injection, in un negozio

Un modulo riceve un dato dalla richiesta (un identificativo, un testo di ricerca, un filtro) e lo inserisce in una query al database senza ripulirlo. Se al posto del numero atteso arriva un pezzo di SQL, il database lo esegue. In PrestaShop la difesa di base è semplice: convertire in intero ciò che deve essere un numero e passare per pSQL() ciò che è testo. Il problema è che non tutti i moduli lo fanno in tutti i loro punti di ingresso.

I più pericolosi sono i controller front dei moduli: URL pubblici, accessibili senza effettuare l'accesso, pensati per il carrello, per una ricerca Ajax, per un filtro o per il ritorno da un gateway di pagamento. Se uno di questi ha la falla, chiunque su Internet può sfruttarla.

Com'è la campagna tipica

1. Scansione di massa. Un robot passa in rassegna migliaia di negozi cercando la presenza di moduli con vulnerabilità note. Non sceglie te: gli basta che tu abbia installata la versione vulnerabile.
2. Sfruttamento. Invia la richiesta che inietta un INSERT nella tabella dei dipendenti, o un UPDATE che alza il profilo di un account esistente.
3. Raffica. Siccome il robot non sa se ha funzionato, ripete. Per questo capita spesso di trovare diversi account creati quasi nello stesso momento, con identificativi consecutivi.
4. Uso successivo. Con l'account, qualcuno entra nel back office, installa un modulo che in realtà è una backdoor, cambia i dati di un metodo di pagamento o inietta uno skimmer nel template del checkout.

Come rilevarlo in ps_employee

La tabella dei dipendenti (con il prefisso del tuo negozio, di solito ps_) è piccola e facile da controllare. Da phpMyAdmin o dallo strumento di database del tuo hosting:

SELECT id_employee, firstname, lastname, email, id_profile, active, last_passwd_gen FROM ps_employee ORDER BY id_employee DESC;

Cosa guardare:

• id_profile = 1 è il profilo di superamministratore. Conta quanti ne hai e se li riconosci tutti.
• Identificativi consecutivi in fondo all'elenco che nessuno del tuo team ha creato.
• Email che non sono del tuo dominio o con nomi generici.
• Nomi e cognomi vuoti o ripetuti, che una creazione dal back office non lascia passare.
• last_passwd_gen con date che non corrispondono a nessuna creazione che ricordi.
• Account vecchi che hanno cambiato profilo: un dipendente della logistica che all'improvviso è superamministratore.

Nella stessa visita controlla anche gli account del webservice (Parametri Avanzati → Webservice). Una nuova chiave API con permesso di scrittura sulla configurazione è una porta che sopravvive al cambio di tutte le password e che non compare nel menu dei dipendenti.

Cosa fare se ne trovi uno

1. Non cancellare ancora: disattiva. Rendi l'account inattivo e conserva i suoi dati. Ti serviranno per sapere da quando e che cosa ha fatto.
2. Controlla che cosa ha toccato. Moduli installati di recente, modifiche alla configurazione dei metodi di pagamento (IBAN del bonifico, chiavi del gateway), template del checkout, dipendenti e webservice, e gli URL del negozio.
3. Cerca file nuovi. Di solito, con l'accesso, è stata lasciata una backdoor sul disco. Confronta il core e i moduli con i loro pacchetti originali.
4. Individua il modulo vulnerabile. I log di accesso del server mostrano spesso richieste strane a un controller di modulo poco prima della comparsa dell'account. Quel modulo va aggiornato o rimosso.
5. Cambia le credenziali: le password di tutti i dipendenti, le chiavi del webservice e, se ci sono indizi che abbiano letto la configurazione, la password del database.
6. Verifica gli ordini recenti con la banca o il gateway, nel caso il denaro sia stato dirottato.

Perché la prevenzione è aggiornare i moduli

Le campagne di massa quasi mai usano falle sconosciute. Usano vulnerabilità pubblicate, spesso con una patch disponibile da mesi. Il robot funziona perché molti negozi non aggiornano i loro moduli, o perché il modulo vulnerabile è stato abbandonato dal suo autore e nessuno l'ha sostituito.

Alcune misure concrete:

• Inventario dei moduli con versione e provenienza. Sapere che cosa hai è il primo passo per sapere che cosa ti riguarda quando esce un avviso.
• Aggiorna prima su una copia e poi in produzione, ma aggiorna. Un modulo non aggiornato da due anni è una scommessa.
• Rimuovi ciò che non usi, comprese le cartelle dei moduli disinstallati rimaste sul disco.
• Segui gli avvisi di sicurezza di PrestaShop e degli autori dei tuoi moduli.
• Tieni PrestaShop e PHP su versioni supportate. Molti moduli smettono di ricevere patch per le versioni vecchie: se il tuo negozio è ancora sulla 1.6 o su una 1.7 dei primi tempi, ogni nuovo avviso ha più probabilità di restare senza soluzione per te, e la migrazione diventa anche una misura di sicurezza.

Un firewall applicativo può frenare parte dei tentativi, ma non sostituisce la patch: le varianti di una stessa injection sono tante, e ne basta una che passi.

Come risolverlo in PrestaShop

RKR Security Alert salva un'istantanea dei dipendenti, dei moduli, della configurazione, degli URL del negozio e degli account del webservice, e la confronta con lo stato attuale a ogni caricamento del back office e tramite cron. Per questo rileva un superamministratore creato con SQL injection anche se non è passato da nessun hook, e lo segnala via Telegram come allerta massima, separata dal resto; anche quando un account esistente viene promosso a superamministratore o compare un nuovo account del webservice. Il suo scanner include un analizzatore di SQL injection che segnala i valori della richiesta che arrivano a una query senza conversione né escape. Se hai già il sospetto o l'incidente in corso, con un pacchetto di ore di assistenza di Rekire facciamo l'audit, troviamo il modulo da cui sono entrati, puliamo e lasciamo il negozio aggiornato.