Convierte tu webcam en un backdoor
Los reportes de (Cr)"hackeos" exitosos contra dispositivos e Internet de Cosas (IoT) han ido en aumento. La mayor parte de estos esfuerzos han implicado la demostración de como ganar el acceso a tal dispositivo o abrirse camino en su barrera de seguridad. La mayor parte de estos ataques son considerados relativamente inconsecuente porque los mismos dispositivos no contienen verdaderos datos de valor (como números de la tarjeta de crédito o PII). Los dispositivos en cuestión generalmente no proporcionan mucho valor al propietario de una botnet quien(es) tienden a tener el acceso a la amplitud de caracteristicas de las partes, pero tienen muy poco en términos de CPU y RAM.
Sin embargo estos dispositivos se hacen más interesantes a atacantes sofisticados cuando ellos pueden establecer un persistente punto de acceso en una red. estableciendo un backdoor de retrollamada en una webcam, por ejemplo, da a un (cr)hacker el acceso todo el tiempo a la red sin necesidad de confiar en la infección de una laptop, el terminal de trabajo o un servidor, todo lo cual por lo general se muestra en un alto escrutinio y a menudo puede ser parchado.
En un dispositivo pequeño, no hay ningún antivirus y ninguna protección de punto final. De hecho, nadie piensa en el dispositivo como el software sobre ello en absoluto. Esto hace que estos dispositivos sean potenciales retos a los atacantes persistentes que confían en los canales cautelosos de mando-y-control para manejar sus ataques.
El inconveniente para el atacante es que esta clase de dispositivos no tiene ningún almacenaje persistente que es realmente utilizable.En cambio, ellos usan nvram para almacenar la configuración y la memoria ROM de sólo lectura para almacenar el código que corre, Entonces la esperanza del atacante para una intrusion descansa en la capacidad de controlar la flash ROM
En este blog, exploraremos como de difícil es crear una nueva imagen flash que podría contener todos las herramientas que necesitamos tener para crear un backdoor persistente sobre la red en la cual el dispositivo está instalado. Una vez que tenemos tal imagen, podriamos provocar un "updating" del dispositivo con la instalación de nuestro backdoor, esto en algún sitio en la cadena de entrega x ej. antes de que sea recibido e instalado por el cliente final.
Para hacer de este experimento significativo, es imperativo que el dispositivo siga realizando su función normal de otra manera, inmediatamente levantaría la sospecha o haría que el cliente sustituyera el dispositivo
EMPECEMOS
En este escenario, el equipo de Sky Labs Labs compró una camara web wifi d-link por masomenos 30 dólares USD*. luego abri su bonita carcasa plástica con un recordatorio de que se debe usar una herramienta adecuada para cada trabajo...
Una vista rápida en la placa de circuitos muestra:
DUMPEANDO LA MEMORIA FLASH
Considerando la presencia del chip de memoria flash sobre el PCB, concluimos que es aquí donde los datos/código son guardados. Entonces lo primero por hacer es dumpear el contenido de aquel chip para ver qué almacena.
Después de conectar la placa a un Bus pirata podemos usar el flashrom para volcar el contenido.
#flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=1M flashrom v0.9.7-r1782 on Linux 4.0.0-kali1-amd64 (x86_64) flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OK. Found Macronix flash chip "MX25L3205(A)" (4096 kB, SPI) on buspirate_spi. Found Macronix flash chip "MX25L3205D/MX25L3208D" (4096 kB, SPI) on buspirate_spi. Found Macronix flash chip "MX25L3206E" (4096 kB, SPI) on buspirate_spi. Multiple flash chip definitions match the detected chip(s): "MX25L3205(A)", "MX25L3205D/MX25L3208D", "MX25L3206E"
Ahora podemos volcar el contenido del chip flash para un análisis remoto
#flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=1M -c 'MX25L3205(A)' -r MX25L3205-A
Una vez que tenemos un buen dumpeo de la flash podemos usar binwalk para determinar lo que hay dentro
#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, image size: 111116 bytes, Data Address: 0x80200000, Entry Point: 0x80200000, data CRC: 0xCD95F789, OS: Linux, CPU: MIPS, image type: 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 header 105777 0x19D31 HTML document footer 105780 0x19D34 HTML document header 105979 0x19DFB HTML document footer 106140 0x19E9C HTML document header 106840 0x1A158 HTML document footer 210495 0x3363F PEM certificate 211671 0x33AD7 PEM RSA private key 327680 0x50000 uImage header, header size: 64 bytes, header CRC: 0xABF213A9, created: Tue Feb 3 11:07:48 2015, image size: 3730981 bytes, Data Address: 0x80000000, Entry Point: 0x8038B000, data CRC: 0x2829F3C1, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "Linux Kernel Image" 327744 0x50040 LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 6394309 bytes327744 0x50040 LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 6394309 bytes
#cpio -ivd --no-absolute-filenames -F. 0.cpio
Una vez que este último paso fue completado, podemos tener acceso al sistema de archivos de imagen Linux. Un binario interesante en el sistema de archivos es el/bin/upgradefw, esto parece ser el ejecutable usado a la verificación realizada y la actualización del firmware
#file ./bin/upgradefw ./bin/upgradefw: ELF 32-bit LSB executable, MIPS, MIPS-II version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped
Para esta sección aunque prefiero el Ollydbg esta vez confiaremos en la potencia del Ida Pro como herramienta para hacer ingenieria inversa al binario del upgrade
IDA es capaz de tomar un primer pase al binario que lo hace más fácil para analizar. Siguiendo el código de la función principal llegamos rápidamente a una función llamada "check" que hace la mayor parte del trabajo de verificación si la imagen flash es válida antes de enviarlo a mtd_write.
La validación hecha por el binario upgradefw parece incluir unas pequeñas comprobaciones de crc32, comprobaciones memmem/strstr y algún loop que calcula un valor y lo compara a un valor fijo o dos.
El flujo lógico de la función check entre el punto de entrada y un retorno exitoso parece hacer esto:
Comprobando el "Release"
Comparando el release con el current release
Verificando la rutina de UBoot/Uimage
switching a x86 para el 55AA55AA
AÑADIENDO UN BACKDOOR
En este punto, un backdoor adicionará un servicio dentro de un sistema Linux - en nuestro caso, todo que queremos es una simple coneccion de regreso. Esto puede o ser logrado con un relay y netcat en el script de arranque o el código de C más optimizado, o uno podría ir con una puerta de atrás de retrollamada simple con una cáscara que usa netcat y busybox que es ya el presente sobre el sistema.
Siempre es una idea buena ser tan ligero como sea posible sobre los rasgos añadidos - después de todo, no tenemos un ordenador portátil lleno para trabajar con aquí, pero más bien una webcam diminuta con 4 Mb de ROM. Entonces la adición de demasiada funcionalidad solamente va a romper el software. Mientras hacemos la modificación, también podemos quitar la capacidad para dirigir de nuevo el dispositivo en el futuro. Esto prevendría una actualización iniciada por administrador de soporte lógico inalterable que quitaría nuestra puerta de atrás.
REEMPACANDO
Después de tirarme algo de tiempo construyendo un repackage, encontré un script interesante en el sitio web de Ralink que terminó siendo bastante útil. lo usaremos con: -f Makefile.4M Después de esto es necesario fijar al checksum el archivo. Esto puede o ser alcanzado con una utilidad RaLink o manualmente arreglando el checksum. El checksum del offset/range puede usarse para descubrir en both el upgradefw
Testeando la retrollamada
Usando el telnetd / busybox / netcat podemos abrir un socket telnet a un host exterior para tener la persistencia remota a la webcam. Con la webcam actuando como proxy, el atacante ahora puede enviar el control de tráfico de la red para avanzar en su ataque, y de la misma manera usar la webcam para sacar datos robados.
Escape character is '^]'. (none) login: admin Password: BusyBox v1.12.1 (2015-11-11 05:41:04 UTC) built-in shell (ash) Enter 'help' for a list of built-in commands. # ls /bin iwpriv pcmcmd nvram_daemon ntpclient sounddb ipush touch pwd ls cp ov7740 switch mii_mgr mtd_write notifystream schedule sync ps login chmod uvc_stream gpio ated msmtp mydlinkevent lanconfig sleep ping kill cat mail nvram_set reg mDNSResponder imagetp iperf sh mount grep ash i2c nvram_get pppoecd lld2d upgradefw inadyn sed mknod echo busybox swing ralink_init openssl disablebonjour audiopush umount rm mkdir date alphapd
Conclusión
El escenario en la vida real podría verse en las tiendas online como amazon ebay olx y otras que podrias ofrecer este tipo de dispositivos a muy bajo coste conllevando a una futura irrupcion de la seguridad, El punto de esta demostración es destacar el verdadero impacto que los dispositivos IoT plantean a la superficie de ataque de una red. Como hemos mostrado, las barreras a la piratería informática de estos dispositivos son relativamente bajos, y aún los dispositivos más básicos pueden proporcionar la fuente necesaria para la creacion de un canal de mando-y-control persistente. Mientras estos dispositivos no muestran mayor valor e importancia, ellos todavía importan a la seguridad de la red.(a la fecha la compañía D-Link no solucionó este fallo) Feliz Semana amigos de Impactos de las TIC´s
y pentesters que nos siguen.
root@SkySecurity# www.skytecnologias.com
No hay comentarios:
Publicar un comentario