CVE-2020-6514

The exploit Quando ho scritto l'exploit, inizialmente alteravo i pacchetti SCTP inviati al dispositivo target modificando il sorgente di WebRTC e ricompilandolo. Questo non era praticabile per attaccare applicazioni closed source, quindi alla fine sono passato all'uso di Frida per hookare il binario del dispositivo attaccante. La funzionalità di hooking di Frida consente di eseguire codice prima e dopo la chiamata di una specifica funzione nativa, il che ha permesso al mio exploit di alterare i pacchetti SCTP in uscita e ispezionare quelli in ingresso. Funzionalmente, equivale a modificare il sorgente del client attaccante, ma invece di apportare le modifiche nel sorgente in fase di compilazione, queste vengono effettuate dinamicamente da Frida in fase di esecuzione. Il sorgente dell'exploit è disponibile qui.

Ci sono sette funzioni che il dispositivo attaccante deve hookare, come segue.

usrsctp_conninput // receives incoming SCTP DtlsTransport::SendPacket // sends outgoing SCTP cricket::SctpTransport::SctpTransport // detects when SCTP transport is ready calculate_crc32c // calculates checksum for SCTP packets sctp_hmac // performs HMAC to guess secret key sctp_hmac_m // signs SCTP packet SrtpTransport::ProtectRtp // suppresses RTP to reduce heap noise

Queste funzioni possono essere hookate come simboli o come offset nel binario.

Ci sono anche tre offset di indirizzo dal binario del dispositivo target necessari affinché l'exploit funzioni. L'offset tra la funzione system e la funzione malloc, così come l'offset tra il gadget descritto nel post precedente e la funzione malloc sono due di questi. Questi offset si trovano in libc, che è una libreria di sistema Android, quindi devono essere determinati in base alla versione di Android del dispositivo target. È necessario anche l'offset dalla posizione della vtable di cricket::SctpTransport alla posizione di malloc nella global offset table. Questo deve essere determinato dal binario che contiene WebRTC nell'applicazione attaccata.

Nota che gli script di exploit forniti hanno una grave limitazione: ogni volta che viene letta la memoria, funziona solo se il bit 31 del puntatore è impostato. Le ragioni di ciò sono spiegate nella Parte 2. Lo script dell'exploit contiene un esempio di come risolvere questo problema e leggere qualsiasi puntatore usando i chunk FWD_TSN, ma questo non è implementato per ogni lettura. A scopo di test, ho resettato il dispositivo finché la libreria WebRTC non è stata mappata in una posizione favorevole. Applicazioni Android Una lista di popolari applicazioni Android che integrano WebRTC è stata determinata cercando nei file APK su Google Play una stringa specifica in usrsctp. Circa 200 applicazioni con più di cinque milioni di utenti sembravano usare WebRTC. Ho valutato queste applicazioni per determinare se potessero essere plausibilmente colpite dalle vulnerabilità dell'exploit e quale sarebbe stato l'impatto.

È emerso che i modi in cui le applicazioni usano WebRTC sono piuttosto vari, ma possono essere suddivisi in quattro categorie principali.

Proiezione: lo schermo e i controlli di un'applicazione mobile vengono proiettati in un browser desktop con il consenso dell'utente per una maggiore usabilità Streaming: contenuti audio e video vengono inviati da un utente a molti utenti. Di solito c'è un server intermedio, quindi il mittente non deve gestire potenzialmente migliaia di peer, e il contenuto viene registrato per una visione successiva Browser: tutti i principali browser contengono WebRTC per implementare l'API JavaScript WebRTC Conferenze: due o più utenti comunicano tramite audio o video in tempo reale

L'impatto delle vulnerabilità usate nell'exploit è diverso per ciascuna di queste categorie. La proiezione è a basso rischio, poiché è necessaria molta interazione da parte dell'utente per configurare la connessione WebRTC, e l'utente ha comunque accesso a entrambi i lati della connessione, quindi c'è poco da guadagnare compromettendo l'altro lato.

Anche lo streaming è a rischio relativamente basso. Sebbene sia possibile che alcune applicazioni usino connessioni peer-to-peer quando uno streaming ha un basso numero di spettatori, di solito usano un server intermedio che termina la connessione WebRTC dal peer mittente e avvia nuove connessioni con i peer riceventi. Questo significa che l'attaccante di solito non può inviare pacchetti malformati direttamente a un peer. Anche in una configurazione in cui lo streaming viene effettuato peer-to-peer, è richiesta l'interazione dell'utente affinché il target visualizzi lo streaming, e spesso non c'è modo di limitare chi può accedere a uno streaming. Per questo motivo, le applicazioni di streaming che usano WebRTC probabilmente non sono utili per attacchi mirati. Naturalmente, è possibile che queste vulnerabilità colpiscano i server usati dai servizi di streaming, ma questo non è stato indagato in questa ricerca.

I browser sono quasi certamente vulnerabili alla maggior parte dei bug di WebRTC, perché consentono un ampio controllo su come viene configurato. Per sfruttare un tale bug in un browser, un attaccante dovrebbe impostare un host che si comporti come l'altro peer nella connessione peer-to-peer e convincere il target a visitare una pagina web che avvii una chiamata verso quell'host. In questo caso, la vulnerabilità avrebbe un impatto simile ad altre vulnerabilità di corruzione della memoria in JavaScript.

Le conferenze sono l'uso di WebRTC a rischio più alto, ma l'impatto effettivo di una vulnerabilità dipende molto da come gli utenti di un'applicazione si contattano. Il design a rischio più alto è un'applicazione in cui qualsiasi utente può contattare qualsiasi altro utente tramite un identificatore. Alcune applicazioni richiedono che il chiamato abbia interagito in un modo specifico con il chiamante prima che una chiamata possa essere effettuata, il che rende più difficile contattare un target e generalmente riduce il rischio. Alcune applicazioni richiedono agli utenti di inserire un codice o visitare un link per avviare una chiamata, il che ha un effetto simile. C'è anche un ampio gruppo di applicazioni in cui è difficile o impossibile chiamare un utente specifico, ad esempio le applicazioni di chat roulette e le applicazioni che offrono funzionalità che consentono a un utente di avviare una chiamata all'assistenza clienti.

Per questa ricerca, mi sono concentrato sulle applicazioni di conferenza che consentono agli utenti di contattare altri utenti specifici. Questo ha ridotto la mia lista di 200 applicazioni a 14 applicazioni, come segue.