Ma ripercorriamo un po’ gli eventi.

Beentouch mi querela tramite Danilo Mirabile

Giorno 30 Marzo 2017, l’uomo dai mille Job Title, Danilo Mirabile, mi querela. A suo modo di vedere avrei effettuato un accesso abusivo verso Beentouch. Tutto questo perché avrei inviato una segnalazione di sicurezza, e dopo che non hanno riconosciuto la vulnerabilità,  il disclosure della stessa.

Il problema qual è, il Mirabile non ha portato nessuno straccio di prova e la linea della querela è stata tutta fatta da supposizioni. Siccome mi ha segnalato una vulnerabilità, probabilmente ha effettuato un accesso abusivo. Ora, non mi aspetto che chi fonda un’azienda esclusivamente sullo storytelling sia così sveglio da capire che chi fa analisi non necessariamente deve effettuare una intrusione per capire che c’è un problema. Avesse però messo le stesse energie che ha messo nella formulazione dei job title per cercare di capire la segnalazione, probabilmente non avrebbe fatto questa enorme figura di bip.

Quando amici e conoscenti mi hanno chiesto di spiegare la vicenda in maniera semplice, ho provato a raccontarla così.

Supponi che un dottore guarda un passante, lo ferma, e gli rivela che ha un problema di salute e che deve farsi curare immediatamente perché pericoloso per gli altri. Gli dà 60 giorni di tempo per rimediare, altrimenti sarà costretto ad avvisare l’ASP. Ora è come se il passante non capisca che il dottore data l’esperienza ha capito il problema senza nemmeno visitarlo, e lo denuncia perché ha effettuati un intervento “abusivo”.

La richiesta di archiviazione del P.M.

Ma torniamo alla querela, il P.M. capisce che non sta in piedi nulla, e propone l’archiviazione. Mirabile non ci sta e depone un atto di opposizione alla richiesta di archiviazione . Meravigliosa. Inizia a parlare di API Rest , HTTPS, come uno studentello al primo anno che con tanta confusione in testa che tenta di ripetere la lezioncina che ha imparato. Inizia a scrivere pure di  Eavesdropping!  Continua a sostenere che  ho effettuato un accesso abusivo, ma anche qui mai una prova, tutte supposizioni.

La fine è meravigliosa, cito:

“Le continue email ricevute da Iuculano (con minacce di pubblicazione delle falle di sicurezza) hanno alterato lo stile di vita del gruppo, il quale, a causa delle pressanti sollecitazioni di Iuculano (a qualunque ora del giorno e della notte, ed anche in giorni festivi, evidentemente in contrapposizione a quelle regole etiche poc’anzi richiamate) ha vissuto un forte periodo di stress.”

Eh sì, li ho sollecitati troppo, sono tutti stressati, come faranno adesso a raccontare in giro che stanno cambiando il mondo? Come farà l’uomo dai mille Job Title ad andare ancora in giro a raccontare come si fa startup, o “introdurre con semplicità e passione nel mondo del lavoro e dell’imprenditorialità”. Ah, dimenticavo. Il contorno di tutto questo è che Beentouch non se la fila più nessuno.

L’archiviazione del GIP

E cosa avrà detto il giudice dopo questo trattato del nulla? Torniamo un attimo seri perché il giudice ha archiviato  con una sentenza che qualche testata ha definito come “sentenza storica in Italia” (Ne ha parlato anche repubblica).

che nel caso de quo l’indagato ha inviato una serie di missive allo staff della “Beentouch” e solo a seguito dell’inerzia della medesima di voler correggere la vulnerabilità del sistema, si  è deciso a render noto, a tutela dei consumatori, Ia presenza di un simile errore a distanza di un mese dalla sua segnalazione;

che la condotta dello luculano non integra pertanto, sulla scorta di quanto chiarito, il delitto di cui all’art, 615ter c.p, inquadrandosi la stessa nella metodologia comune della “divulgazione responsabile“, avendo peraltro l’indagato medesimo contattato prima l’azienda coinvolta proprio per consentirle di emendare l’errore entro un lasso di tempo, che può variare da trenta giorni a un anno, a seconda della gravità e della complessità della vulnerabilità;

Sono rimasto piacevolmente colpito dalla competenza e preparazione del giudice, in poche righe ha perfettamente descritto la vicenda e ha chiarito che si tratta di “Divulgazione Responsabile”.

L'articolo Beentouch mi denuncia e perde con una sentenza storica sembra essere il primo su Giuseppe.

Dopo le tre vulnerabilità segnalate e pubblicate nel precedente articolo, ho scoperto un altro ben più grave problema che ho prontamente segnalato al team Beentouch facendo notare che la vulnerabilità in oggetto mette a rischio la privacy degli utenti.

Purtroppo, a differenza delle precedenti segnalazioni, l’azienda questa volta non riconosce la vulnerabilità e dopo numerose email mi scrivono inspiegabilmente:

Dalle nostre analisi non emerge alcun difetto sulle API, quindi non intendiamo porre una data di disclosure su un problema che non rileviamo che non sia semplicemente il soggettivo grado di elevatura dei sistemi di sicurezza preposti a proteggere il dato.

Inspiegabilmente si rifiutano di riconoscere il problema, arrivando a definire la mia segnalazione “un dubbio”, mentre in realtà, come evidenzierò, si tratta di una vulnerabilità in una loro api molto grave che non richiede nessuna elevatura.

Un attaccante ‘autenticato’ al servizio Beentouch può avere accesso ai dati personali (email, numero di telefono) di TUTTI gli utenti Beentouch 

Quali sono i dati in questione?

• Nome
• Cognome
• email
• numero di telefono
• eventuale Facebook id

Quali sono le implicazioni?

Per come è definita la struttura dati di Beentouch, questo problema permette ad un utente smaliziato, e nemmeno troppo esperto, di avere il DB di tutti gli  utenti di Beentouch in pochi minuti.

Ho anche chiesto all’azienda se avesse intenzione di fare analisi per capire se questa vulnerabilità sia già stata usata per furto di dati, ma ho ricevuto un criptico:

“Il dettaglio delle procedure interne all’azienda per fronteggiare problematiche di questo tipo non sono divulgabil”

Anche questa volta non rileverò i dettagli che permettono di sfruttare la vulnerabilità per tutelare l’azienda ed i suoi utenti, ma spero che la giovane startup faccia marcia indietro e risolva il problema.

Spero che questo articolo possa da un lato  mettere in guardia gli utenti Beentouch, ma dall’altro sia spunto di riflessione per chi si accinge a costruire un nuovo prodotto.

Vi ricordo che se volete essere aggiornati sui miei nuovi articoli, potete farlo con telegram! https://telegram.me/iuculano

Update

È apparso ieri sera un post nel blog di Beentouch, molto ben scritto. Francamente credo che si impieghi molto più tempo a scrivere un post del genere, che a risolvere il problema (se lo si capisce ovviamente).

Rispondo però ai punti principali.

• Giustissimo il punto dove si chiarisce che il numero di telefono non è usato come metodo di autenticazione, però omettono un particolare. Se in un’applicazione che fa Call e videocall o instant messaging riesco a chiamare a nome di un’altra persona, è un problema di sicurezza
• Fanno riferimento a dei super sistemi di sicurezza e alarm che avvisano in caso di tentativi di intrusione. Molto scenica e di impatto, ma purtroppo con una API progettata male non c’è alarm che tenga, semplicemente si ha accesso all’informazione
• Di impatto anche l’analogia con la cassa, la chiave, e la tenaglia. Purtroppo l’analogia è usata impropriamente, perchè nel caso specifico bisognerebbe specificare che non occorre nessuna tenaglia, ma la stessa chiave fornita da Beentouch. Direi che l’analogia più onesta sia questa: è come se un venditore di casse distribuisca lucchetti che vengono aperti tutti con una chiave, distribuita a tutti i proprietari delle casse. Ogni chiave può aprire tutti i lucchetti.

Piccola nota a chiusura del tutto personale

Penso che gli utenti avrebbero apprezzato di più l’umiltà di una azienda che riconosce il problema, avvisa gli utenti, e fa di tutto per risolverlo. Beentouch si è dimostrata molto attenta nella comunicazione tentando maldestramente di sottostimare il problema e dando informazioni parziali. Una startup ai primi mesi di vita dovrebbe pensare un po’ meno all’apparire, più al prodotto.

L'articolo Beentouch, gravissimo problema di sicurezza non riconosciuto dall’azienda. Privacy a rischio. sembra essere il primo su Giuseppe.

Anche se definita come app che “guarda al futuro“, in realtà Beentouch è l’ennesima app costruita sopra Quickblox, un framework proprietario che permette di costruire in poco tempo una app capace di effettuare chiamate, videochiamate e instant messaging.  Nonostante tante testate locali (e non) parlino di un algoritmo rivoluzionario, dalle mie analisi risulta che Beentouch faccia uso di protocolli e codec di Quickblox standard, ma ovviamente se gli autori vorranno replicare con dati e benchmark a supporto sono i benvenuti.

Fatta questa premessa, andiamo al vero argomento dell’articolo.

Spinto dalla curiosità, ho analizzato Beentouch per capire se anche la chiacchierata app sviluppata da ragazzi catanesi soffrisse di vulnerabilità simili a quelle della ormai defunta CiaoIm.

Purtroppo il mio sospetto si è rilevato realtà, Beentouch soffre delle stesse vulnerabilità di CiaoIm, ed in particolare ha un bel po’ di errori nel design del protocollo di autenticazione e registrazione:

• Un attaccante è in grado di registrarsi a nome di un altro utente Beentouch, o numero inesistente all’applicazione Beentouch
• Un attaccante è in grado di usare, ovvero chiamare e videochiamare, a nome di un altro utente Beentouch, o numero inesistente.

In aggiunta, ho trovato anche un altro serio problema, un leak di informazione sensibili:

• Un attaccante può facilmente recuperare le credenziali usate dall’applicazione Beentouch per mandare SMS OTP tramite il gateway Telecom (easyapi), riuscendo a mandare SMS abusivamente dal gateway Telecom.

Disclosure delle vulnerabilità

Giorno 2 Maggio ho contattato il team di Beentouch, che a differenza del team di CiaoIm, si è dimostrato molto disponibile e collaborativo, ringraziandomi per la segnalazione.

Ho dato i dettagli (che nell’articolo sono ancora parzialmente omessi), e abbiamo concordato 20 giorni per la risoluzione. Ahimè dopo un mese le vulnerabilità non sono ancora corrette (nonostante diversi update su Google Play), quindi dopo un paio di rinvii richiesti, ho deciso di rendere pubbliche le vulnerabilità.

Vorrei complimentarmi con i ragazzi di Beentouch che, a differenza di CiaoIm e del suo CEO Davide Erba, hanno gestito bene la comunicazione con il sottoscritto dimostrandosi collaborativi e disponibili. Un po’ meno per la velocità dei fix, che ricordo ad oggi non ci sono…

Vi ricordo che se volete essere aggiornati sui miei nuovi articoli, potete farlo con telegram! https://telegram.me/iuculano

Update

Ho identificato un altro, molto più grave problema. Ho inviato i dettagli al team di Beentouch e sono in attesa di concordare una data per il disclosure.

Update 2

Beentouch, gravissimo problema di sicurezza non riconosciuto dall’azienda. Privacy a rischio.

L'articolo Beentouch, gravi problemi di sicurezza sembra essere il primo su Giuseppe.