Come gli hacker sfruttano le webcam come backdoor
Le segnalazioni di hacking riusciti contro dispositivi Internet of Things (IoT) sono in aumento. La maggior parte di questi tentativi ha riguardato la dimostrazione di come ottenere l'accesso a tali dispositivi o di sfondare la loro barriera di sicurezza. La maggior parte di questi attacchi è considerata relativamente insignificante perché i dispositivi stessi non contengono dati di valore (come numeri di carte di credito o PII). I dispositivi in questione in genere non forniscono molto valore al proprietario di una botnet, poiché tendono ad avere accesso a molta larghezza di banda, ma hanno pochissimo in termini di CPU e RAM.
Tuttavia, questi dispositivi diventano più interessanti per gli aggressori sofisticati quando possono essere utilizzati per stabilire un punto di accesso persistente in una rete. L'inserimento di una backdoor di callback in una webcam, ad esempio, consente a un hacker di accedere a tempo pieno alla rete senza dover ricorrere all'infezione di un laptop, di una workstation o di un server, tutti dispositivi che di solito sono sottoposti a un elevato controllo e possono essere spesso sottoposti a patch. Su un dispositivo di piccole dimensioni, non c'è antivirus né protezione endpoint . Di fatto, nessuno pensa che il dispositivo abbia un software al suo interno. Ciò rende questi dispositivi potenzialmente invitanti per gli aggressori persistenti che si affidano a canali furtivi di comando e controllo per gestire i loro attacchi.
L'aspetto negativo per l'attaccante è che questa classe di dispositivi di solito non dispone di una 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'aggressore di ottenere una vera persistenza si basa sulla possibilità di controllare ciò che si trova nella flash ROM. In questo blog esploreremo quanto sia difficile creare una nuova immagine flash che possa contenere tutti gli strumenti necessari per avere una vera backdoor persistente nella rete su cui è installato il dispositivo. Una volta ottenuta tale immagine flash, la sua messa in opera potrebbe comportare l'"aggiornamento" di un dispositivo già distribuito o l'installazione della backdoor sul dispositivo in qualche punto della catena di distribuzione, ossia prima che venga ricevuto e installato dal cliente finale. Affinché questo esperimento sia significativo, è indispensabile che il dispositivo continui a svolgere le sue normali funzioni, altrimenti solleverebbe immediatamente dei sospetti o indurrebbe il cliente a sostituire il dispositivo con una versione funzionante.
Come iniziare con l'exploit della webcam
In questo scenario, il team di Vectra Threat Labs ha acquistato una videocamera WiFi D-Link di livello consumer per circa 30 dollari USA*. Aprire quella piccola e meravigliosa custodia di plastica è stata un'esperienza straordinaria che ci ha ricordato che un Leatherman non è l'attrezzo giusto per ogni lavoro...
Una rapida occhiata al circuito stampato mostra:
- Antenna WiFi
- Ralink RT5350F
- SDram M12L2561616a-6t
- Flash Rom MX25L3205
Fase 1: Dumping della memoria flash
Data la presenza del chip di memoria flash sul PCB, si suppone che sia qui che i dati/codice vengono probabilmente conservati per la persistenza. La prima cosa da fare è quindi scaricare il contenuto del chip per vedere cosa vi è memorizzato.
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 libero, ottenere 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 di 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 della memoria flash
Una volta ottenuto un bel dump della flash, possiamo usare binwalk per determinare cosa c'è al suo interno.
#binwalk -Me MX25L3205-A DECIMAL HEXADECIMAL DESCRIPTION--------------------------------------------------------------------------------0 0x0 uImage header, header size: 64 bytes, header CRC: 0x11BEF629, created: Tue Feb 3 11:07:53 2015, dimensione immagine: 111116 byte, Indirizzo dati: 0x80200000, Punto di ingresso: 0x80200000, CRC dati: 0xCD95F789, OS: Linux, CPU: MIPS, tipo di immagine: Standalone Program, tipo di compressione: nessuno, nome immagine: "SPI Flash Image "91040 0x163A0 Stringa versione U-Boot, "U-Boot 1.1.3"105424 0x19BD0 Intestazione del documento HTML105777 0x19D31 Piè di pagina del documento HTML105780 0x19D34 Intestazione del documento HTML105979 0x19DFB Piè di pagina del documento HTML106140 0x19E9C Intestazione del documento HTML106840 0x1A158 Piè di pagina del documento HTML210495 0x3363F Certificato PEM211671 0x33AD7 Chiave privata PEM RSA327680 0x50000 Intestazione uImage, dimensione intestazione: 64 byte, CRC intestazione: 0xABF213A9, creata: Tue Feb 3 11:07:48 2015, dimensione immagine: 3730981 byte, Indirizzo dati: 0x80000000, Entry Point: 0x8038B000, CRC dati: 0x2829F3C1, OS: Linux, CPU: MIPS, tipo di immagine: OS Kernel Image, tipo di compressione: lzma, nome immagine: "Linux Kernel Image "327744 0x50040 Dati compressi LZMA, proprietà: 0x5D, dimensione dizionario: 33554432 byte, dimensione non compressa: 6394309 byte327744 0x50040 Dati compressi LZMA, proprietà: 0x5D, dimensione dizionario: 33554432 byte, dimensione non compressa: 6394309 byte
Il formato di questo firmware consiste in un u-boot e in un kernel e un'immagine Linux.
Avremmo potuto usare dd, lzma o cpio per estrarre il contenuto del firmware o lasciare che binwalk facesse questo lavoro. Abbiamo ancora bisogno di estrarre l'ultimo passo dell'immagine cpio per vedere il contenuto dell'immagine.
#cpio -ivd --no-absolute-filenames -F. 0.cpio Una volta eseguito quest'ultimo passaggio, si può accedere al filesystem dell'immagine Linux.
Un 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), linkato dinamicamente, interprete /lib/ld-uClibc.so.0, strippato
Passo 3: analisi del binario upgradefw
In questa sezione ci affideremo a IDA Pro come strumento di scelta per il reverse-engineering del binario di aggiornamento.
IDA è in grado di fare una prima analisi molto buona del binario, il che lo rende molto più facile da analizzare. Seguendo il percorso del codice dalla funzione principale si arriva rapidamente a una funzione chiamata "check" che svolge la maggior parte del lavoro di verifica della validità dell'immagine flash prima di inviarla a mtd_write.
La convalida effettuata dal binario upgradefw sembra includere alcuni controlli crc32, controlli memmem/str e qualche ciclo che calcola un valore e lo confronta con un valore fisso o due.
Il flusso logico della funzione di controllo tra il punto di ingresso e il ritorno al successo è più o meno il seguente:
1. Controllare se il file è stato aperto correttamente
2. Controllare le dimensioni del file
3. Caricare il file e verificare che la lettura abbia funzionato
4. Selezionare la voce "Firma: "
5. Controllare l'opzione "Rilascio": "
6. Confrontare la release con la release corrente
7. Routine di controllo di Uboot/uimage
passare a x86 qui per il checksum 55AA55AA.
Passo 4: Aggiunta di una backdoor nella webcam
A questo punto, l'aggiunta di una backdoor si riduce all'aggiunta di un servizio all'interno di un sistema Linux: nel nostro caso, tutto ciò che vogliamo è un semplice proxy Socks di ritorno. Questo può essere realizzato con srelay e netcat nello script di avvio o con codice C più ottimizzato, oppure con una semplice backdoor di callback con una shell che utilizza netcat e busybox, già presenti nel sistema.
È sempre una buona idea essere il più leggeri possibile nelle funzioni aggiunte: dopo tutto, non abbiamo un computer portatile completo con cui lavorare, ma piuttosto una piccola webcam con 4 MB di ROM. Quindi, aggiungere troppe funzionalità non farà altro che rompere il software. Mentre apportiamo la modifica, possiamo anche rimuovere la possibilità di riflashare il dispositivo in futuro. In questo modo si eviterebbe un aggiornamento del firmware avviato dall'amministratore che rimuoverebbe la nostra backdoor.
Passo 5: riconfezionamento dello script
Dopo aver dedicato un po' di tempo alla creazione di uno script di riconfezionamento, abbiamo trovato un bello script sul sito web di Ralink che si è rivelato piuttosto utile.
utilizzarlo con:
make -f Makefile.4M
A questo punto è sufficiente correggere la somma di controllo del file. Questo può essere ottenuto con un'utilità di RaLink chiamata addchecksum o correggendo manualmente la somma di controllo. L'offset e l'intervallo di checksum utilizzati possono essere scoperti sia nel binario di upgradefw che in quello di addchecksum. E come al solito... controllate l'endianness.
Fase 6: Prova di un collegamento posteriore
Utilizzando telnetd / busybox / netcat possiamo riportare un socket telnet a un host esterno per avere una persistenza remota alla webcam. Con la webcam che funge da proxy, l'aggressore può ora inviare traffico di controllo nella rete per portare avanti il suo attacco, e allo stesso modo usare la webcam per trafugare i dati rubati.
Il carattere di escape è '^]'.(nessuno) login: adminPassword:BusyBox v1.12.1 (2015-11-11 05:41:04 UTC) shell integrata (ash)Inserire '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 questo significa che la webcam di D-Link ha un grave problema di sicurezza? Non necessariamente: otteniamo ciò che paghiamo, e chiedere a un fornitore che vende una webcam su Amazon per 30 dollari di fornire funzioni 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 l'impatto reale 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ù elementari possono fornire le infrastrutture per un canale di comando e controllo persistente. Sebbene questi dispositivi abbiano un basso valore in termini di costi, sono comunque importanti per la sicurezza della rete e i team devono tenerli d'occhio per individuare eventuali segnali di comportamento dannoso.
*Vectra ha comunicato il problema a D-LInk all'inizio di dicembre 2015. Al 7 gennaio 2016, l'azienda non ha fornito una soluzione.