Cómo explotan los hackers las cámaras web como puertas traseras
Los informes sobre hackeos con éxito contra dispositivos de Internet de las Cosas (IoT) han ido en aumento. La mayoría de estos intentos han consistido en demostrar cómo acceder a un dispositivo de este tipo o traspasar su barrera de seguridad. La mayoría de estos ataques se consideran relativamente intrascendentes porque los propios dispositivos no contienen datos reales de valor (como números de tarjetas de crédito o PII). Por lo general, los dispositivos en cuestión no aportan mucho valor al propietario de una botnet, ya que suelen tener acceso a mucho ancho de banda, pero disponen de muy poco en términos de CPU y RAM.
Sin embargo, estos dispositivos se vuelven más interesantes para los atacantes sofisticados cuando pueden utilizarse para establecer un punto de acceso persistente en una red. Poner una puerta trasera de devolución de llamada en una cámara web, por ejemplo, da a un pirata informático acceso a tiempo completo a la red sin tener que depender de infectar un ordenador portátil, una estación de trabajo o un servidor, todos los cuales suelen estar muy vigilados y a menudo pueden estar parcheados. En un dispositivo diminuto, no hay antivirus ni protección de punto final. De hecho, nadie piensa que el dispositivo tenga software. Esto hace que estos dispositivos sean potencialmente atractivos para los atacantes persistentes que confían en canales sigilosos de mando y control para gestionar sus ataques.
El inconveniente para el atacante es que esta clase de dispositivos no suelen tener ningún almacenamiento persistente que sea realmente utilizable. En su lugar, utilizan la nvram para almacenar la configuración y la flash ROM para almacenar el código en ejecución. Así que la esperanza del atacante para una persistencia real descansa en ser capaz de controlar lo que habrá en la flash ROM. En este blog, exploraremos lo difícil que es crear una nueva imagen flash que pueda contener todas las herramientas que necesitamos para tener una verdadera puerta trasera persistente a la red en la que está instalado el dispositivo. Una vez que tengamos dicha imagen flash, ponerla en marcha podría implicar "actualizar" un dispositivo ya desplegado o instalar la puerta trasera en el dispositivo en algún punto de la cadena de entrega, es decir, antes de que lo reciba e instale el cliente final. Para que este experimento tenga sentido, es imprescindible que el dispositivo siga realizando su función normal, ya que de lo contrario levantaría inmediatamente sospechas o haría que el cliente sustituyera el dispositivo por una versión que funcione.
Primeros pasos con Webcam Exploit
En este caso, el equipo de Vectra Threat Labs adquirió una cámara web WiFi D-Link de consumo por unos 30 dólares*. Abrir esa pequeña y maravillosa caja de plástico fue una experiencia increíble que nos recordó que una Leatherman no es la herramienta adecuada para todos los trabajos...
Un rápido vistazo a la placa de circuito muestra:
- Antena WiFi
- Ralink RT5350F
- SDram M12L2561616a-6t
- Flash Rom MX25L3205
Paso 1: Volcado de la memoria flash
Dada la presencia del chip de memoria flash en la PCB, suponemos que es ahí donde probablemente se guardan los datos/código para su persistencia. Así que lo primero que hay que hacer es volcar el contenido de ese chip para ver qué hay almacenado en él.
Después de conectar un Bus Pirate a la placa, podemos usar flashrom para volcar el contenido.
#flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=1Mflashrom v0.9.7-r1782 en Linux 4.0.0-kali1-amd64 (x86_64)flashrom es software libre, obtén el código fuente, Calibrando el bucle de retardo... OK. Encontrado chip flash Macronix "MX25L3205(A)" (4096 kB, SPI) en buspirate_spi.Encontrado chip flash Macronix "MX25L3205D/MX25L3208D" (4096 kB, SPI) en buspirate_spi.Encontrado chip flash Macronix "MX25L3206E" (4096 kB, SPI) en buspirate_spi.Varias definiciones de chip flash coinciden con los chips detectados: "MX25L3205(A)", "MX25L3205D/MX25L3208D", "MX25L3206E "Especifique qué definición de chip utilizar con la opción -c.
Ahora podemos volcar el contenido de los chips flash para su posterior análisis.
#flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=1M -c 'MX25L3205(A)' -r MX25L3205-A
Paso 2: Análisis del volcado de flash
Una vez que tenemos un buen volcado de la flash podemos utilizar binwalk para determinar lo que hay dentro de ella.
#binwalk -Me MX25L3205-A DECIMAL HEXADECIMAL DESCRIPTION--------------------------------------------------------------------------------0 0x0 uCabecera de imagen, tamaño de cabecera: 64 bytes, CRC de cabecera: 0x11BEF629, creada: Tue Feb 3 11:07:53 2015, tamaño de la imagen: 111116 bytes, Dirección de datos: 0x80200000, Punto de entrada: 0x80200000, datos CRC: 0xCD95F789, OS: Linux, CPU: MIPS, tipo de imagen: Standalone Program, compression type: none, image name: "SPI Flash Image "91040 0x163A0 U-Boot version string, "U-Boot 1.1.3"105424 0x19BD0 HTML document header105777 0x19D31 HTML document footer105780 0x19D34 HTML document header105979 0x19DFB HTML document footer106140 0x19E9C HTML document header106840 0x1A158 HTML document footer210495 0x3363F PEM certificate211671 0x33AD7 PEM RSA private key327680 0x50000 uImage header, header size: 64 bytes, header CRC: 0xABF213A9, created: mar Feb 3 11:07:48 2015, tamaño de la imagen: 3730981 bytes, Dirección de datos: 0x80000000, Punto de entrada: 0x8038B000, datos CRC: 0x2829F3C1, OS: Linux, CPU: MIPS, tipo de imagen: OS Kernel Image, tipo de compresión: lzma, nombre de la imagen: "Linux Kernel Image "327744 0x50040 Datos comprimidos LZMA, propiedades: 0x5D, tamaño del diccionario: 33554432 bytes, tamaño sin comprimir: 6394309 bytes327744 0x50040 Datos comprimidos LZMA, propiedades: 0x5D, tamaño del diccionario: 33554432 bytes, tamaño sin comprimir: 6394309 bytes
Así que el formato de este firmware consiste en un u-boot y un kernel e imagen Linux.
Podriamos haber usado dd, lzma o cpio para extraer el contenido del firmware o podemos dejar que binwalk haga este trabajo. Aún necesitamos extraer el último paso de la imagen cpio para ver el contenido de la imagen.
#cpio -ivd --no-absolute-filenames -F. 0.cpio Una vez realizado este último paso, podemos acceder al sistema de archivos de imagen de Linux.
Un binario interesante en el sistema de archivos es el /bin/upgradefw, este parece ser el ejecutable utilizado para realizar la verificación y actualización del firmware.
#Archivo ./bin/upgradefw./bin/upgradefw: ELF 32-bit LSB executable, MIPS, MIPS-II version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped
Paso 3: Análisis del binario upgradefw
En esta sección vamos a utilizar IDA Pro como herramienta para realizar la ingeniería inversa del binario de actualización.
IDA es capaz de hacer una muy buena primera pasada al binario lo que lo hace mucho más fácil de analizar. Siguiendo la ruta del código desde la función principal nos lleva rápidamente a una función llamada "check" que hace la mayor parte del trabajo de verificar si la imagen flash es válida antes de enviarla a mtd_write.
La validación realizada por el binario upgradefw parece incluir algunas comprobaciones crc32, comprobaciones memmem/strstr y algún bucle que calcula un valor y lo compara con uno o dos valores fijos.
El flujo lógico de la función de comprobación entre el punto de entrada y un retorno con éxito es más o menos así:
1. Compruebe si el archivo se ha abierto correctamente
2. Comprobar el tamaño del archivo
3. Cargar el archivo y comprobar que la lectura ha funcionado
4. Marque la casilla "Firma: "
5. Marque la casilla "Liberar: "
6. Comparar la versión con la versión actual
7. Rutina de comprobación Uboot/uimage
cambiando a x86 aquí por la suma de comprobación 55AA55AA.
Paso 4: Añadir una puerta trasera en la Webcam
En este punto, añadir una puerta trasera se convierte más o menos en añadir un servicio dentro de un sistema Linux - en nuestro caso, todo lo que queremos es un simple proxy Socks connect-back. Esto se puede lograr con un srelay y netcat en el script de inicio o con código C más optimizado, o se podría ir con una simple puerta trasera de devolución de llamada con un shell usando netcat y busybox que ya están presentes en el sistema.
Siempre es una buena idea ser lo más ligero posible en las características añadidas - después de todo, no tenemos un portátil completo con el que trabajar aquí, sino más bien una pequeña webcam con 4MB de ROM. Así que añadir demasiadas funcionalidades va a romper el software. Mientras hacemos la modificación, también podemos eliminar la capacidad de reflashear el dispositivo en el futuro. Esto evitaría una actualización de firmware iniciada por el administrador que eliminaría nuestra puerta trasera.
Paso 5: Reempaquetar el guión
Después de pasar algún tiempo construyendo un script de reempaquetado, encontramos un buen script en el sitio web de Ralink que terminó siendo bastante útil.
úsalo con:
make -f Makefile.4M
Después de eso, todo lo que se necesita es arreglar la suma de comprobación del archivo. Esto se puede conseguir con una utilidad de RaLink llamada addchecksum o arreglando manualmente la suma de comprobación. El offset/rango que usa la suma de comprobación puede ser descubierto tanto en el binario upgradefw como en el addchecksum. Y como de costumbre... compruebe su endianness.
Paso 6: Probar un connect back
Usando telnetd / busybox / netcat podemos traer un socket telnet a un host externo para tener persistencia remota a la webcam. Con la webcam actuando como un proxy, el atacante puede ahora enviar tráfico de control en la red para avanzar en su ataque, y del mismo modo utilizar la webcam para desviar los datos robados.
El carácter de escape es '^]'.(none) login: adminContraseña:BusyBox v1.12.1 (2015-11-11 05:41:04 UTC) shell integrado (ash)Introduce 'help' para ver una lista de comandos integrados.# 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
Conclusión: Cómo protegerse de las puertas traseras de las cámaras web
¿Significa todo esto que la cámara web de D-Link tiene un grave problema de seguridad? No necesariamente: obtenemos lo que pagamos, y pedir a un proveedor que vende una cámara web en Amazon por 30 dólares que proporcione funciones de actualización de firmware seguras que requerirían un TPM o un chip especializado para verificar el contenido y la firma de una actualización de software no es muy realista. El objetivo de esta demostración es más bien poner de relieve el impacto real que los dispositivos IoT suponen para la superficie de ataque de una red. Como hemos demostrado, las barreras para piratear estos dispositivos son relativamente bajas, e incluso los dispositivos más básicos pueden proporcionar las tuberías para un canal de mando y control persistente. Aunque estos dispositivos tienen poco valor en términos de costes, siguen siendo importantes para la seguridad de la red, y los equipos deben vigilarlos para detectar cualquier indicio de comportamiento malicioso.
*Vectra comunicó el problema a D-LInk a principios de diciembre de 2015. A 7 de enero de 2016, la empresa no había proporcionado una solución.