La prima e la seconda puntata di questa breve guida, basata sulle informazioni fornite da Google nell’ambito della campagna #NoHacked, hanno rispettivamente mostrato quali buone norme di sicurezza seguire e come individuare una determinata tipologia di hack (injected gibberish url). La terza ed ultima puntata vi mostrerà invece come intervenire direttamente sul portale colpito dall’hack per riportare tutto alla normalità.
La prima operazione da compiere è quella di mandare offline il vostro sito. In questo modo eviterete che ignari visitatori accedano alle pagine infette e clicchino sugli url generati dall’hack. I passaggi successivi, sottolinea la stessa Google, possono essere eseguiti solo da utenti esperti: nel caso non sappiate come procedere è bene valutare l’intervento di un tecnico qualificato.
Dopo che il sito è andato offline, occorre effettuare il backup del portale (manuale o con l’intervento del vostro provider). Ricordate che la copia di backup conterrà anche le pagine infette ma, nel caso vengano cancellati componenti critici del sito, consentirà di ripristinare velocemente i file accidentalmente eliminati. Il file .htacces è uno degli elementi da controllare accuratamente. L’hack in questione è infatti solito modificarlo inserendovi nuove linee di codice. Ecco un esempio di codice sospetto:
Tra gli altri obiettivi dell’hack troviamo anche file JavaScript e PHP. I malintenzionati agiscono solitamente in due modi: inseriscono nel sito dei file JavaScript e PHP che hanno dei nomi molto simili a quelli dei file “legittimi” (esempio: wp-cache.php invece dell’originale wp_cache.php); inseriscono codice malevolo all’interno di file già presenti nel sito (esempio: un template o un plugin JavaScript). Per riuscire ad aprire i file PHP, gli hacker sono soliti rendere illeggibili i file modificati, Google suggerisce l’utilizzo dei seguenti tool: PHP Decoder e UnPHP.
La terza fase del procedimento prevede l’eliminazione degli elementi compromessi ed il ripristino di una versione completamente pulita del sito. Per coloro che effettuano frequentemente backup si tratta di un’operazione relativamente facile – dispongono dei file non infetti grazie alle copie presenti in archivio. Nel caso non si disponga di copie di backup vi sono poche alternative: oltre all’eliminazione dei file compromessi bisognerà provvedere manualmente all’upload dei file “originali” (file PHP e JavaScript, file principali del CMS in utilizzo e dei relativi plugin).
La quarta ed ultima fase prevede una serie di verifiche e controlli dei quali abbiamo già parlato nelle puntate precedenti: cambio delle credenziali di accesso, aggiornamento del software in utilizzo, ulteriore scansione delle pagine con gli strumenti offerti da Google (Fetch as Google, Search Analytics etc) per accertarsi che qualsiasi file malevolo sia stato definitivamente eliminato.
