UNA PRIMA ANALISI DELL’ATTACCO
Gli istanti successivi li ho passati ad analizzare i logs (v. figura 4) e dopo alcune ore insonni ho scoperto una cosa interessante: l’attaccante utilizzava una vulnerabilità del tema che gli consentiva di “iniettare” del codice HTML nella index.php tramite query SQL (tecnica SQL injection).
Figura 4.
(Elenco dei logs risultato dell’attacco hacker)
L’SQL injection è un tipo di attacco condotto frequentemente verso i siti web sviluppati con WordPress o Joomla. La modifica del codice SQL e quindi l’estrazione o la manipolazione delle informazioni presenti nei database MYSQL è una delle tecniche più usate e “più semplici” per cancellare un sito web o “postare” una nuova index. In particolare, i moduli di contatto utilizzati per dare la possibilità agli utenti di interagire, molte volte, nascondono delle vulnerabilità.
Facciamo un esempio:
Se il vostro modulo di contatto è stato sviluppato con un linguaggio PHP una parte del codice potrebbe essere la seguente:
$query1: “SELECT * FROM utenti WHERE nomeutente = ‘”+$nomeutente+”‘ AND password = ‘”+password”;
L’interrogazione SQL $query1 al database MYSQL sembra corretta dal punto di vista del codice, ma in termini di sicurezza è vulnerabile. Infatti, se al posto di password inserite nel modulo di contato poex’ OR 1=1, il codice eseguito non è quello scritto nella query1, ma viene modificato da un codice iniettato presente dopo la virgoletta della password ossia OR 1=1.
Ovviamente, non è così semplice “iniettare” del codice SQL aggiuntivo, ma l’errore nell’esempio, è stato quello di non “filtrare” il codice SQL e di rendere così vulnerabile ill modulo di contatto. E’ proprio per tale motivo che le vulnerabilità principali di WordPress o Joomla sono costituite dai moduli di contatto, dai temi o dai plugins non aggiornati o comunque vulnerabili a queste tecniche di hacking.
A questo punto, dovevo far di più, e quindi verificai i permessi di alcune directory del sito tramite collegamento FTP. Mi accorsi che erano impostati correttamente, ma per evitare altre sorprese cambiai tutti i permessi al valore 705. Allo stesso tempo cambiai tutte le password e le resi estremamente complesse. Ricordate, che la pagina di login wp-admin è importantissima e che una debolezza in tal senso vi potrebbe costare cara (ma di questo parlerò nella seconda parte dell’articolo). Eseguii un altro backup della configurazione e del contenuto del dominio, e andai a dormire.
Per la cronaca, impostare, un valore 755 significa permettere al proprietario di leggere. scrivere ed eseguire i files (7), consentire al gruppo del proprietario di leggere ed eseguire i files (5), e infine far eseguire e leggere agli altri (5). Un valore 705 significa sostanzialmente bloccare il gruppo del proprietario.
UNA PRIMA VITTORIA
Dopo circa un giorno, Pippo non era stato violato, la index era intatta e tutto filava come doveva, ma non avevo ancora finito con le procedure di difesa e con le verifiche. Volete sapere chi ha vinto? La prossima parte sarà disponibile a breve solo per gli utenti registrati.
In breve, le azioni di difesa in questa prima parte sono state le seguenti:
1) Backup della configurazione e del contenuto del dominio.
2) Identificazione ed esclusione dell’indirizzo IP dell’attaccante.
3) Cambio dei permessi di alcuni files tramite FTP.
4) Modifica di tutte le password di accesso e di collegamento (FTP, dominio…..).
Se avete subito un qualche attacco al vostro sito in WordPress contattatemi all’indirizzo webmaster@megalinux.cloud per maggiori informazioni.
Come al solito, per eventuali domande e integrazioni inviate un e-mail a webmaster@megalinux.cloud. Aiutate a sostenere The Megalinux, l’unico sito nel Web senza pubblicità inviando Bitcoin al seguente indirizzo.
3LpoukFpvDHTZPn5qGbLwUzve3rX9zsSq6
