Wordstress, uno scanner di vulnerabilità WordPress scritto in Ruby e tutto italiano.

Wordstress. Cos’è ?

Wordstress è uno scanner di sicurezza whitebox per i siti web wordpress .

I proprietari dei siti WordPress non vogliono perdere tempo nella lettura di rapporti di scansione di sicurezza blackbox complessi cercando di rimuovere i falsi positivi .

Uno strumento di sicurezza utile deve dare loro solo le vulnerabilità che interessano davvero plugin o temi installati, eliminando dunque falsi positivi e rimanendo molto attendibili.

Per raggiungere questo obiettivo , il plugin wordstress deve essere installato e configurato con una chiave di accesso unica sul sito web di destinazione. Lo scanner wordstress userà la chiave per accedere alle informazioni fornite dal plugin per individuare problemi di sicurezza .

Wordstress utilizza API al database di problemi di sicurezza fornito da wpvulndb.com

La pagina ufficiale del plugin la si può trovare qui : https://wordpress.org/plugins/wordstress/

L’autore, Paolo Perego, classe 1976 Milanese, può essere seguito e contattato su http://armoredcode.com/thesp0nge/ , specializzato in application security e sicurezza del Web è sicuramente indicato per gli interessati al settore.

 

WordPress XMLRPC, più di 162.000 siti WordPress utilizzati per attacco DDOS

ddosGli attacchi DDOS stanno diventando una tendenza comune ultimamente, ed è una questione molto seria per ogni proprietario del sito. Oggi vi voglio parlare di un grande attacco DDOS che ha sfruttato migliaia di siti web WordPress ignari come vettori di amplificazione.

Qualsiasi sito WordPress con Pingback abilitato (che è attivata per impostazione predefinita) può essere utilizzato in attacchi DDOS contro altri siti.  Notare che XMLRPC viene utilizzato per pingbacks, trackback, l’accesso remoto tramite dispositivi mobili e molte altre caratteristiche è molto probabile che sia abilitato. Ma può anche essere pesantemente abusato come quello che stiamo vedendo.

I fatti

E ‘successo tutto nei confronti di un sito WordPress popolare che era andato giù per molte ore a causa di un DDOS. Poiché l’attacco è aumentato in termini di dimensioni, il loro hoster l’ha spento, e poi hanno deciso di chiedere aiuto a un proxy di tipo Cloudflare.

Una volta che il DNS è stato ripristinato siamo stati in grado di vedere cosa stava succedendo, era un grande attacco flood basato su  HTTP (layer 7) , inviare ovvero centinaia di richieste al secondo al server. La richiesta sembrava questa:

 
74.86.132.186 - - [09/Mar/2014:11:05:27 -0400] "GET /?4137049=6431829 HTTP/1.0" 403 0 "-" "WordPress/3.8; http://www.mtbgearreview.com"
121.127.254.2 - - [09/Mar/2014:11:05:27 -0400] "GET /?4758117=5073922 HTTP/1.0" 403 0 "-" "WordPress/3.4.2; http://www.kschunvmo.com" 
217.160.253.21 - - [09/Mar/2014:11:05:27 -0400] "GET /?7190851=6824134 HTTP/1.0" 403 0 "-" "WordPress/3.8.1; http://www.intoxzone.fr" 
193.197.34.216 - - [09/Mar/2014:11:05:27 -0400] "GET /?3162504=9747583 HTTP/1.0" 403 0 "-" "WordPress/2.9.2; http://www.verwaltungmodern.de" 
..

Se notate, tutte le query avevano un valore casuale (come “? 4.137.049 = 643.182”), che aggirato la loro cache e forzare una pagina di ricarica completa ogni volta. Si stava uccidendo il loro server abbastanza rapidamente.

Ma la parte più interessante è che tutte le richieste provenivano da siti WordPress validi e legittimi. Sì, gli altri siti WordPress mandavano che le richieste casuali portando il sito down.

WordPress che ha XMLRPC abilitato = Very Large Botnet

Proprio nel corso di poche ore, oltre 162.000 diverse e legittime siti WordPress cercato di attaccare il suo sito.Avremmo probabilmente abbiamo rilevato molto di più siti, ma abbiamo deciso che avevamo visto abbastanza e bloccato le richieste al firewall di confine, soprattutto per evitare di riempire i registri con spazzatura.

Riuscite a vedere quanto potente può essere? Un attaccante può usare migliaia di siti WordPress popolari e puliti per svolgere il loro attacco DDOS, pur essendo nascosto nell’ombra, e che tutto accade con un semplice ping torna richiesta al file XML-RPC:

$ Curl-D - "www.anywordpresssite.com / xmlrpc.php"-d '<methodCall><methodName>pingback.ping</methodName><params><param><value><string>http://victim.com</string></value></param><param><value><string>www.anywordpresssite.com/postchosen</string></value></param></params></methodCall>'

Il tuo sito attaccando gli altri?

Potrebbe essere e non avete idea. Per verificare, guardare attraverso i registri di eventuali richieste POST al file XML-RPC, simile a quello qui sotto. Se vedi un pingback a un URL casuale, sai che il tuo sito è attuato in modo abusivo.

93.174.93.72 - [09/Mar/2014: 20:11:34 -0400] "POST / xmlrpc.php HTTP/1.0" 403 4034 "-" "-" "PostRequest: <xml version = \ x221.0 \ x22 encoding=\x22iso-8859-1\x22?>\x0A<methodCall>\x0A<methodName>pingback.ping</methodName>\x0A<params>\x0A  <param> \ x0A <valore> \ x0A <string> http://fastbet99.com/?1698491=8940641 </ string> \ x0A </ value> \ x0A </ param> \ x0A <param> \ x0A <valore > \ x0A <string> yoursite.com </ string> \ x0A </ value> \ x0A </ param> \ x0A </ params> \ x0A </ methodCall> \ x0A "
 
 94.102.63.238 - [09/Mar/2014: 23:21:01 -0400] "POST / xmlrpc.php HTTP/1.0" 403 4034 "-" "-" "PostRequest:   \ X0A   \ X0A   pingback.ping   \ X0A   \ X0A   \ X0A   \ X0A   http://www.guttercleanerlondon.co.uk/?7964015=3863899   \ X0A   \ X0A   \ X0A   \ X0A   \ X0A   yoursite.com   \ X0A   \ X0A   \ X0A   \ X0A   \ X0A "

Per interrompere il vostro sito WordPress da uso improprio, è necessario disattivare la funzionalità XML-RPC (pingback) sul tuo sito.

Un modo migliore per bloccarlo è quello di aggiungere al file functions.php del tema attuale, aggiungendo il seguente filtro:

add_filter( ‘xmlrpc_methods’, function( $methods ) {
unset( $methods[‘pingback.ping’] );
return $methods;
} );

Provatelo e fare la vostra parte per rendere Internet un luogo più sicuro per tutti.

WordPress a rischio : timthumb.php vulnerabile ad attacchi di tipo Remote File Include

TimThumb, l’utility di ridimensionamento delle immagini compresa in molti template della famosa piattaforma WordPress, sta dando problemi di sicurezza in quanto evidenzia vulnerabilità che eventuali cracker potrebbero sfruttare per attaccare siti e blog che utilizzano tale piattaforma.

Mark Maunder, amministratore delegato di Feedjit, ha scoperto il problema quando il suo blog ha cominciato a caricare contenuti pubblicitari che originariamente non erano stati da egli stesso inseriti. Proprio sul blog ha parlato dal problema, spiegando che è correlato alla libreria timthumb.php, utilizzata dal tema che egli ha acquistato per il suo spazio web. «Dal momento che sono appena stato attaccato attraverso essa, immagino sia giusto parlare della vulnerabilità al grande pubblico», ha scritto Maunder.

TimThumb.php, continua, è “intrinsecamente insicuro” perché scrive i file in una directory quando si carica l’immagine e la si ridimensiona. Tuttavia, questa directory è accessibile alle persone che visitano il sito, diventando quindi fonte di attacchi per i pirati informatici. Un utente malintenzionato può anche compromettere il sito agendo direttamente dalla directory, “riempendola” di file infetti.

Non solo (aggiungiamo noi), il problema infatti non si limita solo a caricare file infetti ma anche file php maliziosi come le famose phpshell,  e nel caso in cui non fosse stato fatto hardening a livello di configurazione PHP (separazione privilegi con su_php o php-fpm, o la disabilitazione di funzioni pericolose come l’allow_url_fopen,system,exec,ecc…) può compromettere seriamente la sicurezza dell’intero server Web oltre che del vhost specifico.

Il tipo di attacco è quello comunemente definito RFI (Remote File Inclusion), http://it.wikipedia.org/wiki/Remote_File_Inclusion

Maunder ha dunque spiegato che al momento conviene disabilitare TimThumb o, al limite, limitarne l’accesso.

Per quanto il discorso di Maunder possa essere corretto e sensato, esso tende a creare dei fraintendimenti ad utenti WordPress e webmaster non troppo esperti.

Va ricordato infatti che timthumb non è un plugin di WordPress ma bensì un file php “sfuso” inserito come parte funzionale di molti template WordPress (ma non solo wordpress).

Risulta dunque impossibile disabilitare questo plugin da pannello di controllo come si farebbe normalmente nell’attivazione e disattivazione di plugin wordpress e sopratutto non bisogna illudersi che basti aggiornare la versione di WordPress attuale all’ultima stabile per risolvere questo problema.

Bisogna (purtroppo) fare un’attività di ricerca manuale nelle cartelle del proprio template, individuare il file timthumb.php (se presente) e sostituirlo con la nuova versione che potete scaricare qui http://code.google.com/p/timthumb/
Uomo avvisato …