tezeb/accflyDivulgazione delle vulnerabilità delle telecamere Accfly: CVE-2020-25782, CVE-2020-25783, CVE-2020-25784, CVE-2020-25785.
All'inizio del 2020, presso il mio precedente posto di lavoro, ho avuto la possibilità di prendere parte a un evento in stile pwn2own interno. C'erano diversi target disponibili, ma ero maggiormente interessato alla Accfly Wireless Security camera. Sfortunatamente non ero riuscito a completare la mia ricerca per l'evento vero e proprio, ma dato che non c'erano altri tentativi su questo dispositivo, ho continuato.
L'obiettivo principale della ricerca erano le vulnerabilità che potessero portare all'esecuzione remota di codice (RCE). Questo tipo di vulnerabilità consente a un attaccante di assumere il pieno controllo del dispositivo e, nel caso di una videocamera, può risultare in un completo compromesso della privacy del proprietario. Purtroppo il firmware del dispositivo è risultato essere pieno di tali problemi.
Prima di tutto, il dispositivo non fornisce alcuna autenticazione. Di conseguenza, un attaccante in grado di connettersi ad esso può accedervi e riconfigurarlo liberamente. Nella forma più semplice, è possibile riavviare continuamente il dispositivo, rendendolo completamente inutilizzabile per l'utente legittimo. La portata di questo attacco è leggermente limitata, poiché il dispositivo è progettato per essere utilizzato all'interno di una rete WiFi, di solito dietro NAT, quindi non direttamente raggiungibile da Internet. Tuttavia, la mancanza di crittografia tra il dispositivo e l'app dello smartphone del proprietario, insieme all'uso del server del fornitore come proxy per la comunicazione, crea un'opportunità per attacchi MitM o di manipolazione DNS, che possono superare la restrizione NAT del WiFi.
Inoltre, l'applicazione utilizza un protocollo binario proprietario per la comunicazione. È stata implementata in un mix di C e C++ ed è risultata piena di funzioni di gestione delle stringhe non sicure. L'eseguibile principale contiene una grande quantità di codice inutilizzato, il che suggerisce che venga riutilizzato su altri dispositivi. Questo rende la manutenzione più difficile e aumenta la superficie d'attacco. L'applicazione non abilita alcun meccanismo di sicurezza moderno, che la proteggerebbe da molte comuni tecniche di sfruttamento. Inoltre, non limita nemmeno i permessi utente, eseguendo come root - con i più alti privilegi disponibili.
Come risultato di questa ricerca, sono state documentate le seguenti quattro vulnerabilità.
CNetClientManage::ServerIP_Proto_Set durante la gestione dei messaggi in ingressoCNetClientTalk::OprMsg durante la gestione dei messaggi in ingressoCNetClientGuard::SubOprMsg durante la gestione dei messaggi in ingressoCFtpProtocol::FtpLogin durante la procedura di aggiornamentoPer tre di esse sono stati sviluppati exploit RCE, che consentono a un attaccante di ottenere il controllo completo del dispositivo. Tuttavia, a causa della mancanza di risposta da parte del fornitore ai tentativi di segnalazione delle vulnerabilità, questo repository contiene solo PoC limitati, che si limitano a far crashare l'applicazione.
I problemi sono stati trovati nella versione del software V3.10.73 e verificati nella versione V4.15.77, l'ultima disponibile al momento della pubblicazione (26 gennaio 2021).
In caso di domande, non esitare a contattarmi via email (vedi commit git) o tramite le issue di Github. Se hai un dispositivo IoT che pensi possa essere interessante da hackerare, stai cercando un Security Researcher o vuoi solo salutare, sono felice di sentirti. Puoi anche offrirmi un caffè!
Il dispositivo preso di mira è una videocamera, controllata tramite l'app mobile associata. La mia analisi è iniziata dal traffico di rete della videocamera ed è proseguita con il firmware della stessa. Per tutte le comunicazioni viene utilizzato un protocollo binario personalizzato. I comandi vengono inviati direttamente al dispositivo mobile quando si è nella stessa rete oppure passano attraverso il server del produttore del dispositivo. Il software della videocamera ascolta su più porte TCP (23456, 34567) e UDP (34568, 34569). Non c'è crittografia né autenticazione per il traffico di rete, il che consente attacchi MitM o accesso diretto quando la videocamera è esposta sulla rete. Sembra probabile che anche l'accesso al flusso video sia possibile senza autenticazione, ma non ho fatto reverse engineering abbastanza del protocollo proprietario per provarlo.
Dopo una breve panoramica della comunicazione, il passo successivo è stato cercare di ottenere l'accesso al firmware del dispositivo. Il mio primo tentativo è stato scaricarlo direttamente dirottando il processo di aggiornamento del dispositivo, ma non è successo nulla di simile nel traffico di rete. Sarei rimasto bloccato in questa fase, se non fosse stato per l'aiuto davvero necessario di un collega che ha estratto il firmware dalla memoria flash, permettendomi di continuare questa ricerca.
Il firmware è risultato eseguire Linux su CPU MIPS little-endian. C'è esattamente un processo interessante, chiamato Alloca, che è responsabile dell'acquisizione video e gestisce anche tutte le comunicazioni di rete. L'applicazione è creata in C++ e contiene molto codice che non viene utilizzato su questo dispositivo. Ciò indica che lo stesso software viene utilizzato anche su dispositivi diversi.
Anche se questo problema è stato trovato per ultimo, è cruciale per lo sfruttamento effettivo della maggior parte degli altri, perché derivano dall'uso di funzioni C non sicure per la gestione delle stringhe. Sebbene esistano diverse tecniche che possono essere utilizzate per eseguire codice con successo in scenari simili, l'applicazione è creata in modo tale che siano per lo più inutili. Il problema principale è che il codice e i dati di Alloca sono allocati staticamente a indirizzi bassi ( < 0x01000000). Quindi i tentativi di riutilizzare il codice esistente (cioè ROP e simili) non sono utili, poiché richiedono la capacità di scrivere indirizzi nella memoria del programma. Poiché le stringhe C usano \x00 come carattere di terminazione e le funzioni di stringa terminano l'elaborazione al primo byte di questo tipo, non è possibile usare più di un singolo byte NULL. Inoltre, la posizione dello stack è randomizzata e l'applicazione è pesantemente multi-thread, il che rende altre tecniche molto meno affidabili.
Questa vulnerabilità è il risultato della condivisione di dati tra più thread e dell'uso non sicuro di strcpy. Anche se ho analizzato questo particolare problema per molto tempo, non avevo individuato la possibilità di usarlo come vettore di fuga di dati fino a poche settimane prima di questa pubblicazione. Curiosamente, grazie alla fuga dell'indirizzo heap di un oggetto C++, questa vulnerabilità consente anche l'esecuzione remota di codice. Tuttavia, questo attacco non è incluso in questo rapporto.