Il mito della privacy e della crittografia end-to-end in Zoom

Zoom è un servizio per ospitare meeting senza bisogno di installare e configurare complicati applicativi: è una delle tante soluzioni per chi, in periodo di quarantena, vuole tenersi in contatto con amici e parenti.

In questo ultimo periodo, sta avendo un successo dato dalla semplicità con cui è possibile iniziare a fare meeting e dalla possibilità di incontrarsi con un semplice tocco. Basta infatti un URL e tutti i partecipanti sono connessi. Questo ha permesso che molti professori attuassero la didattica a distanza utilizzando la piattaforma Zoom.us.

Tuttavia un’altro dibattito sta prendendo vita; difatti, se è vero che questa piattaforma permette a milioni di persone di stare in contatto con amici, familiari e colleghi, vi sono molti dubbi sulla sua efficacia nel proteggere i dati personali degli utenti e quindi la loro privacy.

Il mio intento è quello di approfondire in maniera tecnica quali dati effettivamente vengono inviati ai server Zoom. La prima parte dell’analisi prenderà in considerazione la policy sulla privacy applicata antecedentemente il 29 marzo per poi passare ad una valutazione tecnica che stabilisca se tale policy sia stata rispettata o meno.

Questo articolo non sarà l’unico dove tratterò questo argomento e sarà seguito da un secondo “capitolo” in cui verrà spiegato il funzionamento del client e cosa avviene all’atto della creazione di un meeting.

Zoom.us Privacy Policy

Perchè iniziare questa analisi con la policy sulla privacy? Essenzialmente perchè si tratta di un esempio di brand protection policy che, attraverso una serie di termini giuridici, mira a blindare la propria reputazione di fronte ai dubbi sorti dopo il caso della vulnerabilità riscontrata sul client Zoom per la piattaforma iOS. Inoltre è interessante vedere come tale policy sia cambiata in una finestra temporale di circa 10 giorni.

Difatti nella versione estratta su web.archive.org, datata 18 marzo, appaiono chiare le differenze con la versione attualmente in vigore. Attraverso un sopraffine gioco di parole e la sostituzione di alcuni lemmi come “terze parti” l’attuale versione appare molto “privacy compliant”:

We do not use data we obtain from your use of our services, including your meetings, for any advertising.

Tale paragrafo, tuttavia, viene in qualche modo contraddetto da questo:

To personalize marketing communications and website content based on your preferences, such as in response to your request for specific information on products and services that may be of interest.

Riassumendo, Zoom afferma di garantire la privacy non sfruttando alcun dato dell’utente per fini di business. Tale affermazione purtroppo non rassicura e non chiarifica effettivamente se e come i dati dell’utente vengano gestiti. Quindi ci si chiede; può considerarsi garantita la mia privacy se Zoom non vende i miei dati? Posso dirmi al sicuro?
Per dirimere ogni eventuale dubbio non resta altro che analizzare tecnicamente cosa avviene durante un meeting effettuato con Zoom e confermare o confutare la “loro versione dei fatti”.

Analisi: ispezionare le richieste

Passando alla parte tecnica ho prediletto l’uso di ZAP, un web application scanner sulla falsariga del ben più famoso Burp, che mi ha permesso di catturare le singole richieste in https e le sessioni sul Websocket.

Una volta aver effettuato l’accesso ad un meeting su Zoom, si nota che la prima richiesta inviata dall’host sorgente ha come destinazione zoom.us/j/config, che permette al client stesso di ottenere tutti i dettagli sul meeting tra i quali l’elenco degli endpoint ed i parametri per stabilire ricevere e trasmettere dati con l’infrastruttura Zoom. Come ogni richiesta HTTP che si rispetti, i dati che vengono inviati sono suddivisi in due porzioni: l’header ed il body.

Nel primo si trovano:

• un cookie contenente un ID univoco _ZMMTG_TRACK_ID (fornisce un fingerprint unico per la macchina da cui si utilizza zoom), non è un cookie “commerciale”;
• user-agent: versione del client Zoom, sistema operativo ed architettura (x86 o x64);
• ZM-CAP: numero
• ZM-PROP: Mac.Zoom (stringa hard-coded per client, per Windows sarà Win.Zoom)
• ZM-RF: 1
• ZM-ORIGIN: US (può essere US, CN, JP, DE, FR, PT, ES, KR a seconda della lingua selezionata);
• ZM-LOCALE: “DEF” per tutte i paesi, “CN” se si connette attraverso l’applicazione Cinese;
• ZM-CID: device_id saltato con md5;
• ZM-NSGN: concatenazione del device_id saltato (utilizzato probabilmente per abbinare lo User Agent al tipo di device) e timestamp della richiesta;

Come body, troviamo:

• username con cui si partecipa al meeting
• _ZMMTG_TRACK_ID` che deve essere uguale a quello inviato in header contiene un base64 del deviceid + una stringa randomica;
• versione del client utilizzata
• “client” per chi si unisce al meeting, altrimenti “server” se si è l’host;
• il meeting ID;
• password del meeting (se il meeting non disponibile attraverso URL pubblico);
• source (attraverso l’url oppure attraverso la dashboard);
• timestamp;

Una volta ottenuto l’elenco degli endpoint la connessione viene impostata in modalità end-to-end (o peer-to-peer) attraverso l’uso del web socket usato dall’infrastruttura Zoom. Questa modalità di instaurazione della connessione permane uguale su tutte le piattaforme quali Microsoft, Apple e Linux.

Android app: un caso particolare

Per Android, che costituisce un caso particolare, il funzionamento è differente. Difatti vengono dapprima inviate tre informazioni:

• hardwareInfo
• meeting-id
• personal-zoom-id

Quello che suscita un certo stupore, ma anche curiosità, è la funzione getHardwareInfo() diversa dall’implementazione che troviamo nell’SDK messo a disposizione dall’azienda. Come di seguito mostrato dallo screenshot, tale funzione crea una sorta di report diagnostico sul device utilizzato includendo informazioni su marca, modello, sistema operativo fino al paese e la presenza o meno di una modifica per l’uso dei permessi di root.

Andando avanti con l’analisi dell’apk si trova una ulteriore sezione in cui viene controllata la presenza o meno del binario “su” per acquisire l’utenza di un altro utente ma in particolare di root.
Tale controllo salta all’occhio ed appare inusuale soprattutto per un applicativo utilizzato solo ed esclusivamente per meeting online.

Il mito della criptazione end-to-end

Ritornando all’argomento “privacy” è molto interessante evidenziare come la così acclamata comunicazione “end-to-end” funzioni realmente. Leggendo attentamente quello che viene riportato nello screenshot seguente, Zoom assicura che ogni sessione tra due o più host verrebbe cifrata, utilizzo il condizionale poiché, come anche affermato dal portavoce di Zoom:

“Currently, it is not possible to enable E2E encryption for Zoom video meetings. Zoom video meetings use a combination of TCP and UDP. TCP connections are made using TLS and UDP connections are encrypted with AES using a key negotiated over a TLS connection."

Nonostante l’encryption end-to-end sia supportato, le sessioni non vengono cifrate come l’utente si aspetta. La cifratura definita come end-to-end si basa sul criterio che ogni informazione scambiata tra due o più host sia cifrata e venga decifrata solo dal mittente e dal destinatario rendendo impossibile ad un terzo di poter introdursi e carpire le informazioni.
Ecco, nel caso di Zoom, l’ente terzo è proprio l’infrastruttura server che si fa carico, nello schema end-to-end, solo di trasmettere il messaggio al destinatario senza visualizzarlo o manipolarlo. Il destinatario, in questo modello, non fa altro che connettersi all’infrastruttura Zoom ed accedere al messaggio cifrato inviato dal mittente per poi decifrarlo grazie alla chiave in suo possesso.

Non sembra però essere questo il caso di Zoom, dato che sia il Desktop client sia il Web client, utilizzano la tecnologia TLS per poter comunicare con il server.

La tecnologia TLS è un protocollo di comunicazione che si basa sulla crittografazione dei pacchetti utilizzando delle chiavi. Le chiavi per questa crittografia simmetrica vengono generate in modo univoco per ogni connessione e si basano su un “segreto” che è stato negoziato all’inizio della sessione (handshaking). Tuttavia, il server che comunica con il client deve essere per forza a conoscenza del “segreto”.

Questo implica che Zoom può accedere ad ogni contenuto presente nei suoi server; ciò mostra come la parola “end-to-end” viene solo aggiunta per migliorare “l’immagine aziendale”. In realtà, la documentazione di Zoom menziona solo la possibilità di crittografare in maniera end-to-end le chat dei meeting, a patto però di sottoscrivere un piano a pagamento. “Se è gratis, il prodotto sei tu”.

Conclusioni

Riassumendo, si può affermare che zoom rappresenti una soluzione certamente versatile, di facile uso ed accessibile da tutti su qualsiasi piattaforma ad oggi conosciuta in ambito Home. Tuttavia permane una profonda incertezza sul come venga garantita e protetta la privacy dell’utente finale e del dispositivo da questi utilizzato.

Come ricercatore, ma anche come utente più smaliziato, mi attendo che l’azienda dirami questa sorta di nebbiosa situazione e chiarisca in modo assolutamente trasparente.

Nonostante zoom possa, ad oggi, esser considerata la piattaforma di maggior successo, vi è la possibilità di poter sfruttare altre soluzioni più open tra le quali , ad onor di cronaca, Jitsi rappresenta forse la più valida alternativa.

Jitsi è un insieme di progetti open source che consente di creare e implementare facilmente soluzioni di videoconferenza sicure e private. Al centro di Jitsi ci sono Jitsi Videobridge e Jitsi Meet, che consentono di tenere conferenze su Internet. Il maggior vantaggio è dato dalla natura “self-hosted” che permette agli utenti di installarsi Jitsi sul proprio server per gestire i propri dati in modo più diretto.