Come gli hacker sfruttano le webcam come backdoor
Sono in aumento le segnalazioni di attacchi hacker riusciti contro dispositivi Internet of Things (IoT). La maggior parte di questi tentativi ha riguardato la dimostrazione di come ottenere l'accesso a tali dispositivi o superare le loro barriere di sicurezza. La maggior parte di questi attacchi è considerata relativamente irrilevante perché i dispositivi stessi non contengono dati realmente preziosi (come numeri di carte di credito o informazioni personali identificabili). I dispositivi in questione generalmente non offrono molto valore ai proprietari di botnet, poiché tendono ad avere accesso a molta larghezza di banda, ma hanno pochissima CPU e RAM.
Tuttavia, questi dispositivi diventano più interessanti per gli hacker esperti quando possono essere utilizzati per stabilire un punto di accesso persistente in una rete. Inserire una backdoor di callback in una webcam, ad esempio, offre a un hacker un accesso permanente alla rete senza dover ricorrere all'infezione di un laptop, una workstation o un server, che di solito sono sottoposti a un attento controllo e spesso possono essere aggiornati con patch. Su un dispositivo così piccolo non sono presenti antivirus né endpoint . Infatti, nessuno pensa che il dispositivo possa contenere software. Ciò rende questi dispositivi potenzialmente allettanti per gli hacker persistenti che si affidano a canali di comando e controllo invisibili per gestire i propri attacchi.
Lo svantaggio per l'autore dell'attacco è che questa classe di dispositivi solitamente non dispone di alcuna memoria persistente realmente utilizzabile. Utilizzano invece la nvram per memorizzare la configurazione e la flash ROM per memorizzare il codice in esecuzione. Pertanto, la speranza dell'autore dell'attacco di ottenere una reale persistenza si basa sulla possibilità di controllare il contenuto della flash ROM. In questo blog, esploreremo quanto sia difficile creare una nuova immagine flash che possa contenere tutti gli strumenti necessari per avere una backdoor realmente persistente alla rete su cui è installato il dispositivo. Una volta ottenuta tale immagine flash, la sua implementazione potrebbe comportare l'"aggiornamento" di un dispositivo già distribuito o l'installazione della backdoor sul dispositivo in un punto qualsiasi della catena di distribuzione, ovvero prima che venga ricevuto e installato dal cliente finale. Affinché questo esperimento sia significativo, è fondamentale che il dispositivo continui a svolgere la sua normale funzione, altrimenti solleverebbe immediatamente sospetti o indurrebbe il cliente a sostituirlo con una versione funzionante.
Guida introduttiva all'exploit della webcam
In questo scenario, il team di Vectra Threat Labs ha acquistato una webcam WiFi D-Link di fascia consumer per circa 30 dollari*. Aprire quel piccolo e meraviglioso involucro di plastica è stata un'esperienza incredibile, che ci ha ricordato che un Leatherman non è lo strumento giusto per ogni lavoro...
Una rapida occhiata al circuito stampato mostra:
- Antenna WiFi
- Ralink RT5350F
- SDram M12L2561616a-6t
- Flash ROM MX25L3205
Passaggio 1: scaricare la memoria flash
Data la presenza del chip di memoria flash sul PCB, ipotizziamo che sia qui che vengono conservati i dati/codici per garantirne la persistenza. Quindi la prima cosa da fare è scaricare il contenuto di quel chip per vedere cosa è memorizzato al suo interno.
Dopo aver collegato un Bus Pirate alla scheda, possiamo usare flashrom per scaricare il contenuto.
#flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=1Mflashrom v0.9.7-r1782 su Linux 4.0.0-kali1-amd64 (x86_64)flashrom è un software gratuito, scarica il codice sorgente, Calibrazione del loop di ritardo... OK. Trovato chip flash Macronix "MX25L3205(A)" (4096 kB, SPI) su buspirate_spi. Trovato chip flash Macronix "MX25L3205D/MX25L3208D" (4096 kB, SPI) su buspirate_spi.Trovato chip flash Macronix "MX25L3206E" (4096 kB, SPI) su buspirate_spi. Più definizioni di chip flash corrispondono ai chip rilevati: "MX25L3205(A)", "MX25L3205D/MX25L3208D", "MX25L3206E" Specificare quale definizione del chip utilizzare con l'opzione -c .
Ora possiamo scaricare il contenuto dei chip flash per ulteriori analisi.
#flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=1M -c 'MX25L3205(A)' -r MX25L3205-A
Fase 2: Analisi del dump flash
Una volta ottenuto un buon dump della memoria flash, possiamo usare binwalk per determinare cosa contiene.
#binwalk -Me MX25L3205-A DECIMALE ESADECIMALE DESCRIZIONE--------------------------------------------------------------------------------0 0x0 intestazione uImage, dimensione intestazione: 64 byte, CRC intestazione: 0x11BEF629, creato: martedì 3 febbraio 11:07:53 2015, dimensione immagine: 111116 byte, indirizzo dati: 0x80200000, Punto di ingresso: 0x80200000, CRC dati: 0xCD95F789, Sistema operativo: Linux, CPU: MIPS, tipo di immagine: Programma autonomo, tipo di compressione: nessuno, nome immagine: "SPI Flash Image"91040 0x163A0 Stringa versione U-Boot, "U-Boot 1.1.3"105424 0x19BD0 Intestazione documento HTML105777 0x19D31 Piè di pagina documento HTML105780 0x19D34 Intestazione documento HTML105979 0x19DFB Piè di pagina documento HTML106140 0x19E9C Intestazione documento HTML106840 0x1A158 piè di pagina del documento HTML210495 0x3363F certificato PEM211671 0x33AD7 chiave privata RSA PEM327680 0x50000 intestazione uImage, dimensione intestazione: 64 byte, CRC intestazione: 0xABF213A9, creato: Tue Feb 3 11:07:48 2015, dimensione immagine: 3730981 byte, Indirizzo dati: 0x80000000, Punto di ingresso: 0x8038B000, CRC dati: 0x2829F3C1, OS: Linux, CPU: MIPS, tipo di immagine: immagine del kernel del sistema operativo, tipo di compressione: lzma, nome dell'immagine: "Linux Kernel Image"327744 0x50040 dati compressi LZMA, proprietà: 0x5D, dimensione del dizionario: 33554432 byte, dimensione non compressa: 6394309 byte327744 0x50040 Dati compressi LZMA, proprietà: 0x5D, dimensione del dizionario: 33554432 byte, dimensione non compressa: 6394309 byte
Quindi il formato di questo firmware è composto da un u-boot, un kernel Linux e un'immagine.
Avremmo potuto usare dd, lzma o cpio per estrarre il contenuto del firmware oppure lasciare che fosse binwalk a farlo. Dobbiamo ancora estrarre l'ultimo passaggio dell'immagine cpio per vedere il contenuto dell'immagine.
#cpio -ivd --no-absolute-filenames -F. 0.cpio Una volta completato quest'ultimo passaggio, possiamo accedere al filesystem dell'immagine Linux.
Un file binario interessante nel filesystem è /bin/upgradefw, che sembra essere l'eseguibile utilizzato per eseguire la verifica e l'aggiornamento del firmware.
#file ./bin/upgradefw./bin/upgradefw: eseguibile ELF a 32 bit LSB, MIPS, MIPS-II versione 1 (SYSV), collegato dinamicamente, interprete /lib/ld-uClibc.so.0, stripped
Passaggio 3: Analisi del binario upgradefw
Per questa sezione utilizzeremo IDA Pro come strumento preferito per il reverse engineering del binario di aggiornamento.
IDA è in grado di eseguire un ottimo primo passaggio sul binario, rendendo l'analisi molto più semplice. Seguendo il percorso del codice dalla funzione principale, si arriva rapidamente a una funzione denominata "check" che svolge la maggior parte del lavoro di verifica della validità dell'immagine flash prima di inviarla a mtd_write.
La convalida eseguita dal binario upgradefw sembra includere alcuni controlli crc32, controlli memmem/strstr e alcuni loop che calcolano un valore e lo confrontano con uno o due valori fissi.
Il flusso logico della funzione di controllo tra il punto di ingresso e un ritorno di successo è approssimativamente il seguente:
1. Controllare che il file sia stato aperto correttamente.
2. Controllare la dimensione del file
3. Caricare il file e verificare che la lettura abbia funzionato
4. Controlla la "Firma: "
5. Controllare "Rilascio: "
6. Confronta la versione con quella attuale
7. Routine di controllo Uboot/uimage
passaggio a x86 qui per il checksum 55AA55AA.
Passaggio 4: aggiunta di una backdoor nella webcam
A questo punto, aggiungere una backdoor equivale grosso modo ad aggiungere un servizio all'interno di un sistema Linux: nel nostro caso, tutto ciò che vogliamo è un semplice proxy Socks con connessione di ritorno. Ciò può essere ottenuto con uno srelay e netcat nello script di avvio o con un codice C più ottimizzato, oppure si potrebbe optare per una semplice backdoor di callback con una shell utilizzando netcat e busybox, già presenti nel sistema.
È sempre una buona idea aggiungere il minor numero possibile di funzionalità: dopotutto, non abbiamo a disposizione un laptop completo, ma solo una piccola webcam con 4 MB di ROM. Aggiungere troppe funzionalità comprometterebbe il funzionamento del software. Durante la modifica, possiamo anche rimuovere la possibilità di riflashare il dispositivo in futuro. Ciò impedirebbe un aggiornamento del firmware avviato dall'amministratore che rimuoverebbe la nostra backdoor.
Passaggio 5: Ricomposizione dello script
Dopo aver dedicato un po' di tempo alla creazione di uno script di ricompressione, abbiamo trovato uno script molto utile sul sito web di Ralink.
utilizzarlo con:
make -f Makefile.4M
Dopodiché, è sufficiente correggere il checksum nel file. Ciò può essere ottenuto utilizzando l'utilità RaLink denominata addchecksum oppure correggendo manualmente il checksum. L'offset/intervallo utilizzato dal checksum può essere individuato sia nel file binario upgradefw che in quello addchecksum. E come al solito... controllate l'endianness.
Passaggio 6: Testare una riconnessione
Utilizzando telnetd / busybox / netcat possiamo riportare un socket telnet su un host esterno per ottenere una persistenza remota sulla webcam. Con la webcam che funge da proxy, l'autore dell'attacco può ora inviare traffico di controllo nella rete per portare avanti il suo attacco e, allo stesso modo, utilizzare la webcam per sottrarre i dati rubati.
Il carattere di escape è '^]'.(nessuno) login: adminPassword:BusyBox v1.12.1 (2015-11-11 05:41:04 UTC) shell integrata (ash)Digitare 'help' per un elenco dei comandi integrati.# ls /biniwpriv pcmcmd nvram_daemon ntpclient sounddb ipush touch pwd ls cpov7740 switch mii_mgr mtd_write notifystream schedule sync ps login chmoduvc_stream gpio ated msmtp mydlinkevent lanconfig sleep ping kill catmail nvram_set reg mDNSResponder imagetp iperf sh mount grep ashi2c nvram_get pppoecd lld2d upgradefw inadyn sed mknod echo busyboxswing ralink_init openssl disablebonjour audiopush umount rm mkdir date alphapd
Conclusione: protezione contro le backdoor delle webcam
Tutto ciò significa che la webcam di D-Link presenta un grave problema di sicurezza? Non necessariamente: otteniamo ciò per cui paghiamo, e chiedere a un fornitore che vende una webcam su Amazon a 30 dollari di fornire funzionalità di aggiornamento del firmware sicure, che richiederebbero un TPM o un chip specializzato per verificare il contenuto e la firma di un aggiornamento software, non è molto realistico. Lo scopo di questa dimostrazione è piuttosto quello di evidenziare il reale impatto che i dispositivi IoT hanno sulla superficie di attacco di una rete. Come abbiamo dimostrato, le barriere all'hacking di questi dispositivi sono relativamente basse e anche i dispositivi più semplici possono fornire le basi per un canale di comando e controllo persistente. Sebbene questi dispositivi abbiano un valore basso in termini di costi effettivi, sono comunque importanti per la sicurezza della rete e i team devono tenerli sotto controllo per individuare eventuali segni di comportamenti dannosi.
*Vectra ha segnalato il problema a D-Link all'inizio di dicembre 2015. Al 7 gennaio 2016, l'azienda non ha ancora fornito una soluzione.