Como parte de esta investigación, los investigadores de VDOO encontraron vulnerabilidades de día cero en dispositivos de varios proveedores. Estas vulnerabilidades se revelaron a los proveedores, de acuerdo con las mejores prácticas de divulgación responsable, y se compartirán gradualmente después de que concluyan los períodos de divulgación.

Uno de los proveedores para los que encontramos dispositivos vulnerables fue Hikvision. Nuestro equipo descubrió una vulnerabilidad en las cámaras de seguridad Hikvision. Al explotar la vulnerabilidad descubierta, un adversario que obtiene con éxito la dirección IP de la cámara puede ejecutar el código de forma remota con privilegios de root en la cámara (a través de LAN o Internet). VDOO ha divulgado esta vulnerabilidad (CVE-2018-6414) y se ha comprometido con el equipo de seguridad de Hikvision para resolver el problema.

Según nuestro conocimiento, esta vulnerabilidad no se explotó en el campo y, por lo tanto, no generó ninguna violación concreta de la privacidad o amenaza de seguridad para los clientes de Hikvision. El equipo de Hikvision actuó rápidamente para parchear esta vulnerabilidad e impulsar la versión parcheada a los productos vulnerables.

Resumen Técnico

La cámara ejecuta un sistema operativo Linux. El proceso de davinci incluye muchas de las funcionalidades de la cámara, incluido el servidor web, y se ejecuta con privilegios de identificación de usuario 0 (la identificación de usuario se denomina "admin", pero efectivamente otorga privilegios de raíz ya que el uid es 0). La interfaz web de la cámara se basa en el servidor web de Embebthis appweb 3 con algún código agregado por Hikvision. El servidor web tiene algunas páginas especiales para controlar la configuración de la cámara, que fueron agregadas por Hikvision. Por lo general, estas páginas especiales solo se ejecutan después de la autenticación HTTP, pero algunas de ellas no requieren autenticación.

En el código que atiende una solicitud a una de las páginas que no necesita autenticación HTTP, hay una llamada no segura a sscanf que puede, al usar una solicitud especialmente diseñada, conducir a un desbordamiento de búfer, que a su vez puede Corrompe la memoria y conduzca a la ejecución de código arbitrario o bloquee el proceso.

Inmersión técnica

Esta vulnerabilidad permite que un adversario ejecute un fragmento de código de su elección en el firmware de la cámara.

Cuando un usuario inicia sesión utilizando la página web de inicio de sesión, se envía una solicitud POST que también puede contener parámetros GET.

En el código que analiza un parámetro GET específico, hay una llamada a __isoc99_sscanf. La función__isoc99_sscanf se comporta como la función scanf conocida, pero en lugar de leer su entrada desde la entrada estándar, obtiene la entrada de una cadena. En este caso, la entrada es la cadena que contiene la cadena de consulta de la solicitud:

La cadena de formato de la función se compone del nombre del parámetro, seguido de "=% s". Esto significa que la función espera que la cadena comience con el nombre del parámetro seguido de "=", y luego lee cualquier cadena después de eso en una variable basada en la pila llamada "s1" en la figura anterior. Esto nos permite escribir tantos bytes como queramos en la pila, ya que no hay límite en el% s. El único límite que existe es el límite que el servidor web aplica a todo el URI, incluida la cadena de consulta.

El límite del servidor web se aplica primero, antes de que ocurra cualquiera de la lógica detrás de las páginas, como se ve en el código fuente de appweb 3 (como se puede ver en github: https://github.com/embedthis/appweb-3/blob /master/src/http/request.c):

El valor que la cámara Hikvision asigna a maxUrl se puede encontrar mirando las funciones relevantes:

Cuando se compara el pseudocódigo con el código original, es fácil comprender que “v3 [52]” significa límites de conn->http->limits, y que el valor está en el desplazamiento 48. Cuando se encuentra la función que inicializa los valores Veremos que el valor se establece en 0x400 (que es diferente de los valores que se encuentran en el código fuente original de la aplicación 3):

Al restar la longitud del URI con las variables GET de 0x400, obtenemos el límite de la carga útil que se puede usar en el valor de la variable. Aún necesitamos restar un byte más de este valor, ya que también se verifica la igualdad de la URI. Ahora, podemos comprobar qué podemos hacer con los bytes disponibles.

Volviendo a la función vulnerable, observaremos el marco de la pila y comprobaremos el desplazamiento de la variable "s1" en él. En este firmware específico, la variable se encuentra en un desplazamiento lo suficientemente cerca del comienzo de la pila, lo que significa que podemos desbordar hasta el comienzo del marco de pila. Sin embargo, en algunas de las otras versiones de firmware que verificamos, la variable estaba ubicada en direcciones inferiores en la pila y eso no nos permitiría llegar hasta el principio del marco de pila. En tales casos, la vulnerabilidad aún puede ser parcialmente explotable al sobrescribir las variables que residen en el marco de la pila.

Como la dirección de retorno a la función de llamada se encuentra al comienzo del marco de pila, al sobrescribirla, podemos controlar qué código se ejecutará a continuación (cuando nuestra función regrese).

Dado que el ataque se basa en un especificador de formato sscanf% s, no podemos utilizar espacios en blanco en nuestro ataque ni caracteres NULL. Este hecho nos limita, ya que todas las direcciones en la sección de códigos comienzan con un byte NULO. Sin embargo, utilizamos técnicas comúnmente conocidas para superar esta limitación.

Una cosa importante que ayuda a aprovechar esta vulnerabilidad es el hecho de que mientras ASLR está en uso para las bibliotecas compartidas cargadas, no está en uso para el binario principal del firmware. Por lo tanto, es posible saber exactamente dónde reside el código, lo que nos permite saltar a un fragmento de código de nuestra elección. También podemos ver que no se utilizan los canarios de pila, lo que significa que podemos sobrescribir con seguridad el contenido de la pila sin que se haya revisado.

Después de tener todo eso, tenemos que elegir una dirección para saltar. Como ejemplo, de manera similar al Foscam PoC, elegimos saltar a un fragmento de código que restablece las credenciales del dispositivo, lo que nos permite iniciar sesión en el dispositivo como administrador. Luego, como administradores de dispositivos, podemos controlar cualquier configuración, incluida la capacidad de actualizar el dispositivo con un firmware personalizado.

PoC

Dado el riesgo que presenta esta vulnerabilidad, decidimos no publicar un PoC para proteger a los usuarios que no han actualizado sus dispositivos de ataques malintencionados.