La notizia non è che un WordPress sia stato sfondato, ma come.
In questo momento il sito del PD Toscana mostra questa immagine di apertura:
Ad un’analisi superficiale potrebbe apparire che degli abilissimi hacker abbiano rubato le credenziali al webmaster. (altro…)
Se sì e se è un utente valido siete dei gonzi.
La tabellina a fianco mostra l’elenco di IP che in meno di 10 ore ieri hanno tentato almeno 5 login come admin a questo sito.
Probabilmente è un programma utilizzato da qualche script kiddie, ma non per questo meno pericoloso, specialmente se poi il sito viene trapanato.
Il report è generato dal plugin Limit Login Attempts, che merita sicuramente di essere installato su un WordPress esposto ad Internet.
Le funzioni del plugin sono essenziali, ma ci sono tutte quelle che servono: numero di tentativi, durata della prima blacklist, tentativi che scatenano la seconda blacklist e relativa durata, tempo dopo il quale vengono resettati i contatori. Si può anche fare in modo di notificare l’amministratore (quello legato all’utente admin…) quando scatta una blacklist di secondo livello.
Un plugin come Limit Login Attempts è fondamentale in quanto in WordPress non sono (ancora?) disponibili funzioni integrate di lockout degli utenti.
Nella sicurezza non esiste un solo silver bullet, ma ci sono tanti piccoli accorgimenti che aiutano a rafforzare un sistema.
Uno dei problemi dei siti è il controllo e l’isolamento dei file caricati dagli utenti o da sconosciuti. Ci sono vari modi per mitigare eventuali problemi che si possono verificare quando viene caricato un file indesiderato, qui ne viene esposto uno, ben sapendo che non si tratta dell’unico.
Il tipico esempio di directory pericolosa per un sito è la directory /wp-content/uploads di WordPress. Un metodo per mitigare gli attacchi è disabilitare qualsiasi tipo di esecuzione di script o programmi da questa directory da parte di Apache aggiungendo queste direttive alla configurazione del sito:
<Directory /path/wp-content/uploads/>
AllowOverride none
RemoveHandler .cgi .pl .py
<FilesMatch "\.(php|p?html?)$">
SetHandler none
</FilesMatch>
</Directory>
In questo modo nessun file CGI, Perl, Python o PHP caricato in quella directory potrà essere interpretato come tale se richiamato da Apache.
Come molti siti basati su WordPress, anche questo subisce un sacco di attacchi.
Fino a pochi giorni fa gli unici sistemi di difesa erano dei plugin come Secure WordPress che nascondono informazioni utili a chi vuole fare un attacco, sia esso mirato o scripted.
Di recente sono usciti scanner come WPScan che non solo portano un attacco a forza bruta contro il sito, ma rieschiano anche di creare dei DoS totali o parziali a causa del sovraccarico a cui sottopongono il sistema.
(altro…)Qualche tempo fa ho attivato il servizio gratuito di Website Defender su questo blog come parte del plugin Secure WordPress.
Al pari del plugin, il servizio aggiunge un utile livello di paranoia alla normale sicurezza di un sito basato su WordPress.
Periodicamente Website Defender segnala i file modificati dall’ultima scansione e compie delle analisi sulle pagine per evitare problemi.
Poco fa il report periodico mi ha informato che una pagina potrebbe rivelare l’IP interno del server. È evidentemente un falso allarme, in quanto il sistema automatico di analisi ha scambiato un numero espresso con la notazione italiana (punto che separa le migliaia) per un indirizzo IPv4 appratente ad uno dei range assegnati alle reti interne.
Questo esempio dimostra quanta distanza ci sia ancora tra una regular expression e un’interpretazione semantica dei contenuti.
Secondo Google la solita frase “Tanto chi vuoi che sia interessato al mio blog?” ha oltre 50.000 vittime.
Nei 51.500 risultati ci sono alcuni blog che trattano questa notizia, tutti gli altri sono blog infettati da siteurlpath.
I blog infettati sono tutti WordPress e, ovviamente, tutti non aggiornati. Nota per la Curva Sud dei tifosi del software: l’accento non è su WordPress, bensì su non aggiornato.
Continuate così, fateci del male. (via sicuri.net)
È una delle massime più comuni nell’informatica ed è uno degli errori più ricorrenti.
Ci sono cascato anche io. Ovviamente.
È stata scoperta una vulnerabilità nell’utility TimThumb utilizzata da molti temi di WordPress per visualizzare le immagini.
TimThumb è ampiamente utilizzato da numerosi temi, sia gratuiti sia commerciali.
La vulnerabilità può essere sfruttata per caricare ed eseguire del codice PHP direttamente dalla directory di cache di TimThumb.
Per risolvere il problema bisogna cercare il file timthumb.php all’interno dell’installazione di PHP e modificarlo, se necessario. Se viene utilizzato da un tema, il file si trova in wp-content/themes/[nome del tema]/ o in una delle sue sottodirectory.
Il metodo per trovare il file, se esiste, e di editarlo dipende dall’installazione di WordPress e dalla modalità con cui si accede ad essa.
Una volta identificato il file, bisogna cercare nelle prime righe se esiste questo pezzo di codice:
// external domains that are allowed to be displayed on your website
$allowedSites = array (
'flickr.com',
'picasa.com',
'blogger.com',
'wordpress.com',
'img.youtube.com',
'amazonaws.com',
);
che deve essere sostituito con un array vuoto:
// external domains that are allowed to be displayed on your website $allowedSites = array ();
Se il codice non esiste, si sta utilizzando una versione più vecchia dell’utility, che non dovrebbe essere interessata dal baco.
Per la cronaca, la skin di Siamo Geek non contiene TimThumb. (via The Hacker News)