tothi/pwn-hisilicon-dvrExploit proof-of-concept e divulgazione di vulnerabilità per dispositivi DVR/NVR HiSilicon hi3520d. Dimostra RCE tramite interfaccia web, credenziali backdoor e analisi del buffer overflow.
= HiSilicon DVR hack Istvan Toth [email protected] v1.0, 2017-09-06 :source-highlighter: pygments :toc: preamble :toclevels: 5 :toc-title: Contents :image_width: 100%
[abstract] Questo rapporto rivela serie vulnerabilità (con codice proof of concept (PoC)) dei dispositivi DVR/NVR costruiti con il HiSilicon hi3520d e simili system on a chip (SoC). Lo sfruttamento delle vulnerabilità porta a esecuzione remota di codice (RCE) non autorizzata usando solo l'interfaccia web, causando la completa compromissione del dispositivo sfruttato. A causa della mancanza di firmware aggiornati, l'uso di questi dispositivi non è raccomandato. Il venditore è stato contattato prima di dicembre 2016, ma non c'è ancora stata risposta. La data di rilascio della divulgazione è febbraio 2017.
== prefazione
Un paio di anni fa ho comprato un economico DVR cinese su eBay. Il logo di avvio del dispositivo dice: "SECULINK - Security Monitoring". Da appassionato di sicurezza informatica, ho deciso di dare un'occhiata più da vicino al dispositivo per vedere quanto "sicuro" fosse quel servizio di monitoraggio di sicurezza. Cercando su Google ho trovato materiale interessante, ma scavando più a fondo ho trovato problemi (0-day) molto più interessanti e molto più seri riguardanti il dispositivo.
Diamo un'occhiata all'intera sessione di hacking dall'inizio. (I nuovi risultati, ottenuti personalmente, saranno indicati come nuovi, così come quelli vecchi e già noti.)
== esplorare il DVR
Prima dovremmo imparare a usare l'interfaccia utente ufficiale, poi scavare più a fondo, magari cercare di ottenere il firmware. Le probabilità di trovare vulnerabilità aumentano con il firmware.
=== il DVR a prima vista
Il dispositivo DVR usato per i test è marchiato "Seculink".
image::./seculink_device.png[Dispositivo DVR Seculink]
Interfacce fisiche disponibili:
Interfacce utente ufficiali:
L'interfaccia di configurazione accessibile direttamente è protetta da autenticazione utente (nome utente, password). Il superutente predefinito è 'admin', la password predefinita è vuota.
Dopo aver impostato una password robusta, l'utente può sentirsi al sicuro che la visualizzazione delle sue telecamere non sia accessibile ad altri. Spesso le persone inoltrano la porta web (tcp/80) del DVR verso il lato WAN dalla loro LAN sicura per accedere ai flussi del DVR dall'esterno (possiamo verificarlo, ad esempio, con una ricerca Shodan adeguata ;) ).
=== ottenere il firmware
Ci possono essere molti modi per ottenere il firmware:
Anche se quest'ultimo metodo (il download) funziona ed è il più semplice, proviamo il primo, perché fornisce anche altre informazioni sul dispositivo.
=== scansione dei servizi
Facciamo una scansione completa delle porte sul DVR. Nota: la scansione SYN (predefinita se eseguita come root) è molto lenta a causa dei pacchetti scartati, ma la scansione completa TCP connect termina in un paio di minuti.
Nmap scan report for dvr.lan (192.168.88.127) Host is up (0.028s latency). Not shown: 65529 closed ports PORT STATE SERVICE VERSION 23/tcp open telnet BusyBox telnetd 80/tcp open http uc-httpd 1.0.0 554/tcp open rtsp LuxVision or Vacron DVR rtspd 9527/tcp open unknown 34567/tcp open dhanalakshmi? 34599/tcp open unknown MAC Address: 00:12:12:15:B3:E7 (Plus ) Service Info: Host: LocalHost; Device: webcam
Riassumendo e test manuali:
Nota: anche l'apertura del flusso rtsp richiede le credenziali.
Qui dovremmo precisare che il dispositivo è probabilmente un sistema simile a Linux.
Connettendosi alla porta 9527/tcp (con netcat raw) si vede la console
dell'applicazione con messaggi di log e un prompt di login. Il login con una qualsiasi
delle credenziali applicative definite funziona. Digitando help dopo il
prompt si ottiene una breve descrizione dei comandi della console. Il comando
shell sembra il più interessante. Sì, fornisce una shell di root sul
dispositivo. ;)
Nota: questo è ovviamente un serio problema di sicurezza, perché un qualsiasi utente applicativo (con privilegi bassi) non dovrebbe ottenere automaticamente una shell di root sul dispositivo.
=== shell di root
Esplorando il dispositivo nella shell di root (ad esempio con dmesg)
diventa chiaro che il DVR esegue un kernel Linux (versione 3.0.8), ha
una CPU ARMv7 e il modello di SoC è hi3520d.
Dall'elenco dei processi in esecuzione (ps) è chiaro che l'applicazione
DVR è /var/Sofia, che è in ascolto anche su 34568/udp e
34569/udp oltre alle porte tcp rilevate da nmap
(netstat -nlup).
Dall'elenco dei file system montati (comando mount), è chiaro che
l'immagine del firmware è nei dispositivi /dev/mtdblockX (dove X=0,1,2,3,4,5).
Il firmware è piccolo e quindi limitato, quindi dobbiamo essere creativi se vogliamo copiare file da/al dispositivo. Fortunatamente NFS è supportato, quindi configurare un server NFS sulla nostra macchina desktop e montarlo dal DVR risolve il problema:
Ora ottenere il firmware è semplice:
Possiamo ottenere i file (non solo le immagini grezze):
=== interfaccia telnet
Per accedere al dispositivo tramite l'interfaccia telnet (porta 23/tcp),
potremmo aver bisogno di alcune credenziali del sistema operativo. Guardando
/etc/passwd troviamo l'hash della password per l'utente root:
Nota: non c'è nessun altro utente oltre a root, tutto viene eseguito con pieni privilegi. (Quindi se qualcuno riesce a introdursi nel dispositivo in qualche modo, non ci sono barriere: l'attaccante ottiene immediatamente pieni poteri.)
Supponendo una password alfanumerica (minuscola) di sei caratteri, hashcat decifra rapidamente il debole hash DES sopra riportato:
$ ./hashcat64.bin -a3 -m1500 absxcfbgXtb3o -1 ?l?d ?1?1?1?1?1?1
