Il taccuino di Armando Leotta Rotating Header Image

hacking

Log e dintorni: 138 pagine di attacchi al daemon FTP

Un NAS casalingo, poco tempo e tanti interessi.

Questo è lo scenario di riferimento.

Questa volta spulciando i file di log ho isolato i soliti tentativi spot e improbabili del lamer di turno e quanto è rimasto ha catturato la mia attenzione : 138 pagine di tentativi di login falliti al daemon FTP.

Tutti il 30.03.14, tutti dallo stesso indirizzo IP.

FTP attack

FTP Attack (clicca per ingrandire)

Raccolgo info sull’IP. Di tutto, di più e per non farsi mancare nulla, botnet piuttosto attiva.

Mi vengono in mente le tecniche di fuzzing e le grammatiche sviluppabili su vari framework sia per scovare il buffer overflow che per sferrare l’attacco brute force o dictionary che sia.

Adesso, ringrazio della cortese attenzione ma il $token su cui ciclare è la $password, non lo $username (clicca sullo screenshot per ingrandire)

Detto questo, vedo di trovare il tempo di abilitare un ban dinamico a tempo.

 

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

[WARNING] Gawker Media hacked. In altre parole account compromessi su Lifehacker, Gizmodo, Gawker, Jezebel, io9, Jalopnik, Kotaku, Deadspin e Fleshbot

Ieri mi ero allarmato per un accesso anomalo al mio profilo facebook.

(via lifehacker)

Stanotte ho letto che GaWKER MEDIA ha comunicato di essere stata vittima di un attacco.

Il risultato è la compromissione degli account *registrati* usati per commentare sulle loro piattaforme Lifehacker, Gizmodo, Gawker, Jezebel, io9, Jalopnik, Kotaku, Deadspin e Fleshbot.

Due modi per avere la conferma di essere vittime involontarie di questo attacco: usare un widget oppure controllare se il proprio indirizzo di mail è nell’elenco ormai pubblico e pubblicamente disponibile (un torrent da 500 MB) dopo la rivendicazione dell’attacco da parte di un gruppo chiamato Gnosis.

Se volete effettuare manualmente il controllo calcolate lo sha-256 (no salt) del vostro indirizzo di mail usato per registrarvi a gawker (non è salvato in chiaro) e controllate qui in base ai primi caratteri del risultato della funzione hash.

Non ricordavo nemmeno di essere registrato ma ovviamente la mia mail è presente nella lista pubblica e non mi resta che pensare che la password era la stessa usata anche per facebook: ecco probabilmente spiegato il login dal New Jersey di ieri.

Lessons learned? Tenere sempre traccia degli account che si registrano (e che non si usano  abitualmente, ndr) e della mail che si usa per la registrazione. L’ideale sarebbe usare password diverse per servizi diversi ma mi rendo conto della difficoltà oggettiva e della controtendenza dei servizi in the cloud.

In ogni caso, controllate e cambiate immediatamente la password e/o le password ai servizi che utilizzate con le medesime credenziali.

_____
Clusit

Il furto d’identità digitale: Byoblu e Google – un caso reale –

Gli addetti ai lavori non perdono occasione per sensibilizzare gli utenti sui rischi del furto d’identità in rete.

L’indiscutibile vantaggio di avere un solo account per governare n servizi ha chiaramente il lato negativo di esporre *tutti* i servizi nel caso di violazione dell’account.

Un esempio per tutti: i servizi Google. Dopo varie ondate di violazioni proveniente apparentemente dalla Cina, a denunciare un furto d’identità è Byoblu di Claudio Messora.

Come potete leggere qui, da ieri non è più in possesso del suo account gmail con il quale, di fatto, governava TUTTI i servizi del gigante di Montain View.

Danno su danno visto che, dalle prime verifiche, sembra che abbiano rimosso l’account (con tutto ciò che questo comporta: contatti, mail, preferenze, youtube…).

Un grande in bocca al lupo a Claudio per la brutta situazione da recuperare: confido (o meglio, spero) in un supporto fattivo e collaborativo di Google stesso.

Lesson learned

I servizi cloud sono una realtà comoda ed economica ma dobbiamo imparare a non fidarci del tutto ed a valutare soluzioni di backup on the cloud direttamente proporzionale alla delicatezza dei dati che esponiamo.