Zoom per Mac corregge il subdolo bug "spiami" - aggiorna ora!

Popolare e onnipresente (il software non è sempre entrambe le cose!), la società di cloud meeting Zoom ha recentemente annunciato un bug che non avrebbe dovuto verificarsi nella versione Mac del suo software.

Il bollettino sulla sicurezza è, perdonabile, scritto nel tipico stile staccato e intriso di gergo dei cacciatori di bug, ma il significato è abbastanza chiaro.

Il bug è indicato CVE-2022-28762, ed è dettagliato in Bollettino Zoom ZB-22023:

Quando il contesto di rendering della modalità fotocamera è abilitato come parte dell'API Zoom App Layers eseguendo determinate app Zoom, una porta di debug locale viene aperta dal client Zoom.

Dove vorresti andare oggi?

Una "porta di debug" si riferisce in genere a una connessione di rete in ascolto, solitamente un socket TCP, che gestisce le richieste di debug.

Nello stesso modo in cui un server di posta elettronica solitamente ascolta sulla porta TCP 25, aspettando che i client di posta elettronica remoti "chiamino" sulla rete e richiedano il permesso di consegnare i messaggi in arrivo, le porte di debug ascoltano su una porta di loro scelta (spesso configurabile, anche se a volte solo in modo non documentato) per le connessioni in entrata che desiderano inviare comandi di debug.

A differenza di un server di posta elettronica, però, che accetta richieste relative alla consegna dei messaggi (ad es. MAIL FROM ed RCPT TO), le connessioni di debug in genere forniscono un tipo di interazione molto più intima con l'app a cui ti stai connettendo.

In effetti, le porte di debug in genere consentono non solo di scoprire la configurazione e lo stato interno dell'app stessa, ma anche di inviare comandi direttamente all'app, incluso il tipo di comandi che compromettono la sicurezza e che non sono disponibili per gli utenti normali che utilizzano tramite la normale interfaccia utente.

Un server di posta elettronica, ad esempio, in genere ti consentirà di inviare un messaggio alla sua porta TCP per un nome utente di tua scelta, ma non ti consentirà di inviare comandi che riconfigurano il server stesso e non ti consentirà di estrarre informazioni segrete. come le statistiche del server o i messaggi di altre persone.

Al contrario, queste sono esattamente il tipo di "funzionalità" normalmente consentite dalle porte di debug, in modo che gli sviluppatori possano modificare e monitorare il comportamento della loro app mentre cercano di risolvere i problemi, senza dover passare attraverso la normale interfaccia utente.

(Puoi vedere come questa sorta di "canale laterale" all'interno di un'applicazione sarebbe particolarmente utile quando stai tentando di eseguire il debug dell'interfaccia utente stessa, dato che l'atto di utilizzare l'interfaccia utente per eseguire il debug dell'interfaccia utente quasi sicuramente interferirebbe con le stesse misurazioni che stavi cercando di effettuare.)

In particolare, le porte di debug in genere consentono di ottenere una sorta di "visione interna" dell'app stessa, ad esempio: sbirciare in aree di memoria che normalmente non verrebbero mai esposte agli utenti dell'app; acquisire istantanee di dati che potrebbero contenere dati riservati come password e token di accesso; e attivare acquisizioni audio o video senza avvisare l'utente...

…tutto senza accedere all’app o al servizio in primo luogo.

In altre parole, le porte di debug sono un male necessario da utilizzare durante lo sviluppo e il test, ma non dovrebbero essere attivate, o idealmente nemmeno attivabili, durante l'uso regolare dell'app, a causa delle ovvie falle di sicurezza che introducono.

Nessuna password necessaria

In parole povere, se hai accesso alla porta TCP su cui il debugger è in ascolto e puoi creare una connessione TCP ad essa, questa è tutta l'autenticazione necessaria per assumere il controllo dell'app.

Ed è per questo che le porte di debug vengono in genere abilitate solo in circostanze attentamente controllate, quando sai di voler effettivamente consentire a uno sviluppatore di vagare all'interno dell'applicazione, godendo di ciò che è effettivamente un accesso da superpotere non regolamentato e potenzialmente pericoloso.

In effetti, molti prodotti software sono deliberatamente realizzati in due versioni diverse: una build di debug, in cui il debug può essere attivato se lo si desidera, e una build di rilascio in cui le funzionalità di debug sono omesse del tutto in modo che non possano essere attivate affatto, sia tramite incidente o per progettazione.

I telefoni Android di Google includono una modalità di debug, in cui puoi collegare un cavo USB e accedere al telefono (anche se non con tutti i poteri di root) dal tuo laptop tramite quello che è noto come ADB, abbreviazione di Bridge di debug Android. Per abilitare il debug, devi prima fare clic su Impostazioni profilo > Info sul telefono > Numero di build sette volte (davvero!) di seguito. Solo allora l'opzione per attivare il debug appare anche nei menu, dove puoi attivarlo Impostazioni profilo > Sistema > Tecnologia > Opzioni sviluppatori > Debug USB. Quindi, quando ti colleghi e provi a connetterti dal tuo laptop, devi autorizzare la connessione tramite un popup di avviso sul telefono stesso. Puoi certamente farlo apposta, se hai accesso fisico a un telefono sbloccato, ma è improbabile che accada per errore.

Per ulteriore sicurezza, le porte di debug sono spesso impostate in modo da non accettare connessioni provenienti da altri computer (in termini tecnici, ascoltano solo sull'interfaccia "localhost").

Ciò significa che un utente malintenzionato che cerca di abusare di un'interfaccia di debug abilitata in modo errato avrebbe bisogno prima di un punto d'appoggio sul tuo computer, come una sorta di malware proxy che accetta connessioni tramite Internet e quindi inoltra i suoi pacchetti di rete all'interfaccia di rete "localhost".

Nonostante la necessità di una sorta di accesso locale nel caso di CVE-2022-28762, Zoom ha assegnato a questo bug un "punteggio di gravità" CVSS di 7.3/10 (73%) e un punteggio di urgenza di Alta.

Le connessioni di rete TCP locali sono in genere progettate per funzionare oltre i confini degli utenti e dei processi, quindi un utente malintenzionato non avrebbe bisogno di accedere come te (o come amministratore) per abusare di questo bug: qualsiasi processo, anche un programma in esecuzione con un limite molto limitato account ospite, potrebbe essere in grado di spiarti a piacimento.

Inoltre, poiché i comandi software emessi tramite una porta di debug in genere funzionano indipendentemente dalla normale interfaccia utente di un'app, probabilmente non vedresti alcun segno che la tua sessione Zoom sia stata dirottata in questo modo.

Se un utente malintenzionato attivasse l'app tramite canali di controllo remoto Mac più convenzionali come Screen Sharing (VNC), avresti almeno la possibilità di individuare l'utente malintenzionato che muove il puntatore del mouse, fa clic sui pulsanti del menu o digita testo...

…ma tramite un’interfaccia di debug, che è essenzialmente una backdoor deliberata, potresti essere del tutto inconsapevole (e forse addirittura incapace di rilevare) che un utente malintenzionato ti stava spiando personalmente, utilizzando la tua webcam e il tuo microfono.

Cosa fare?

Fortunatamente, il team di sicurezza di Zoom ha individuato quello che presumiamo fosse un errore in fase di compilazione (una funzionalità lasciata abilitata che avrebbe dovuto essere soppressa) e ha prontamente aggiornato il software Mac difettoso.

Aggiorna il tuo client Zoom macOS a versione 5.12.0 o successiva e la porta di debug rimarrà chiusa quando usi Zoom.

Su un Mac, vai al menu principale zoom.us menu e scegli Check for Updates... per vedere se hai la versione più recente.

---