.st0{fill:#FFFFFF;}

Riesgo al usar UPNP en cámaras y NVRs de Hikvision 

 enero 25, 2021

Por  Felipe Arguello4708

Las cámaras y NVRs Hikvision pueden usar UPNP (Universal Plug ‘n’ Play) para configurar rápida, fácil, automáticamente la asignación y reenvío de puertos en su enrutador de oficina / hogar para facilitar el acceso remoto a sus cámaras HikVision.  Esta función  también debe estar habilitado en su enrutador (pero a menudo es por defecto).

Desafortunadamente, esto puede presentar un riesgo de acceso remoto no deseado. Los puertos que se reenvían son bien conocidos, y UPNP en realidad reenvía o abre más puertos que hasta ahora no ha sido claro (cinco en lugar de los tres declarados en la imagen de este artículo).

HikVision actualizó su firmware para reparar el acceso de puerta trasera en mayo de 2017 (V5.4.5).

Desde la versión de firmware de Hikvision V5.5.0 en adelante UPNP está deshabilitado de forma predeterminada, es decir, si desea utilizarlo, debe habilitarlo a sabiendas.

Vulnerabilidad UPNP en cámaras y NVRs Hikvision

Desafortunadamente, si actualiza desde una versión inferior a la V5.5.0, donde UPNP estaba activado de manera predeterminada, la actualización del firmware no la desactiva (permanece en el valor predeterminado anterior – configurado en upnp habilitado).

Por lo tanto, potencialmente, incluso si creía que no había reenviado intencionalmente sus cámaras para el acceso remoto a Internet, es posible que hayan utilizado upnp y configurado automáticamente su enrutador para reenviar puertos y permitir el acceso externo a las cámaras.

En las versiones de firmware más bajas, antes de V5.4.5, esta capacidad de encontrar cámaras combinadas con la contraseña de puerta trasera dejaba a muchos dispositivos vulnerables, y muchos fueron pirateados.

Por lo tanto, si no desea habilitar el acceso remoto a sus cámaras, desactive el upnp (captura de pantalla a continuación).

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 usando 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 stdin , obtiene la entrada de una cadena. En este caso, la entrada es la cadena que contiene la cadena de consulta de la solicitud:

Captura de pantalla de Hikvision IDA

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 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 % 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 suceda 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 ):

código fuente de appweb 3

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

Valor macurl de la cámara Hikvision

Al comparar el pseudocódigo con el código original, es fácil comprender que «v3 [52]» significa conn-> http-> limits, y que el valor está en el desplazamiento 48. Al encontrar 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 appweb 3):

Código de Hikvision

Al restar la longitud del URI con las variables GET de 0x400, obtenemos el límite de la carga útil que es posible usar en el valor de la variable. Todavía necesitamos restar un byte más de este valor, ya que la longitud del URI también se verifica para verificar la igualdad. 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 está ubicada en un desplazamiento lo suficientemente cerca del comienzo de la pila, lo que significa que podemos desbordar hasta el comienzo del marco de la pila. Sin embargo, en algunas de las otras versiones de firmware que verificamos, la variable estaba ubicada en direcciones más bajas en la pila y eso no nos permitiría llegar hasta el principio del marco de la pila. En tales casos, la vulnerabilidad aún puede aprovecharse parcialmente sobrescribiendo las variables que residen en el marco de la pila.

Dado que la dirección de retorno a la función que llama se encuentra al principio del marco de la 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 % s sscanf, no podemos usar espacios en blanco en nuestro ataque ni caracteres NULL. Este hecho nos limita, ya que todas las direcciones en la sección de código comienzan con un byte NULL. Sin embargo, utilizamos técnicas comúnmente conocidas para superar esta limitación.

Una cosa importante que ayuda a explotar 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 una pieza de código de nuestra elección. También podemos ver que no se utilizan canarios de pila, lo que significa que podemos sobrescribir de forma segura el contenido de la pila sin que se compruebe nunca.

Después de tener todo eso, debemos elegir una dirección a la que saltar. Como ejemplo, de manera similar a 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 del dispositivo, podemos controlar cualquier configuración, incluida la capacidad de actualizar el dispositivo con firmware personalizado.

Publicamos esto con cierta inquietud, sé que probablemente van a preocuparse y tendrán varias preguntas o consultas.

El acceso de Hik-Connect habilitará upnp y lo usará para reenviar puertos automáticamente; eso está bien si está utilizando el último firmware y, por lo tanto, ha impedido el uso de la contraseña de puerta trasera para obtener el control de su contraseña.

Si no está seguro de cómo se configuró su acceso remoto, haga una captura de pantalla de su configuración antes de desactivar upnp (ya que los números de puerto probablemente sean diferentes para cada cámara si tiene múltiples dispositivos configurados para acceso remoto).

Fuente: VDOO

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}
>