Tormenta en el horizonte: dentro del ecosistema de IoT de AJCloud

Introducción

Las cámaras Wi-Fi son algunos de los dispositivos IoT más comunes que se encuentran en hogares, compañías y otros espacios públicos. Suelen ser bastante asequibles y proporcionan a los usuarios un fácil acceso a una transmisión de video en directo en su dispositivo móvil desde cualquier parte del planeta. Como suele ocurrir con los dispositivos IoT, la seguridad tiende a pasar por alto en estas cámaras, dejándolas expuestas a vulnerabilidades críticas. Si se explotan, estas vulnerabilidades pueden provocar efectos devastadores en las cámaras y las redes en las que se despliegan. Pueden llevar a comprometer la PII confidencial de sus usuarios.

Una reciente Elastic ON Week nos brindó la oportunidad de explorar la superficie de ataque de este tipo de dispositivos para obtener una comprensión más profunda de cómo se están comprometiendo. Nos centramos principalmente en realizar una investigación de vulnerabilidades en la Wansview Q5 (junto con la Q6 casi idéntica), una de las cámaras más populares y asequibles que se venden en Amazon. Wansview es un proveedor de productos de seguridad con sede en Shenzhen, China, y uno de los distribuidores más destacados de cámaras Wi-Fi de Amazon.

La Q5 ofrece el mismo conjunto de características básicas que se ve en la mayoría de las cámaras:

Panorámica / inclinación / zoom
Visión nocturna
Audio bidireccional
Grabación de video en tarjeta SD
La integración con los asistentes de IA de Smart Home (p. ej. Alexa)
ONVIF para la interoperabilidad con otros productos de seguridad
RTSP para atajo a la transmisión de video dentro de la LAN
Actualizaciones de firmware automatizadas desde la nube
Soporte técnico remoto
Acceso a dispositivos compartidos con otras cuentas
Subscripción mensual opcional para espacio en la nube y detección de movimiento

Al igual que la mayoría de las otras cámaras Wi-Fi, estos modelos requieren una conexión activa a la infraestructura en la nube de su proveedor para un funcionamiento básico; sin acceso a Internet, simplemente no funcionarán. Antes de que una cámara pueda poner, debe emparejar con una cuenta de usuario registrada a través de la aplicación móvil oficial de Wansview y un proceso de configuración estándar basado en un código QR. Una vez que se complete este proceso, la cámara estará completamente en línea y operativa.

AJCloud: Una breve introducción

Aunque Wansview estuvo en funcionamiento desde 2009, por el momento parecen ser principalmente un revendedor de productos de cámara construidos por una compañía separada con sede en Nanjing, China: AJCloud.

AJCloud proporciona a los proveedores acceso a dispositivos de seguridad fabricados, el firmware necesario, aplicaciones de usuario móviles y de escritorio, la plataforma de gestión en la nube y servicios que conectan todo. Desde que se fundó AJCloud en 2018, se asociaron con varios proveedores, tanto grandes como pequeños, incluidos, entre otros, los siguientes:

Una revisión superficial de las aplicaciones móviles y de escritorio desarrolladas y publicadas por AJCloud en Google Play, la App Store de Apple y la Microsoft Store revela sus vínculos con cada uno de estos proveedores. Más allá de la marca superficial de la compañía, estas aplicaciones son idénticas en forma y función, y todas requieren conectividad con la plataforma de gestión AJCloud.

En cuanto a las cámaras, es evidente que estos proveedores están vendiendo modelos similares con solo pequeñas modificaciones en la carcasa de la cámara y el hardware subyacente.

El parecido entre el Faleemi 886 y el Wansview Q6 (1080p) es obvio

Es probable que la reutilización de los recursos de fabricación de hardware y desarrollo de software ayude a controlar los costos y simplificar la logística para AJCloud y sus revendedores. Sin embargo, esta racionalización de los activos también significa que las vulnerabilidades de seguridad descubiertas en un modelo de cámara probablemente permearían todos los productos asociados con AJCloud.

A pesar de su papel fundamental en llevar estos dispositivos a los consumidores, AJCloud tiene un perfil público relativamente bajo. Sin embargo, los investigadores de IPVM publicaron recientemente una investigación sobre una vulnerabilidad significativa (que ya fue resuelta) en el repositorio GitLab de AJCloud. Esta vulnerabilidad permitiría a cualquier usuario acceder al código fuente, credenciales, certificados y otros datos confidenciales sin necesidad de autenticación.

Aunque las cifras totales de ventas son difíciles de derivar para Wansview y otros proveedores en el espacio de cámaras Wi-Fi, IPVM estimó que al menos un millón de dispositivos estaban conectados a la plataforma AJCloud en el momento de la publicación de su reporte. A medida que las ventas de cámaras continúan aumentando a cientos de millones, es seguro asumir que más dispositivos de AJCloud estarán conectados en hogares de todo el mundo en los próximos años.

Esfuerzos iniciales de investigación de vulnerabilidades

Para obtener una comprensión más profunda de la postura de seguridad del Wansview Q5, lo atacamos desde múltiples ángulos:

Al principio, nuestros esfuerzos se centraron principalmente en el reconocimiento de red activo y pasivo de la cámara y la versión para Android de Wansview Cloud, la aplicación móvil oficial de Wansview. Escaneamos en busca de puertos abiertos, espiamos las comunicaciones de red a través de ataques de intermediario (MitM), intentamos forzar el comportamiento impredecible de las cámaras a través de una configuración incorrecta intencional en la aplicación e interrumpimos el funcionamiento de las cámaras abusando del formato de código QR e interactuando físicamente con la cámara. Los dispositivos y su infraestructura eran sorprendentemente resistentes a este tipo de ataques a nivel de superficie, y nuestros esfuerzos iniciales arrojaron pocos éxitos notables.

Nos sorprendió especialmente nuestra falta de éxito al interceptar las comunicaciones de red tanto en la cámara como en la aplicación. En repetidas ocasiones, nos encontramos con funciones de seguridad estables (por ejemplo, anclaje de certificados, restricciones de versiones de aplicaciones y sistemas operativos, y conexiones TLS debidamente protegidas) que interrumpieron nuestros intentos.

Las herramientas de ingeniería inversa nos permitieron analizar el APK mucho más de cerca, aunque la complejidad de la ofuscación del código observada dentro del código fuente de Java descompilado requeriría un periodo de tiempo prolongado para recomponerlo por completo.

Nuestro limitado éxito inicial nos obligaría a explorar más opciones que nos proporcionaran una visión más matizada del Q5 y de su funcionamiento.

Hackeo inicial de hardware

Para obtener más información sobre cómo funcionaba la cámara, decidimos echar un vistazo más de cerca al firmware de la cámara. Si bien algunos paquetes de firmware están disponibles en línea, queríamos echar un vistazo al código directamente y poder monitorearlo y los registros resultantes mientras la cámara estaba funcionando. Para hacer esto, primero echamos un vistazo al diagrama de hardware para el sistema en un chip (SoC) para ver si había alguna vía de hardware que pudiéramos aprovechar. El Wansview Q5 emplea un SoC Ingenic Xburst T31, su diagrama de bloques del sistema se muestra a continuación.

Una vía que nos llamó la atención fue el bloque de E/S SPI I2Cx3/UARTx2/SPIx2. Si son accesibles, estos bloques de E/S a menudo proporcionan interfaces de salida de registro y/o interfaces de shell, que se pueden usar para depurar e interactuar con el SoC. Parecía prometedor, luego realizamos un desmontaje de hardware de la cámara y encontramos lo que parecía ser una interfaz serie UART para el SoC, que se muestra a continuación.

A continuación, conectamos un analizador lógico para ver qué protocolo se estaba empleando sobre estos pines, y cuando se decodificaron, la señal era efectivamente UART.

Ahora que podemos acceder a una interfaz UART expuesta, buscamos establecer una conexión de shell con el SoC a través de UART. Hay un serial de diferentes mecanismos de software para hacer esto, pero para nuestros propósitos empleamos la utilidad Unix screen con la velocidad de transmisión detectada del analizador lógico.

Al abrir y monitorear la secuencia de arranque, descubrimos que el arranque seguro no estaba habilitado a pesar de ser compatible con el SoC. Luego procedimos a modificar la configuración para arrancar en modo de usuario único, proporcionando un shell raíz para que lo usemos para examinar el firmware antes de que se realicen los procesos de inicialización, que se muestran a continuación.

Una vez en el modo de usuario único, pudimos extraer los archivos de firmware para el análisis estático empleando la utilidad binwalk , como se muestra a continuación.

En esta etapa, el sistema de archivos es generalmente de solo lectura; Sin embargo, queríamos poder realizar ediciones e instanciar solo partes específicas de la inicialización del firmware según fuera necesario, por lo que hicimos algunas configuraciones rápidas para una persistencia adicional más allá del acceso en modo de usuario único. Esto se puede hacer de varias maneras, pero hay dos métodos principales que uno puede desear emplear. En términos generales, en ambos enfoques, se querrá realizar la menor cantidad posible de modificaciones en la configuración existente. Por lo general, se prefiere esto cuando se ejecuta un análisis dinámico si es posible, ya que tuvimos el menor impacto en el entorno de tiempo de ejecución. Un método que empleamos para este enfoque es crear una partición tmpfs para el acceso de lectura/escritura en la memoria y montarla a través de fstab. En nuestro caso, fstab ya se consideraba de tal manera que lo apoyaba y, como tal, lo convertía en un cambio mínimo. Consulte los comandos y resultados de este enfoque a continuación.

Otro método es extraer las credenciales de usuario existentes e intentar usarlas para iniciar sesión. Este enfoque también tuvo éxito. El hash de la contraseña para el usuario root se puede encontrar en el archivo etc/passwd y descifrar con una herramienta como John the Ripper. En nuestros ejemplos anteriores, estábamos transfiriendo datos y archivos completamente a través de la conexión en serial. La cámara también tiene una ranura para tarjetas SD disponible que se puede montar y usar para transferir archivos. En el futuro, usaremos la tarjeta SD o la red local para mover archivos, ya que el ancho de banda hace que la transferencia sea más rápida y fácil; Sin embargo, serial aún se puede usar para todas las comunicaciones para la configuración y depuración de hardware si se prefiere.

Ahora, tenemos acceso a nivel de root a la cámara que proporciona acceso al firmware y a los registros dmesg mientras se ejecuta el software. Empleando tanto el firmware como los registros como referencia, examinamos más a fondo las interfaces de usuario de la cámara para ver si había un buen punto de entrada que pudiéramos emplear para obtener más información.

Wansview Cloud para Windows

Después de que las aplicaciones móviles demostraron ser más seguras de lo que anticipamos originalmente, cambiamos nuestro enfoque a una versión anterior de la aplicación Wansview Cloud creada para Windows 7. Esta aplicación, que todavía está disponible para su descarga, nos proporcionaría una visión directa de las comunicaciones de red involucradas con las cámaras conectadas a la plataforma AJCloud.

Gracias en gran parte a un registro de depuración excesivamente indulgente en nombre de los desarrolladores, la aplicación de Windows derrama sus secretos con un abandono imprudente que rara vez se ve en el software comercial. La primera señal de que las cosas van mal es que las credenciales de inicio de sesión del usuario se registran en texto sin cifrar.

La ingeniería inversa del ejecutable principal y las DLL (que no están empaquetadas, a diferencia del APK de Wansview Cloud) se aceleró gracias al uso frecuente de mensajes de registro detallados que contienen cadenas únicas. La identificación de referencias a archivos y líneas específicos dentro de su base de código subyacente nos ayudó a mapear rápidamente los componentes principales de la aplicación y establecer el flujo de control de alto nivel.

Las comunicaciones de red, que eran difíciles de interceptar para nosotros en Android, todavía se transmiten a través de TLS, aunque se registran convenientemente en el disco en texto sin cifrar. Con acceso completo a todos los datos de solicitud y respuesta HTTP POST (que se empaquetan en objetos JSON), no hubo más necesidad de realizar ataques MitM en el lado de la aplicación.

Dentro de las respuestas de POST, encontramos metadatos confidenciales, incluidos enlaces a capturas de pantalla de acceso público junto con información sobre la ubicación de la cámara, la configuración de red y su versión de firmware.

Luego de documentar todas las solicitudes POST y las respuestas encontradas dentro de los datos de registro, comenzamos a experimentar con la manipulación de diferentes campos en cada solicitud en un intento de acceder a datos no asociados con nuestra cámara o cuenta. Eventualmente, emplearíamos un depurador para cambiar el deviceId al de una cámara de destino que no esté emparejada con la cuenta de inicio de sesión actual. Un deviceId de cámara también funciona como su número de serial y se puede encontrar impreso en una etiqueta adhesiva ubicada en la parte posterior o inferior de una cámara.

Encontramos el objetivo más apropiado para nuestro ataque en una sección de código donde el deviceId se transmite primero en una solicitud POST a https://sdc-us.ajcloud.net/api/v1/dev-config:

Nuestro plan era establecer un punto de interrupción en la instrucción resaltada en la captura de pantalla anterior, intercambiar el deviceId dentro de la memoria y, a continuación, permitir que la aplicación reanudara la ejecución.

Sorprendentemente, este enfoque ingenuo no solo funcionó para recuperar datos confidenciales almacenados en la plataforma AJCloud asociados con la cámara objetivo y la cuenta a la que está vinculada, sino que también nos conectó con la propia cámara. Esto nos permitió acceder a sus transmisiones de video y audio y controlarlo de forma remota a través de la aplicación como si fuera nuestra propia cámara.

A través de la explotación de esta vulnerabilidad y las pruebas con múltiples modelos de varios proveedores, determinamos que todos los dispositivos conectados a la plataforma AJCloud podían ser accedidos y controlados de forma remota de esta manera. Escribimos un script de exploit de PoC para automatizar este proceso y demostrar de manera efectiva la facilidad con la que esta vulnerabilidad de control de acceso dentro de la infraestructura de AJCloud se puede explotar de manera trivial.

Explorando las comunicaciones de red

Aunque pudimos crear y activar de manera confiable un exploit contra una vulnerabilidad crítica en la plataforma AJCloud, tendríamos que indagar más para comprender mejor el funcionamiento interno de las aplicaciones, el firmware de la cámara y la infraestructura en la nube.

A medida que exploramos más allá de las solicitudes POST y las respuestas observadas a lo largo del proceso de inicio de sesión, notamos una gran cantidad de solicitudes y respuestas UDP de una amplia variedad de IP. A lo largo de estas comunicaciones se pudieron encontrar pocos datos de texto plano discernibles, y los números de puerto UDP de destino para las solicitudes salientes parecían variar. Investigaciones posteriores revelarían que esta actividad UDP era indicativa de PPPP, un protocolo peer-to-peer (P2P) de IoT que fue analizado y demostrado ampliamente por Paul Marrapesse durante su presentación en DEF CON 28. Más tarde concluiríamos que la forma en que explotamos la vulnerabilidad que descubrimos se facilitó a través de solicitudes P2P modificadas, lo que nos llevó a explorar más a fondo el papel crítico que juega el P2P en la plataforma AJCloud.

El objetivo principal del P2P es facilitar la comunicación entre las aplicaciones y los dispositivos IoT, independientemente de las configuraciones de red involucradas. El P2P emplea principalmente un enfoque basado en la perforación de agujeros UDP para crear vías de comunicación temporales que permiten que las solicitudes lleguen a su objetivo, ya sea directamente o a través de un servidor de retransmisión ubicado en un entorno de red más accesible. El conjunto básico de comandos P2P integrados en las aplicaciones de AJCloud proporciona acceso a las transmisiones de video y audio, así como al micrófono y a la panorámica/inclinación/zoom.

Hacking de hardware avanzado

Con nuestro conocimiento adicional de las comunicaciones P2P, ahora era el momento de examinar la cámara más de cerca durante estas conversaciones P2P, incluida la ejecución del software de la cámara en un depurador. Para comenzar, configuramos la cámara con una salida de registro en tiempo real a través de la conexión serie UART que establecimos anteriormente, que se muestra a continuación.

Esto proporcionó una vista en tiempo real de los mensajes de registro de las aplicaciones, así como de cualquier fuente de registro adicional que necesitábamos. A partir de esta información, identificamos el binario principal que se emplea para establecer la comunicación entre la cámara y la nube, así como para proporcionar las interfaces para acceder a la cámara a través de P2P.

Este binario se denomina localmente initApp, y se ejecuta una vez que la cámara se inicializó completamente y se completó la secuencia de arranque. Teniendo en cuenta esto, nos propusimos ejecutar este binario con un depurador para evaluar mejor las funciones locales. Al intentar hacerlo, nos encontramos con un perro guardián del kernel que detectaba cuando initApp no se estaba ejecutando y forzaba el resetear de la cámara si detectaba un problema. Este perro guardián comprueba si hay escrituras en /dev/watchdog y, si estas escrituras cesan, activará un temporizador que resetear la cámara si las escrituras no se reanudan. Esto hace que la depuración sea más difícil, ya que cuando uno pausa la ejecución de initApp, las escrituras en el perro guardián también se detienen. A continuación se muestra un ejemplo de este comportamiento de detención:

Para evitar esto, simplemente se puede intentar escribir al guardián cada vez que initApp se detenga para evitar el resetear. Sin embargo, otra opción más limpia es hacer uso de la función de cierre mágico de la API del controlador de vigilancia del kernel de Linux. En resumen, si uno escribe un carácter mágico específico 'V' /dev/watchdog el perro guardián se desactivará. También hay otros métodos para derrotar al perro guardián, pero este fue el que elegimos para nuestra investigación, ya que facilita la activación y desactivación del perro guardián a voluntad.

Con el perro guardián deshabilitado, la configuración para depurar initApp es bastante sencilla. Queríamos ejecutar el código directamente en la cámara, si era posible, en lugar de usar un emulador. La arquitectura de la cámara es Little Endian MIPS (MIPSEL). Tuvimos la suerte de que los binarios GDB y GDBServer preconstruidos pudieran funcionar sin modificaciones; sin embargo, inicialmente no lo sabíamos, por lo que también configuramos una cadena de herramientas para compilar GDBServer específicamente para la cámara. Una técnica que podría ser útil si se encuentra en una situación similar es emplear una herramienta de compilación como gcc para compilar algún código fuente en su arquitectura de destino sospechosa y ver si se ejecuta; Vea el ejemplo a continuación.

En nuestro caso, dado que conocíamos nuestro SoC, estábamos bastante seguros de la arquitectura de destino; Sin embargo, en ciertas situaciones, esto puede no ser tan fácil de descubrir, y trabajar a partir de binarios de Hello World puede ser útil para establecer una comprensión inicial. Una vez que pudimos compilar binarios, compilamos GDBServer para nuestra cámara y luego lo usamos para anexar e iniciar initApp. Luego, nos conectamos a ella desde otra computadora en la misma red local que la cámara. A continuación se muestra un ejemplo de esto:

Como nota para el ejemplo anterior, estamos usando el parámetro -x para pasar algunos comandos por conveniencia, pero no son necesarios para la depuración. Para obtener más información sobre cualquiera de los archivos o comandos, consulte nuestro repositorio de GitHub elastic/camera-hacks . Para que initApp se cargara correctamente, también necesitábamos cerciorarnos de que las bibliotecas empleadas por el binario fueran accesibles a través de las variables de entorno PATH y LD_LIBARY_PATH . Con esta configuración, pudimos depurar el binario según lo necesitábamos. Dado que también usamos el método de personaje mágico para derrotar al perro guardián anteriormente, también tendremos que cerciorarnos de controlar las instancias en las que el perro guardián se puede volver a habilitar. En la mayoría de los casos, no queremos que esto suceda. Como tal, sobrscribimos las llamadas de guardián en initApp para que el guardián no se volviera a habilitar mientras depurábamos, como se muestra a continuación.

El siguiente video muestra el proceso de configuración completo desde el arranque hasta la ejecución de GDBServer. En el video, también iniciamos un nuevo proceso de initApp y, como tal, necesitamos matar tanto el proceso original como el script de shell daemon.sh que generará un nuevo proceso de initApp si se mata.

Creación de un cliente P2P

Con el fin de explorar más a fondo el alcance total de las capacidades que P2P proporciona a los dispositivos IoT de AJCloud y cómo los atacantes pueden abusar de ellas, nos propusimos construir nuestro propio cliente independiente. Este enfoque eliminaría la sobrecarga de manipular la aplicación Wansview Cloud para Windows, al tiempo que nos permitiría conectarnos más rápidamente a las cámaras y probar los comandos que derivamos de la ingeniería inversa del firmware.

A partir de los datos de configuración que obtuvimos anteriormente de los registros de aplicaciones de Windows, sabíamos que un cliente emite solicitudes a hasta tres servidores diferentes como parte del proceso de conexión. Estos servidores proporcionan instrucciones a los clientes sobre dónde se debe enrutar el tráfico para acceder a una cámara determinada. Si desea descubrir más de estos servidores al aire libre, puede escanear Internet empleando la siguiente carga útil UDP de cuatro bytes en el puerto 60722. Paul Marrapese empleó esta técnica con gran efecto como parte de su investigación.

Para establecer correctamente una conexión P2P, un cliente primero debe enviar un mensaje de saludo simple (MSG_HELLO), que debe ser ACK'd (MSG_HELLO_ACK) por un servidor peer-to-peer. A continuación, el cliente consulta al servidor (MSG_P2P_REQ) un deviceId determinado. Si el servidor es consciente de ese dispositivo, responderá (MSG_PUNCH_TO) al cliente con una dirección IP de destino y un par de números de puerto UDP. A continuación, el cliente intentará conectarse (MSG_PUNCH_PKT) a la IP y al par de puertos junto con otros puertos dentro de un rango predeterminado como parte de una rutina de perforación de agujeros UDP . Si tiene éxito, el objetivo enviará un mensaje (MSG_PUNCH_PKT) al cliente junto con un mensaje final (MSG_P2P_RDY) para confirmar que se estableció la conexión.

Luego de conectarnos a una cámara, lo que más nos interesa es enviar diferentes paquetes de MSG_DRW y observar su comportamiento. Estos paquetes contienen comandos que nos permitirán manipular físicamente la cámara, ver y escuchar sus flujos de video y audio, acceder a los datos almacenados en ella o alterar su configuración. El comando más sencillo con el que comenzamos consistía en desplazar la cámara en sentido contrario a las agujas del reloj, lo que pudimos identificar fácilmente como una transmisión de un solo mensaje.

Los mensajes de registro de depuración en la cámara nos permitieron localizar fácilmente dónde se procesó este comando dentro del firmware.

Localizar el origen de este mensaje en individuo nos colocó en la rutina principal que maneja el procesamiento de mensajes MSG_DRW, lo que nos proporcionó información crítica sobre cómo se invoca este comando y qué otros comandos son compatibles con el firmware.

La ingeniería inversa y las pruebas exhaustivas nos permitieron crear un cliente PoC P2P que permite a los usuarios conectarse a cualquier cámara en la plataforma AJCloud, siempre que tengan acceso a su deviceId. Los comandos básicos compatibles con el cliente incluyen el movimiento panorámico y la inclinación de la cámara, el resetear, el resetear, la reproducción de clips de audio e incluso el bloqueo del firmware.

La capacidad más peligrosa que pudimos implementar fue a través de un comando que modifica un archivo de configuración de dispositivo central: /var/syscfg/config_default/app_ajy_sn.ini. En nuestra cámara de prueba, el contenido del archivo era originalmente el siguiente:

[common]
product_name=Q5
model=NAV
vendor=WVC
serialnum=WVCD7HUJWJNXEKXF
macaddress=
wifimacaddress=

Si bien esto parece contener metadatos básicos del dispositivo, este archivo es el único medio a través del cual la cámara sabe cómo identificar. Al iniciar, la cámara lee el contenido de este archivo y luego intenta conectarse a la plataforma AJCloud a través de un serial de solicitudes curl a varios puntos finales de API. Estas solicitudes curl pasan el nombre del producto, el modelo de cámara, el código de proveedor y los valores del número de serial extraídos del archivo INI como argumentos de cadena de consulta. Usamos nuestro cliente para entregar un mensaje que sobreescribir el contenido de la siguiente manera:

[common]
product_name=
model=OPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~HH01
vendor=YZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~HH01
serialnum=defghijklmnopqrstuvwxyz{|}~HH01
macaddress=
wifimacaddress=

Luego de restablecer la cámara, todas las solicitudes curl emitidas a los puntos finales de la API de la plataforma AJCloud como parte de la rutina de inicio fallarán debido a los datos con formato incorrecto contenidos en el archivo INI. Estas solicitudes se seguirán enviando periódicamente, pero nunca tendrán éxito y la cámara permanecerá inactiva e inaccesible a través de cualquier aplicación. Desafortunadamente, no existe una forma sencilla de restaurar el contenido del archivo anterior mediante el restablecimiento de la cámara, la actualización de su firmware o la restauración de la configuración de fábrica. Las modificaciones de archivos llevadas a cabo a través de este comando bloquearán efectivamente una cámara y la inutilizarán.

Echando un vistazo más de cerca a la función descompilada (syscfg_setAjySnParams) que sobreescribir los valores almacenados en app_ajy_sn.ini, podemos ver que los parámetros de entrada, extraídos del comando MSG_DRW , se emplean para pasar datos de cadena que se emplearán para sobreescribir los campos de modelo, proveedor y número de serial en el archivo. memset se emplea para sobreescribir tres variables globales, destinadas a almacenar estas cadenas de entrada, con bytes nulos. A continuación, strcpy se emplea para transferir los parámetros de entrada a estos globales. En cada caso, esto dará como resultado que los bytes se copien directamente desde el búfer de comandos de MSG_DRW hasta que encuentre un carácter nulo.

Debido a que no se aplica ninguna validación sobre la longitud de estos parámetros de entrada extraídos del comando, es trivial crear un mensaje de longitud suficiente que desencadene un desbordamiento de búfer. Si bien no aprovechamos esta vulnerabilidad como parte de nuestro ataque para bloquear la cámara, esta parece ser una instancia en la que se podría desarrollar un exploit que permitiría a un atacante lograr la ejecución remota de código en la cámara.

Impacto

Confirmamos que una amplia gama de dispositivos de varios proveedores convertidos en miembro a AJCloud y varias versiones de firmware diferentes se ven afectados por estas vulnerabilidades y fallas. En general, demostramos con éxito nuestros ataques contra quince productos de cámara diferentes de Wansview, Galayou, Cinnado y Faleemi. Basándonos en nuestros hallazgos, es seguro asumir que todos los dispositivos que operan el firmware de AJCloud y se conectan a la plataforma AJCloud se ven afectados.

Todos los intentos de poner en contacto tanto con AJCloud como con Wansview para revelar estas vulnerabilidades y fallos fueron infructuosos.

¿Qué hicieron bien los vendedores?

A pesar de las vulnerabilidades que descubrimos y discutimos anteriormente, hay un serial de controles de seguridad que AJCloud y los proveedores de cámaras implementaron bien. Para un dispositivo de tan bajo costo, se implementaron muchas de las mejores prácticas. En primer lugar, las comunicaciones de red están bien protegidas mediante la autenticación WebSocket basada en certificados. Además de agregar cifrado, colocar muchos de los puntos finales de la API detrás de la autenticación del certificado hace que los ataques de intermediario sean significativamente más desafiantes. Además, los APK de las aplicaciones móviles estaban firmados y ofuscados, lo que hacía que la manipulación de estas aplicaciones llevara mucho tiempo.

Además, los proveedores también tomaron algunas decisiones acertadas con el hardware y el firmware de la cámara. El sistema operativo local de la cámara es efectivamente limitado, centrar solo en la funcionalidad necesaria para su producto. El sistema de archivos está configurado para ser de solo lectura, fuera del registro, y el guardián del kernel es un método eficaz para garantizar el tiempo de actividad y reducir el riesgo de quedar atascado en un estado de error. El SoC Ingenic Xburst T31 proporciona una plataforma capaz con una amplia gama de soporte, incluido el arranque seguro, un perro guardián de Restablecimiento de encendido (POR) y un procesador RISC-V separado capaz de ejecutar un aprendizaje automático rudimentario en la entrada de la cámara.

¿Qué hicieron mal los vendedores?

Desafortunadamente, hubo un serial de oportunidades perdidas con estas funciones disponibles. Potencialmente, el más atroz es el acceso a la nube no autenticado. Dados los controles de acceso a la API establecidos para muchos de los endpoints, tener el acceso del usuario de la cámara a los endpoints disponible a través del número de serial sin autenticación es un paso en falso enorme y evitable. El protocolo P2P también es vulnerable, como mostramos, pero en comparación con el acceso a la API, que debería poder solucionar de inmediato, puede llevar más tiempo arreglar el protocolo. Es una vulnerabilidad muy peligrosa, pero es un poco más comprensible, ya que requiere una inversión de tiempo considerablemente mayor tanto para descubrirla como para corregirla.

Desde el lado de la aplicación, el problema principal es con la aplicación de Windows que tiene un extenso registro de depuración que debería haber eliminado antes de lanzarlo públicamente. En cuanto al hardware, se puede manipular fácilmente con acceso físico (botón de resetear expuesto, etc.). Esto no es tanto un problema dado el público consumidor objetivo. Se espera que se equivoque por el lado de la usabilidad en lugar de la seguridad, especialmente dado el acceso físico al dispositivo. Del mismo modo, el arranque seguro debería estar habilitado, especialmente dado que el SoC T31 lo admite. Si bien no es estrictamente necesario, esto haría que sea mucho más difícil depurar el código fuente y el firmware del dispositivo directamente, lo que dificultaría el descubrimiento de vulnerabilidades que puedan estar presentes. Idealmente, se implementaría de tal manera que el cargador de arranque aún pudiera cargar un sistema operativo sin firmar para permitir ajustes y desarrollo más fáciles, pero evitaría que el sistema operativo firmado se cargue hasta que se restaure la configuración del cargador de arranque. Sin embargo, una falla importante en el firmware actual es la dependencia del número de serial original que no se almacena en un punto de montaje de solo lectura mientras el sistema está funcionando. La manipulación del número de serial no debería bloquear permanentemente el dispositivo. Debe tener un mecanismo para aplicar un nuevo número de serial (o restaurar su número de serial original) en caso de que se sobreescribir su número de serial, o el número de serial debe ser inmutable.

Mitigaciones

Se pueden tomar ciertas medidas para reducir la superficie de ataque y limitar los posibles efectos adversos en caso de un ataque, aunque varían en su efectividad.

Segmentar las cámaras Wi-Fi y otros dispositivos IoT del resto de la red es una contramedida muy recomendable que evitará que los atacantes volteen lateralmente hacia sistemas más críticos. Sin embargo, este enfoque no evita que un atacante obtenga datos confidenciales del usuario mediante la explotación de la vulnerabilidad de control de acceso que descubrimos en la plataforma AJCloud. Además, teniendo en cuenta la facilidad con la que pudimos demostrar cómo se podía acceder a las cámaras y manipularlas de forma remota a través de P2P, cualquier dispositivo conectado a la plataforma AJCloud todavía corre un riesgo significativo de ver comprometido, independientemente de su configuración de red local.

Restringir todas las comunicaciones de red hacia y desde estas cámaras no sería factible debido a lo esencial que es la conectividad a la plataforma AJCloud para su funcionamiento. Como se mencionó anteriormente, los dispositivos simplemente no funcionarán si no pueden conectarse a varios puntos finales de API al iniciar.

Un enfoque viable podría ser restringir las comunicaciones más allá de la rutina de inicio inicial. Sin embargo, esto impediría el acceso y el control remotos a través de aplicaciones móviles y de escritorio, lo que frustraría todo el propósito de estas cámaras en primer lugar. Para obtener más información sobre esta área, consulte "Bloqueo sin interrupción: identificación y mitigación del tráfico de IoT no esencial", que exploró este enfoque más en profundidad en una gran cantidad de dispositivos y proveedores de IoT.

El mejor enfoque para proteger cualquier cámara Wi-Fi, independientemente del proveedor, mientras se mantiene la funcionalidad principal sería flashearla con un firmware alternativo de código abierto como OpenIPC o thingino. El cambio a firmware de código abierto evita los dolores de cabeza asociados con la conectividad forzada a las plataformas en la nube de los proveedores, ya que proporciona a los usuarios un control detallado de la configuración del dispositivo y la accesibilidad remota a la red. El acceso abierto a la fuente del firmware ayuda a garantizar que los fallos y vulnerabilidades críticas sean identificados y parcheados rápidamente por los diligentes colaboradores del proyecto.

Conclusiones clave

Nuestra investigación reveló varias vulnerabilidades críticas que abarcan todos los aspectos de las cámaras que operan con el firmware de AJCloud y que están conectadas a su plataforma. Fallos significativos en la gestión del control de acceso en su plataforma y el protocolo PPPP peer proporciona una superficie de ataque expansiva que afecta a millones de dispositivos activos en todo el mundo. La explotación de estos fallos y vulnerabilidades conduce a la exposición de datos confidenciales de los usuarios y proporciona a los atacantes un control remoto completo de cualquier cámara conectada a la plataforma AJCloud. Además, un comando P2P incorporado, que proporciona intencionalmente acceso de escritura arbitrario a un archivo de configuración de claves, se puede aprovechar para deshabilitar permanentemente las cámaras o facilitar la ejecución remota de código mediante la activación de un desbordamiento de búfer.

Visite nuestro repositorio de GitHub para ver las herramientas y scripts personalizados que creamos junto con los datos y las notas que capturamos y que, en nuestra opinión, proporcionarían el mayor beneficio a la comunidad de investigación de seguridad.

Tormenta en el horizonte: dentro del ecosistema IoT de AJCloud