Insisto ancora riguardo alla storiella raccontata da Facebook perche’ vedo che nessuno vuole…

Insisto ancora riguardo alla storiella raccontata da Facebook perche’ vedo che nessuno vuole occuparsi di un problema serio, ovvero della mancanza di standard nella rivelazione al pubblico di (avvenuti) problemi di sicurezza. Non importa che la cosa riguardi Facebook o la panzana secondo la quale PGP sarebbe stata vulnerabile ad un attacco che in realta’ riguardava il client di posta elettronica.

Il problema e’ che in assenza di uno standard chiaro su come dare la notizia di un problema di sicurezza, ci sono due grosse spinte a dis-informare la popolazione.

– Vanity Announce: il ricercatore alla ricerca di fama denuncia una “falla” nella maniera piu’ catastrofica possibile, nella maniera piu’ impressionante possibile , quando si tratta di un problema che NON riguarda il programma che aveva la falla, ma di una cattiva pratica implementata dagli utilizzatori.
– Reputation Management: tutta una serie di strategie messe in atto dalle aziende impattate da una falla, allo scopo di lasciarla sottostimare, sottovalutare, salvando la reputazione dell’azienda stessa.

Sulla prima, l’esempio di PGP e’ piu’ che sufficiente. Un dottorando tedesco decide di diventare famoso rivelando alle masse che “pgp e’ insicuro”. Non rispetta ne’ i tempi ne’ le modalita’ di annuncio che normalmente consentono a chi fissa il baco di essere in vantaggio nei confronti di chi lo sfrutta, lasciando diverse settimane agli esperti di phishing per sfruttare la falla.

Dopo qualche ora dall’annuncio si scopre chiaramente che PGP non ha alcun problema, e semmai tutto dipende da una serie di cattivissime pratiche implementate nei client di posta elettronica che usano PGP. In compenso il ricercatore ha avuto i suoi 15 minuti di fama.

Le pratiche di Reputation Management invece sono molto piu’ insidiose. Questi esperti intervengono quando l’azienda ha un problema conclamato di qualita’ del prodotto nei confronti dell’utente finale, e trovano a salvare la faccia del cliente. Si basano sulla costruzione di uno storytelling che mira a:

– Ridurre la percezione del danno, eventualmente impedendo che tale danno sia associato ad altri eventi. (per esempio, poche ore prima dell’annuncio c’era stato un facebookdown piuttosto sentito) Se anche questi outage sono ammessi, non vengono associati all’attacco ma ai provvedimenti presi per contrastarlo. Insomma, tutto quel fumo e’ dovuto al fuoco che abbiamo appiccato per spegnere l’incendio.

– Attribuire il danno ad un baco noto, meglio se appena risolto, anziche’ attribuirlo a qualcosa da analizzare, di difficile soluzione, e specialmente non ancora completamente fissato. Allora si prende un baco vecchio, che era gia’ in via di risoluzione nel processo di devops, e gli si attribuisce la colpa, proprio mentre si sta deployando la patch. E via: il problema c’era, ma e’ gia’ stato risolto.

– Circoscrivere la portata del problema: si dice che la tale credenziale e’ stata rubata, ma non si spiegano tutti gli usi possibili. Se la tale credenziale di facebook sia usata anche da applicazioni di terze parti, per esempio, non e’ mai stato spiegato. Se gli account violati fossero protetti o meno, e quindi si tratti di una violazione di contenuti gia’ pubblici o di contenuti che gli autori non volevano mostrare.

Questo e’ quello che ho visto da Facebook nella scorsa vicenda dell’hack. Come ci si accorge di avere di fronte uno storytelling?

– Il criminale stupidino. Quando ci si accorge che si, il genio del crimine e’ entrato nel caveau, ha evitato 345 allarmi, ha addormentato il ghepardo di guardia, ma poi mentre rubava i diamanti gli e’ venuta fame e ha riempito di merendine la borsa , lasciando il 90% dei diamanti sul posto.

Questa e’ la teoria di chi dice di aver notato un “picco di traffico su alcuni servers”, picco che sarebbe stato dovuto al fatto che leggendo “la pagina come altro utente” , si causava molto traffico. Il criminale stupidino, insomma, non e’ capace di scaricare le credenziali evidanto di scaricare tutto il contenuto. Il criminale stupidino, se anche ha bisogno di scaricare la pagina per non creare degli outliers sospetti non sembra capace di fare tarpitting del suo stesso programma ,e dopo aver ottenuto le credenziali scaricare lentamente le pagine (che non gli servono)

– L’allarme improbabile. Facebook attribuisce ad un allarme di anomaly detection la sua capacita’ di rilevare l’attacco. A quanto pare, siccome usavano la funzione “vedi come altro utente”, allora hanno consumato piu’ banda del previsto.

Certo. In pratica, scaricando 90 milioni di utenti in 8 giorni, hanno scaricato 10 milioni di pagine in preview al giorno. Stiamo parlando di un social network che ha due miliardi di utenti . E questi 10 milioni di pagine in preview, come se non bastasse, in termini di contenuti vengono scaricate principalmente da CDN. Questo allarme improbabile avrebbe notato un aumento tremendo di traffico legato ai contenuti non CDN di ~10 milioni di utenti al giorno, pari alla bellezza di ~115 profili al secondo. …..sseriously?

– Le coincidenze inspiegabili. Mentre il ladro geniale entrava nel caveau, si sono udite delle esplosioni negli edifici circostanti e il centralino della polizia e’ andato afuoco.Ma nessuno si chiede se le cose siano in relazione.

Proprio nell’intervallo di tempo in cui c’e’ stato l’attacco, facebook ha sofferto un facebook down di diverse ore.

In che modo 115 profili in previev al secondo possano impensierire facebook al punto da causarne il down , e’ poco chiaro. In che modo questi due eventi siano collegati nemmeno. Perche’ mai il cambio di credenziali (che Facebook dice di avere fatto) debba causare un down, nemmeno.

Le due cose sono successe, ma nessuno si azzarda a chiedersi se ci siano state delle relazioni.

– Il bersaglio astratto. Quando non si capisce bene che diavolo volesse l’attaccante. Il superladro penetra nel caveau, ma non si capisce se miri ai diamanti o al distributore di merendine del personale.

Perche’ sono stati interessati 90 milioni di account su 2 miliardi. Sono stati scelti a casaccio? E anche ammesso che (come sembra dire Facebook) lo scopo di questo attacco fossero i profili, QUALI profili? Stiamo parlando di profili che sono gia’ pubblici? In quel caso basta un crawler. Stiamo parlando di profili che avevano scelto di NON essere visibili e sono stati aperti? Ok.

Allora sono stati scelti accuratamente. Su quali criteri? Erano oppositori politici di Putin? Erano cinesi? Italiani? tedeschi? Gay? Attivisti? Chi erano? Boh. Nessuna analisi delle vittime e’ stata fatta.

– Il rimedio improbabile. Il delinquente e’ entranto nel caveau usando una debolezza che , guardacaso, conoscevamo e avremmo fissato domani.

Interessante. Quindi quel baco era noto da anni, e nessuno prima lo aveva sfruttato. Guardacaso, lo hanno fatto proprio quando la soluzione era stata scritta, la patch aveva terminato il suo processo di devops e l’abbiamo messa giu’, guarda caso, immediatamente. Ovviamente, in pochi secondi abbiamo anche fatto l’analisi degli impatti di tale patch, e abbiamo anche fatto tutti i test di non regression rispetto a precedenti bachi esistenti.

Aha. Ci credo. Davvero.

– La mancata crisi degli impatti su terze parti. Il nostro ladro geniale ha rubato tutti i diamanti della collezione, ma nessuno si azzarda a dire che le assicurazioni e il capo della polizia siano in una situazione difficile.

Allora questi hanno scaricato credenziali, ma nessuno sta analizzando quali e quanti servizi di terze parti ne facessero uso. A prescindere dal fatto che facebook possa offrire diversi sistemi di autenticazione, quanti sistemi di terze parti usavano l’autenticazione di facebook, e quelle credenziali rubate?

Nessuna analisi di questo tipo sta venendo proposta. E questo e’ grave, per un’altra ragione:

– L’azione di fix affidata agli utenti. Il ladro penetra nel caveau e ruba tutte le carte di credito. Ai possessori di conto corrente viene affidato il compito di controllare se la loro carta di credito e’ tra quelle rubate.Se qualcuno non legge i giornali, ci spiace tanto per il suo conto in banca.

Ok, ok. Facebook ha invalidato le credenziali di questi utenti.Ma qual’era la durata delle credenziali presso i servizi di terze parti? Per quanto tempo i fornitori di API basasi sulle credenziali di altri OTT tengono le credenziali in cache? Ignoto. In pratica, si spera che tutti gli utenti ricordino di aver usato un token di facebook, di aver avuto un account su facebook, che vadano a controllare, e che ricordino tutti i siti di erze parti ove hanno usato tale token, e si spera che tale token non sia in cache. Nel qual caso, le credenziali rubate funzionano ancora.

Quando compaiono questi sintomi, in genere avete a che fare con una caterva di panzane raccontate dagli esperti di Reputation Management.

In definitiva, cioe’, il messaggio e’ semplice: non fidatevi di Facebook, e non usate il vostro account di facebook per registrarvi su servizi di terze parti.
Questa vicenda mostra, qualora ce ne fosse bisogno, che le questioni di sicurezza NON vengono affrontate per proteggere VOI; ma per proteggere gli azionisti.

(RSS generated with FetchRss)

(Fonte: post sulla pagina Facebook Sostenitori di Kein Pfusch / Uriel Fanelli)

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *