¿Qué tan segura es tu cámara de "seguridad"?

Resumen ejecutivo

A principios de 2020, en mi antiguo lugar de trabajo, tuve la oportunidad de participar en un evento interno estilo pwn2own. Había varios objetivos disponibles, pero el que más me interesaba era la cámara de seguridad inalámbrica Accfly. Desafortunadamente, no pude terminar mi investigación para el evento en sí, pero como no hubo otros intentos con este dispositivo, continué con ella.

El enfoque principal de la investigación fueron las vulnerabilidades que podrían llevar a la ejecución remota de código (RCE). Este tipo de vulnerabilidad permite a un atacante tomar el control total del dispositivo y, en el caso de una cámara de video, puede resultar en un compromiso completo de la privacidad del propietario. Desafortunadamente, se descubrió que el firmware del dispositivo está plagado de estos problemas.

Primero, el dispositivo no proporciona ninguna autenticación. Como resultado, un atacante capaz de conectarse a él puede acceder y reconfigurarlo libremente. En la forma más simple, es posible reiniciar continuamente el dispositivo, volviéndolo completamente inutilizable para el usuario legítimo. El alcance de este ataque está ligeramente limitado ya que el dispositivo está diseñado para usarse dentro de una red WiFi, generalmente detrás de NAT, por lo tanto no es directamente accesible desde Internet. Sin embargo, la falta de cifrado entre el dispositivo y la aplicación móvil de su propietario, junto con el uso del servidor del fabricante como proxy para la comunicación, crea una oportunidad para un ataque MitM o de manipulación de DNS, que puede romper la restricción de NAT de la WiFi.

Además, la aplicación utiliza un protocolo binario propietario para la comunicación. Se ha implementado en una mezcla de C y C++ y se ha descubierto que está lleno de funciones de manejo de cadenas inseguras. El ejecutable principal contiene una gran cantidad de código no utilizado, lo que sugiere que se reutiliza en otros dispositivos. Esto dificulta el mantenimiento y aumenta la superficie de ataque. La aplicación no habilita ningún mecanismo de seguridad moderno que la proteja contra muchas técnicas de explotación comunes. Además, ni siquiera limita los permisos de usuario, ejecutándose como root, con los privilegios más altos disponibles.

Como resultado de esta investigación, se han documentado las siguientes cuatro vulnerabilidades:

• CVE-2020-25782 - Desbordamiento de búfer basado en pila no autenticado en la función CNetClientManage::ServerIP_Proto_Set al manejar mensajes entrantes
• CVE-2020-25783 - Desbordamiento de búfer basado en montón no autenticado en la función CNetClientTalk::OprMsg al manejar mensajes entrantes
• CVE-2020-25784 - Desbordamiento de búfer basado en pila no autenticado en la función CNetClientGuard::SubOprMsg al manejar mensajes entrantes
• CVE-2020-25785 - Desbordamiento de búfer basado en pila no autenticado en la función CFtpProtocol::FtpLogin durante el procedimiento de actualización

Para tres de ellas se desarrollaron exploits de RCE, que permiten a un atacante obtener el control completo del dispositivo. Sin embargo, debido a la falta de respuesta del fabricante a los intentos de reporte de vulnerabilidades, este repositorio contiene solo exploits PoC limitados, que simplemente hacen fallar la aplicación.

Los problemas se encontraron en la versión de software V3.10.73 y se verificaron en la versión de software V4.15.77, la última disponible en el momento de esta publicación (26 de enero de 2021).

En caso de cualquier pregunta, no dudes en contactarme por correo electrónico (ver git commit) o a través de los issues de Github. Si tienes un dispositivo IoT que crees que podría ser interesante de hackear, estás buscando un Investigador de Seguridad o simplemente quieres saludar, estaré encantado de saber de ti. También puedes invitarme un café!

Introducción

El dispositivo objetivo es una cámara de video, que se controla desde la aplicación móvil acompañante. Mi análisis comenzó con el tráfico de red de la cámara y continuó hacia el firmware de la cámara. Se utiliza un protocolo binario personalizado para toda la comunicación. Los comandos se envían directamente al dispositivo móvil cuando están en la misma red o pasan a través del servidor del fabricante del dispositivo. El software de la cámara escucha en múltiples puertos TCP (23456,34567) y UDP (34568, 34569). No hay cifrado ni autenticación para el tráfico de red, lo que permite ataques MitM o acceso directo cuando la cámara está expuesta en la red. Parece probable que el acceso a la transmisión de video también sea posible sin autenticación, pero no he realizado suficiente ingeniería inversa del protocolo propietario para probarlo.

Después de una breve descripción general de la comunicación, el siguiente paso fue intentar acceder al firmware del dispositivo. Mi primer intento fue descargarlo directamente secuestrando el proceso de actualización del dispositivo, pero no ocurrió nada similar en el tráfico de red. Me habría quedado estancado en esta etapa, si no fuera por la muy necesaria ayuda de un colega que extrajo el firmware de la memoria flash, lo que me permitió continuar con esta investigación.

Se descubrió que el firmware ejecuta Linux en una CPU MIPS little-endian. Hay exactamente un proceso interesante, llamado Alloca, que es responsable de la captura de video y también maneja todas las comunicaciones de red. La aplicación está creada en C++ y contiene mucho código que no se utiliza en este dispositivo. Esto indica que el mismo software se utiliza en diferentes dispositivos también.

La fuga

Aunque este problema se encontró al final, es crucial para la explotación real de la mayoría de los demás, porque se derivan del uso de funciones de cadena inseguras del lenguaje C. Si bien existen varias técnicas que se pueden utilizar para una ejecución de código exitosa en escenarios similares, la aplicación está creada de tal manera que resultan mayormente inútiles. El problema principal es que el código y los datos de Alloca se asignan estáticamente en direcciones bajas ( <&nbsp;0x01000000). Por lo tanto, los intentos de reutilizar código existente (es decir, ROP y similares) no son útiles, ya que requieren la capacidad de escribir direcciones en la memoria del programa. Debido a que las cadenas en C usan \x00 como carácter de terminación, y las funciones de cadena finalizan el procesamiento en el primer byte de este tipo, no es posible usar más de un solo byte NULL. Además, la ubicación de la pila está aleatorizada y la aplicación tiene múltiples hilos de ejecución, lo que hace que otras técnicas sean mucho menos confiables.

Esta vulnerabilidad es el resultado de compartir datos entre múltiples hilos y el uso inseguro de strcpy. Si bien he analizado este problema en particular durante mucho tiempo, no había visto la oportunidad de usarlo como vector de fuga de datos hasta solo unas pocas semanas antes de esta publicación. Curiosamente, gracias a la fuga de la dirección del montón de un objeto C++, esta vulnerabilidad también permite la ejecución remota de código. Sin embargo, este ataque no está incluido en este informe.