Il taccuino di Armando Leotta Rotating Header Image

vulnerabilità

Operation Global Blackout: Anonymous e l’annunciato DNS DDoS amplification attack

Il 31 marzo è vicino, decisamente prossimo.

Ma andiamo con ordine schematizzando e contestualizzando scenari di rischio, impatti e probabilità.

 

Minaccia

A febbraio di quest’anno il gruppo Anonymous ha diffuso la notizia della pianificazione di un attacco a tutti i root DNS server (13 in totale).

A tale attacco è stato dato il nome di Operation Global Blackout ed è stato fissato per il 31 marzo 2012.

 

Come funziona

Il DNS serve a tradurre i nomi delle risorse internet che si vuole raggiungere in indirizzi IP utili ai fini della raggiungibilità della risorsa stessa.

 Il sistema DNS ha una struttura gerarchica in cima alla quale risiedono i root server (target del supposto attacco) che contengono le informazioni di dove ritrovare i server responsabili per il successivo livello gerarchico (ad esempio, .com, .org, it, etc).

A loro volta, questi server ospitano le informazioni relative ai server dns responsabili per il successivo livello gerarchico (ad esempio google.com) e così via fino ad arrivare alla nome della risorsa richiesta (ad esempio www.google.com).

 L’attacco ipotizzato sfrutta una peculiarità del sistema descritto.

Al fine di raggiungere l’obiettivo di fermare globalmente la risoluzione dei nomi Anonymous punterebbe ad una saturazione delle risorse dei server oggetto dell’attacco tramite una generazione massiva ed amplificata di richieste di risoluzioni (DNS Amplification Attack).

Il tool (chiamato ramp) è da tempo disponibile in rete e consente un fattore di amplificazione fino a  73 (cioè quanto ricevuto dal sistema target è fino a 73 volte più grande della richiesta originaria). La differenza tra la quantità di dati generati meno la quantità necessaria a generarla è chiamata appunto amplificazione dell’attacco.

 

DNS amplification attack

Clicca per ingrandire

Ogni richiesta effettuata al DNS server (*) include un indirizzo sorgente al quale la risposta deve essere inviata.

Per questioni storiche e di performance tale richiesta avviene con protocollo connectionless (UDP) pertanto può essere soggetta a spoofing.

 

Infatti, il tool suggerito da Anonymous prevede l’alterazione dell’IP sorgente in modo da indurre il DNS server a restituire l’informazione richiesta non al vero destinatario (attaccante) ma ad altri (target dell’attacco).

Fattori critici in caso di attacco massivo:

1)       i dns server utilizzati per perpetrare l’attacco saranno via via saturati dalle connessioni entranti. Le performance di tali infrastrutture si degraderanno fino, potenzialmente, al collasso;

2)       Tali server consegneranno le risposte alle richieste ai root server congestionandoli;

3)       Il traffico dati attraverserà le dorsali IP e ciò causerà una saturazione delle risorse dei provider e degli upstream interessati fino al dominio target dell’attacco;

4)       Le performance dell’infrastruttura target dell’attacco subirà un forte degrado

 Se a questi fattori si aggiunge la possibilità che l’attacco possa essere sferrato utilizzando varie botnet lo scenario di rischio diventa decisamente più critico.

Potenziale impatto

Se l’attacco dovesse riuscire contro tutti i root server tutti i servizi basati su Internet avrebbero un fermo.

A meno di sistemi di cache, infatti, le richieste al root dns sarebbero talmente rallentate da andare in timeout a causa dell’attacco.

Nota: l’attacco dovrebbe avere caratteristiche di durata e portata tali da rendere inaccessibili tutti i root server per il tempo sufficiente ad invalidare le risoluzioni già presenti nei sistemi di cache DNS

 

Probabilità di successo

 A mio avviso, basse.

In molti si stanno chiedendo la reale probabilità di successo dell’attacco.

Anche tra gli addetti ai lavori le opinioni sono diverse.

Molti propendono per una mera azione intimidatoria e pubblicitaria da parte di Anonymous senza alcun tipo di velleità reale di creare disservizi.

In linea di massima, per svariati tecnicismi tra cui anche i vari sistemi di cache, il completo blackout è poco verosimile.

Quello che preoccupa gli esperti di sicurezza in caso di attacco massivo è rappresentato dall’imprevista mole di traffico “anomalo” (tra l’altro si tratta di una richiesta tramite un tool modificato ad hoc, non di richieste standard) che può saturare e collassare a macchia di leopardo le risorse a vario titolo coinvolte.

Questo scenario diventa critico se l’attaccante potrà disporre di botnet significative: in questo caso la probabilità di saturazione delle risorse sarà sensibilmente maggiore.

Contromisure

Nel lungo termine sicuramente adottare DNSSEC; nell’immediato verificare che il proprio DNS non sia un open resolver.

Per il resto, per gli addetti ai lavori, alzare il livello d’attenzione, di monitoraggio e di presidio: non è scolpito nella pietra che non possano “abbassare” il target e creare problemi alle tante appetibili infrastrutture ICT.

C’è parecchio hype sulla notizia e non è escluso che l’ottenuta co-partecipazione, volontaria o meno che sia, possa essere sfruttata per un target meno velleitario ma più alla portata.

 

 

________

(*) Sebbene tale attacco richieda la possibilità di poter disporre di un open resolver, di un dns server cioè in grado di accettare delle richieste ricorsive da parte di utenti non locali e che tale configurazione sia stata ampiamente criticata per motivi di sicurezza, ad oggi, non è affatto difficile trovare ed utilizzare un server in questa configurazione.

Vedi  http://www.us-cert.gov/reading_room/DNS-recursion033006.pdf
_____
Clusit

Joomla 1.5.20 vulnerabile ad attacchi XSS

Fino a qualche giorno fa era disponibile un video prof-of-concept ed un hotfix.

Adesso è disponibile l’aggiornamento ufficiale a Joomla 1.5.21.

Buon aggiornamento.

Youtube sotto attacco nel weekend: un XSS in cambio di un banner?

Un 4 luglio che non è passato inosservato.
Almeno in casa Google e, a quanto pare, anche a Cupertino.
Tra sabato e domenica Youtube ha subito un attacco che ha avuto come target i video del cantante pop Justin Bieber (e successivamente di Lady Gaga).
L’attacco dimostrativo, che sfrutta una vulnerabilità nel sistema di parsing dei commenti, mostrava un popup dove si leggeva la notizia della morte del cantante.

Youtube hacked (clicca per ingrandire)

4chan

rivendicazioni? (clicca per ingrandire)

Google, dopo un blocco cautelativo dei commenti, ha rilasciato una fix sui suoi sistemi che risolveva la vulnerabilità (XSS) sfruttata dagli hacker.

Post Google fix (clicca per ingrandire)

Sembra infatti che il parsing del contenuto dei commenti fosse effettuato in modo da gestire solo una prima occorrenza del tag script mentre, quanto in esso contenuto, era accettato senza alcun tipo di controllo ulteriore (sufficiente pertanto a consentire commenti con javascript al suo interno, ad esempio).
C’è chi ipotizza un gesto dimostrativo come reazione alla recente scelta di youtube di inserire pubblicità (Skippable ADS) nei filmati a partire da dicembre prossimo (fonte Baljeet Singh, YouTube Senior product manager in una conferenza stampa di giovedì scorso).
Coincidenza? Pretesto? Esibizionismo?
(screenshot via thenextweb)

_____
Clusit

Ricercatore di Google scopre nuova falla in windows XP e windows server 2003 (helpctr.exe) e Microsoft?

E’ stata scoperta una nuova falla sui sistemi operativi XP e windows server 2003. Il problema è legato a vulnerabilità a cross site script (XSS) nella gestione degli URI (Uniform Resource Identifier) hcp:// (Windows Help e Support Center cioè Guida in linea e supporto tecnico, helpctr.exe).

A scoprirla ed a comunicare a Microsoft la scoperta il 5 giugno è stato ancora Tavis Ormandy, Security Engineer presso Google. Se vi ricordate è lo stesso che lo scorso gennaio pubblico la full discloser circa la vulnerabilità di una funzione legacy per le routine a 16-bit che colpiva il kernel NT della microsoft dal 1993 in poi.

La stessa Microsoft, che ha confermato la ricezione del report di Ormandy lo stesso giorno dell’invio dello stesso, ha confermato (il 10 giugno) la presenza della falla nella Security Advisor 2219745 (che non cita la fonte della scoperta, ndr).

Lo stesso giorno, Ormandy pubblica il full discloser con un proof-of-concept, un exploit funzionante e dei workaround temporanei.

Microsoft si è premurata a pubblicare questo MSRC post e questo SRD post.

Anche Microsoft Italia, per voce del suo responsabile dei programmi di sicurezza e privacy Feliciano Intini, riporta la notizia che chiosa faziosamente in “Poi lascio a voi commentare come si possa giudicare l’operato di Google al riguardo…“.

Credo occorra contestualizzare lo scenario. In primo luogo, Google (probabilmente per implicita promozione dell’imminente uscita di Chrome OS) ha dichiarato di rimuovere windows dai propri computer per problemi di sicurezza. Secondariamente, credo che quattro giorni di tempo (sebbene stiamo parlando di Microsoft e non di Pizza & Fichi Inc.) possano essere risicati per produrre una hotfix pubblica.

Detto questo, sono convinto che se Ormandy non avesse pubblicato un exploit funzionante la sua segnalazione sarebbe finita archiviata. Inoltre, proprio Microsoft ci ha abituati a ben altri tempi:

“Per mantenere il supporto legacy per le applicazioni 16-bit, dal 1993 tutti i sistemi Microsoft si portano dietro questa vulnerabilità.

La cosa interessante è che la stessa Microsoft, a detta dello scopritore della vulnerabilità, fu informata il 12 giugno 2009 la quale confermò la ricezione 10 giorni dopo.

Nessuna patch o workaround ufficiale. Un silenzio che ha portato l’autore alla pubblicazione della vulnerabilità.”

(estratto da Microsoft e sicurezza: ossimoro? su Il Taccuino e sul blog del Clusit).

Il clima tra i giganti non sembra essere dei migliori e forse 4 giorni sono pochi ma mesi se non anni di silenzio a cui ci hanno abituato sono troppi, secondo i miei parametri.

E’ importante sottolineare che il problema è di chi immette le falle, non di chi le segnala e le ha sempre segnalate responsabilmente al fine di raggiungere prima possibile ad una risoluzione.

Detto questo, forse, invece di soddisfatti ed improbabili proclami di parte, occorrerebbe una sana autocritica e prendere atto che servono prodotti con meno bug e rapidamente sanati.

Puntare il dito contro chi identifica i propri errori non sempre è costruttivo.

Java Deployment Toolkit Injection Vulnerability

Secunia segnala una vulnerabilità particolarmente critica che permette il passaggio arbitrario di parametri a javaw.exe e la successiva esecuzione di codice arbitrario tramite il caricamento di opportune pagine web.

Firefox avvisa così (se ne parlava qui):

java deployment toolkit

java deployment toolkit (avviso di sicurezza di firefox)

Alcuni link utili:

  1. Note sull’aggiornamento (sun.com)
  2. Oracle.com security alerts (oracle.com)
  3. Download JRE / JDK com (JRE o JDK da sun.com)
  4. US CERT (Vulnerability note di US CERT)             

Quest’ultimo, in particolare, evidenzia che in alcuni casi l’aggiornamento alla Java JRE 6 Update 20 non risolve completamente ed occorre rimuovere/rinominare il file npdeploytk.dll

Nota: l’aggiornamento automatico a me non funziona e ho dovuto reinstallare l’intero pacchetto (3).

_____
Clusit