Archivi tag: attacchi

Altri esempi di social risk

Di cosa sia il social risk avevo già parlato, ma recentemente sono emersi due eventi che hanno evidenziato sia l’attualità della questione sia soprattutto i rischi reali che si corrono sottovalutando l’uso di questi strumenti.

Caso vuole che siano coinvolte le due principali aziende di fast food del mondo.

Il primo è senza dubbio quello successo a Burger King.

L’account twitter della società è stato violato ed è stato modificato per somigliare a McDonald’s, aggiungendo ovviamente un bel po’ di tweet offensivi…

Fonte abc News

Fonte abc News

Non si hanno i dettagli dell’attacco, ma sicuramente è dovuto ad una scarsa sicurezza. Di Twitter in primis (e ne ho già parlato proprio qualche giorno fa), che non dispone di una autenticazione a due fattori, ma soprattutto di chi gestisce il profilo, che ha impostato una password troppo semplice, e soprattutto non ha monitorato quello che stava succedendo.

Sicuramente non è stato un momento piacevole per la struttura di PR dell’azienda, ma la cosa grave è che l’incidente è nato da una palese sottovalutazione della sicurezza di certi strumenti.

L’altro caso lo riferisce Sophos, e riguarda (casualità) il concorrente: McDonald’s.
Quello che è successo stavolta è che è girato su Facebook una foto fake in cui un non meglio identificato ristorante McD esponeva un cartello molto razzista:

Fonte Sophos Naked Security

Fonte Sophos Naked Security

L’immagine ha avuto quarantamila condivisioni. Era fake perché il numero verde riportato sotto non era di McDonald’s ma addirittura dell’altro concorrente KFC.

Questo sicuramente mostra come su Facebook sia facile far girare delle bufale, ma soprattutto indica come sia necessario monitorare la presenza sui social newtork (tramite sentiment analysis), al fine di prevenire questo genere di eventi, e rispondere prontamente.

In questo caso McDonald’s non aveva ovviamente colpe, non essendo stata attaccata direttamente.
Ma senza un’accurato monitoraggio potrebbe subire un incidente ancora più grave, ad esempio perché la foto falsa potrebbe provocare un attacco pesante da parte di gruppi di hacktivist.

Bye!

Qualche nota sull’attacco a Twitter

Febbraio si è aperto con una gran brutta storia.

Ben riassunta da Paolo Passeri sul suo Hackmageddon con il titolo di The Party Is Not Over! 250,000 Twitter accounts compromised! che riprende il post del blog ufficiale di Twitter dal titolo Keeping our users secure.

Twitter Keeping our users secure

Il succo della vicenda è quello che racconta Twitter stesso: hanno riscontrato tentativi di accesso non autorizzato a circa 250mila utenze.

L’attacco, o per lo meno uno dei tentativi di attacco, è stato bloccato. In via precauzionale Twitter ha resettato tutte le password degli account oggetto dell’attacco, informando gli utenti dell’operazione.

Non è la prima volta che parlo di Twitter in questo blog, lo avevo fatto perché qualche tempo fa pubblicarono un post interessante su come gestire la sicurezza delle proprie password.

La cosa spiacevole, e che purtroppo Twitter non è andata molto oltre la gestione delle password.

Sì perché mentre il contenuto del post, comprensibilmente molto vago, è comunque una prima descrizione di qualcosa che non conoscono bene, il titolo per me è pessimo.

Perché dico questo? Perché l’attacco, che può naturalmente accadere a chiunque, ha svelato in realtà come Twitter non faccia in realtà granché per far stare sicuri i suoi utenti. Sopratutto non lo fa rispetto agli altri social network.

Andiamo con ordine. Essendo utente di Twitter da più di sei anni, e avendo l’attacco colpito i primi utenti del servizio, anche al mio @glamis è arrivato il reset della password.

Della password sì, ma delle sessioni aperte no. E questo è il primo punto.

Ed è importante perché pare che Twitter abbia resettato tutte le password “sospette”, ma solo le sessioni di chi riteneva più a rischio. Questo perché pare che siano state sottratte oltre alle password (cifrate, quindi poco utili), anche i token di sessione di alcuni utenti. Da qui la necessità di resettare tutto il resettabile.

Perfettamente comprensibile.

Ora io ho ovviamente cambiato la mia password, e qui ho scoperto un altro problema delle procedure di Twitter: cambiando la password le sessioni (e i token) attivi non scadono.

Mi aspettavo infatti di rimettere la password su tutti i vari iCosi che ho in giro, ma così non è stato. Tutto ha continuato a funzionare correttamente. Molto molto male. Requisito fondamentale affinché abbia realmente valore un cambio password è proprio la decadenza di tutte le sessioni attive.

Anche perché che altro modo ho io per buttare fuori uno che, ad esempio, mi ha rubato l’iPhone? Nessuno, perché Twitter non ha una funzione di reset delle sessioni.

E non parlo di cose fuori dal mondo, parlo di funzioni di sicurezza basilari che Google e Facebook hanno attivato già da molto tempo. E sono molto utili, per garantire la sicurezza ai propri utenti.

E vi prego non venitemi a dire, come dice il Guardian, che non lo fanno perché

The reason why third-party clients will still let you tweet is that Twitter doesn’t let them use your password. Instead, it uses “tokens” which are issued to the third-party programs, and authorise them to send tweets to Twitter’s database for redistribution to followers. The tokens weren’t revoked as part of the password reset; doing that would have meant that you’d have had to re-authorise all your apps, and for some apps Twitter has only made a limited number of tokens available. So that would have hurt both users and app developers.

Ma non è tutto. Certamente era una cosa nota già da prima, ma con questo attacco è tornato ancora più evidente il fatto che Twitter non consenta un’autenticazione a due fattori. Cosa che, non mi stupisce, Google e Facebook fanno da tempo (e che voi usate, vero….?)

Su questo ultimo punto si “combatteva” già da un po’, ma la cosa ha preso come dicevo ancora più forza e si è diffuso subito l’hashtag #iwantmy2fa

Speriamo che qualcuno ascolti, anche perché, come ricorda sempre Paolo, Twitter non è un caso isolato.

Prima di lui fu attaccato LinkedIn che, coincidenze, non ha né un’autenticazione a due fattori, né un controllo ed eventuale reset delle sessioni attive.

Dagli errori si deve sempre imparare, stavolta è proprio il caso di farlo.

Bye!

Giocare sporco: anatomia di un attacco DDoS tramite game server

Trovate qui la traduzione italiana del mio articolo pubblicato sul numero 29 di ClubHACK Magazine.

Gli attacchi di tipo Distributed Denial of Service (DDoS) sono l’arma più comune e facile da utilizzare per creare grossi problemi e danni molto visibili ad un determinato bersaglio, e con uno sforzo molto limitato.

Questo attacco è senza dubbio quello più utilizzato dai gruppi di hacktivist, poiché necessita di un tool molto comune (come LOIC), e si basa sulla rabbia di centinaia, se non migliaia, di persone disposte a fare qualcosa di semplice. La sua efficacia deriva anche dal fatto che è un attacco molto complesso da evitare, questo perché gli attaccanti dispongono di una banda di rete enorme, e c’è poco altro da fare se non chiudere i firewall per evitare danni peggiori ai server interni. In ogni caso l’attaccante vince, e i servizi sono giù per un po’ di tempo.

Questo è l’unico lato positivo della storia, l’attacco non può durare a lungo e il “Tango Down“, se correttamente individuato e mitigato con una chiusura completa, durerà pochi minuti, lasciando il tempo a chi l’ha sferrato di bullarsi con il resto del mondo via Twitter.

Devo ammettere che spesso si assiste a società in grado di farsi un attacco DDoS da sole,  pubblicando servizi su server mediocri e con un’architettura di rete ridicola. Così non appena il sito va online tutto viene giù alla prima milionata di richieste della homepage. E questo causa molti più problemi che non un gruppo di hacktivist, non credete? 🙂

Tornando all’argomento dell’articolo, questo è il modo classico di eseguire un attacco DDoS, ci sono però altri metodi, più interessanti da analizzare e più raffinati, per creare questo tipo di disservizi.

Lavorando sul campo svolgo spesso analisi post-mortem su attacchi di vario tipo, e recentemente ho analizzato questa modalità di eseguire un DDoS tramite server di gioco online. Vediamo insieme come.

Partiamo dal dire che l’attacco non è eseguito direttamente dall’attaccante, ma usando, come fossero una botnet, un numero elevato di game server custom (cioè gestiti non dalla casa produttrice del gioco, ma da gruppi di fan, spesso illegalmente), sparsi per il globo. Sono loro che attaccheranno il bersaglio.

La Figura 1 mostra come l’attacco è eseguito:

Game server DDoS Attack Flood Scheme

Schema del flood DDoS tramite game server

La prima cosa che colpisce è che, tenendo presente che i game server custom possono essere dislocati ovunque nel mondo e che nascono e muoiono in continuazione, è praticamente impossibile identificare il reale attaccante.

Questo tipo di attacchi non è molto conosciuto, né molto eseguito, ma è stato individuato e descritto per la prima volta lo scorso anno.

Ma perché succede una cosa simile?
Succede perché questi server di gioco sono vulnerabili ad un attacco specifico. L’attacco viene eseguito chiedendo, con un pacchetto fatto ad hoc, lo status di gioco del server. Questa è una richiesta UDP molto piccola, ma se fatta spoofando l’IP sorgente del richiedente, il server risponde a quell’IP con un’enorme quantità di informazioni.

Sempre lo scorso anno uno degli sviluppatori di questi server custom ha pubblicato questa vulnerabilità, e contestualmente rilasciato una patch per risolvere il problema. Naturalmente in molti casi questi server sono del tutto illegali, il software è scaricato chissà da dove, e sono attivi in molte nazioni, comprese Russia e Cina. Non ci si può quindi aspettare che gli amministratori siano molto attenti ad applicare le ultime patch, o che rispondano a qualunque tipo di richiesta. Molto probabilmente chiuderanno bottega e ne attiveranno uno nuovo da un’altra parte.

Avendo modo di lavorare direttamente al caso, posso pubblicare i dettagli dell’attacco, analizzando il traffico reale. Come potete facilmente immaginare, non pubblicherò il bersaglio dell’attacco, né i nomi o gli IP dei game server coinvolti. Questo è solo un case study per capire come funziona questo tipo di performance.

La prima cosa da notare è la tipologia dei pacchetti. Come detto è tutto traffico UDP, di dimensione variabile, inviati alla porta 21 del server oggetto dell’attacco.

Fusso UDP di risposta

Fusso UDP di risposta

Guardando il dettaglio di un paio di flussi, possiamo vedere che il pacchetto è uno statusResponse da un server custom di Call of Duty.

CoD statusResponse

CoD statusResponse 2

Potrei continuare a mettere screenshot per giorni, i server coinvolti nell’attacco erano centinaia, e ognuno aveva inviato un’enorme quantità di risposte. Immagino che i giocatori non fossero molto contenti dei lag nel gioco durante l’attacco!

Call of Duty non è stato l’unico gioco utilizzato, ma erano coinvolti anche dei server Quake 3.

Quake3 game server resposne

E anche in questo caso abbiamo un pacchetto statusResponse.

Quake 3 response

Penso che sarete d’accordo con me nel ritenere questo attacco molto più raffinato e ordinato, rispetto ad un classico DDoS eseguito con LOIC.

Vi domanderete ora come fare ad evitare questo tipo di attacchi.
C’è poco da fare purtroppo.

Mettere in blacklist i game server è una tattica poco efficace, loro e i loro IP vanno e vengono ogni giorno, quindi non servirebbe a molto. Proseguendo con il patching questo tipo di vulnerabilità potrebbe andare a morire, ma ci saranno sempre server vulnerabili in giro, spesso da certe nazioni, pronti ad essere usati per sferrare questi attacchi.

Come al solito la migliore difesa monitorare costantemente cosa accade sulla vostra rete. Solo in questo caso è possibile rispondere rapidamente e provare a mitigare l’attacco, sia tramite blacklist temporanee, sia tramite chiusure dei firewall.

Ma, come al solito, se non vedete nulla non saprete mai cosa sta succedendo.

Federico Filacchione
pubblicato originariamente come “Playing Bad Games: Anatomy of a Game-Server DDoS Attack” su ClubHACK Magazine numero 29.

Quando l’intelligence si rivolta contro

Ovvero: bisogna sempre stare attenti a fidarsi degli altri.

Piccolo antefatto: a Natale del 2011 viene bucato, dal gruppo Anonymous, il sito della nota agenzia di cyber-intelligence STRATFOR.

Vengono sottratti numerosi dati. Prima di tutto il dump delle email degli analisti, poi la lista degli utenti, gli account, le password e in numerosi casi le carte di credito dei sottoscrittori ai servizi dell’agenzia. Ma non voglio parlare di questo, in giro trovate tantissime analisi di quanto è successo, inclusa una eccellente timeline (seppure con molti link ormai rimossi).

Analizzando il database che trovate su Dazzlepod, ho notato che ci sono (oltre ad una vagonata di altra roba) degli account gov.it interessanti:

Non avendo mai sentito il dominio alfa.gov.it, sono andato a fare una ricerca, ma non espone un servizio web accessibile direttamente. Qualche parolina nelle email però inizia a far riflettere…

Cercando su Google emerge però un ulteriore sottodominio webq.alfa.gov.it, che presenta una form di login, presumibilmente ad un’interfaccia di web mail.
Fare un whois ai siti governativi italiani è abbastanza complesso (come registrarli del resto, ma si tratta appunto di roba governativa e italiana, quindi c’è poco da meravigliarsi 🙂 ) anche se un servizio esiste, vedi l’aggiornamento più sotto.

Questo sito è ospitato dall’IP 151.13.11.186, di Infostrada.
Non è possibile capire di più, ma è possibile utilizzare un fantastico strumento come Robtex, per capire cos’altro c’è su quella classe di indirizzi, visto che verosimilmente saranno stati assegnati tutti insieme. E infatti facendo una ricerca esce fuori…

Ecco rivelato chi c’è dietro alfa.gov.it, e perché era interessato all’intelligence.

Chiariamo subito una cosa, non si trattava e non si tratta di risorse segrete.
Si tratta di asset più o meno volutamente nascosti. Per lo meno non esposti direttamente a chi non si cura di cercare le cose per bene.

Questa storia è un bel case study per spiegare due cose molto importanti nella sicurezza informatica.

La prima è senza dubbio che non bisogna fidarsi di nessuno.
Per quanto sia importante il fornitore del servizio, per quanto si paghi o si pensi di stare al sicuro, non bisogna mai esporsi troppo direttamente. Sarebbe bastato usare un indirizzo gmail registrato al volo e sarebbe scomparso nelle centinaia di miglaia di utenze dumpate.

Il secondo è che le fonti OSINT– Open Source Intenlligence sono potentissime.
È necessario realmente fare due/tre ricerche e la mole di informazioni che viene resa disponile è enorme. Quindi se pensate di poter nascondere qualche cosetta tra le pieghe dei vostri servizi internet, se pensate che in fondo che male c’è ad usare l’email aziendale… ripensateci. Non stiamo parlando di tecniche avanzate di Google hacking, basta una semplicissima ricerca.

Ironia della sorte, i colpiti da questa vicenda sono proprio coloro che stavano cercando, e chissà perché con tanti indirizzi diversi, proprio informazioni da fonti OSINT…

Bye!

Aggiornamento: cercando meglio, una specie di whois dei domini .gov.it è disponibile qui, dove il dominio alfa.gov.it risulta attivo e registrato a “Presidenza del Consiglio dei Ministri CESIS“. Il che rende ancora più semplice l’OSINT e ancora più emblematico il problema derivante dall’uso di quelle email.