tothi/pwn-hisilicon-dvrExploit de prueba de concepto y divulgación de vulnerabilidad para dispositivos DVR/NVR HiSilicon hi3520d. Demuestra RCE a través de la interfaz web, credenciales de backdoor y análisis de desbordamiento de búfer.
= Hackeo de DVR HiSilicon Istvan Toth [email protected] v1.0, 2017-09-06 :source-highlighter: pygments :toc: preamble :toclevels: 5 :toc-title: Contents :image_width: 100%
[abstract] Este informe divulga vulnerabilidades graves (con código de prueba de concepto (PoC)) de dispositivos DVR/NVR construidos con el sistema en un chip (SoC) HiSilicon hi3520d y similares. La explotación de las vulnerabilidades conduce a la ejecución remota de código (RCE) no autorizada usando solo la interfaz web, lo que provoca la toma de control total del dispositivo explotado. Debido a la falta de firmwares actualizados, no se recomienda el uso de estos dispositivos. Se contactó con el proveedor antes de diciembre de 2016, pero aún no hay respuesta. La fecha de publicación de la divulgación es febrero de 2017.
== prefacio
Hace un par de años compré un DVR chino barato en eBay. El logo de arranque del dispositivo dice: "SECULINK - Security Monitoring". Como entusiasta de la seguridad informática, decidí echar un vistazo más de cerca al dispositivo para ver qué tan "seguro" es ese servicio de monitoreo de seguridad. Buscando en Google sobre el tema encontré algunos materiales interesantes, pero profundicé más y encontré problemas mucho más interesantes y mucho más graves (0-days) sobre el dispositivo.
Echemos un vistazo a la sesión de hacking completa desde el principio. (Los nuevos hallazgos propios se indicarán junto con los antiguos, ya conocidos).
== explorando el DVR
Primero deberíamos aprender la interfaz de usuario oficial, luego profundizar, tal vez intentar obtener el firmware. Las posibilidades de encontrar vulnerabilidades aumentan con el firmware.
=== el DVR a primera vista
El dispositivo DVR destinado a las pruebas está marcado como "Seculink".
image::./seculink_device.png[Dispositivo DVR Seculink]
Interfaces físicas disponibles:
Interfaces de usuario oficiales:
La interfaz de configuración de acceso directo está restringida por autenticación de usuario (nombre de usuario, contraseña). El superusuario predeterminado es 'admin', y la contraseña predeterminada está vacía.
Después de establecer una contraseña segura, el usuario puede sentirse seguro de que su vista de cámara no es accesible para otros. La gente suele redirigir el puerto web (tcp/80) del DVR hacia el lado WAN desde su LAN segura para acceder a los flujos del DVR desde el exterior (podemos comprobarlo, por ejemplo, con una búsqueda adecuada en Shodan ;) ).
=== obteniendo el firmware
Puede haber muchas formas de obtener el firmware:
Aunque el último método (descarga) funciona aquí y es el más fácil, probemos el primero, porque también da otra información sobre el dispositivo.
=== escaneo de servicios
Hagamos un escaneo completo de puertos en el DVR. Nótese que el escaneo SYN (el predeterminado si lo ejecuta root) es muy lento debido a paquetes descartados, pero el escaneo completo de conexión TCP termina en un par de minutos.
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
Resumiendo y probando manualmente:
Nótese que abrir el flujo rtsp también requiere credenciales.
Aquí debemos señalar que el dispositivo es probablemente un sistema tipo Linux.
Conectarse a 9527/tcp (con netcat crudo) muestra la consola de la
aplicación con mensajes de registro y un prompt de inicio de sesión.
Iniciar sesión con cualquiera de las credenciales definidas de la
aplicación funciona. Escribir help después del prompt da una breve
descripción de los comandos de la consola. El comando shell parece ser
el más interesante. Sí, da un shell de root en los dispositivos. ;)
Nótese que esto es obviamente un grave problema de seguridad, porque ningún usuario de la aplicación (con bajos privilegios) debería obtener un shell de root en el dispositivo automáticamente.
=== shell de root
Explorar el dispositivo en el shell de root (por ejemplo, con dmesg)
deja claro que el DVR está ejecutando un kernel Linux (versión 3.0.8),
tiene una CPU ARMv7 y el modelo de SoC es hi3520d.
De la lista de procesos en ejecución (ps) queda claro que la
aplicación del DVR es /var/Sofia, que también está escuchando en
34568/udp y 34569/udp además de los puertos tcp detectados por nmap
(netstat -nlup).
De la lista de discos montados (comando mount), queda claro que la
imagen del firmware está en los dispositivos /dev/mtdblockX (donde
X=0,1,2,3,4,5).
El firmware es pequeño y por lo tanto limitado, así que debemos ser creativos si queremos copiar archivos hacia/desde el dispositivo. Afortunadamente NFS es compatible, así que configurar un servidor NFS en nuestra máquina de escritorio y montarlo desde el DVR resuelve el problema:
Ahora obtener el firmware es sencillo:
Podemos obtener los archivos (no solo las imágenes crudas):
=== interfaz telnet
Para acceder al dispositivo a través de la interfaz telnet (puerto
23/tcp), podemos necesitar algunas credenciales del sistema operativo.
Mirando /etc/passwd tenemos el hash de la contraseña del usuario root:
Nótese que no hay otro usuario que root, todo se ejecuta con privilegios completos. (Así que si alguien irrumpe en el dispositivo de alguna manera, no hay barrera: el atacante obtiene poder total de inmediato).
Suponiendo una contraseña alfanumérica de seis caracteres (minúsculas), hashcat descifra el débil hash DES anterior rápidamente:
$ ./hashcat64.bin -a3 -m1500 absxcfbgXtb3o -1 ?l?d ?1?1?1?1?1?1
