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.

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:

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

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)

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?

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.

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.

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.

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:

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.