Más de 390 cámaras Axis con vulnerabilidades

Más de 390 cámaras Axis han sido encontradas con vulnerabilidades significativas.

Durante los últimos meses, los equipos de investigación de seguridad de VDOO han llevado a cabo una investigación de seguridad a gran escala de los principales productos de IoT, desde los campos de la seguridad. 

En la mayoría de los casos, la investigación se llevó a cabo junto con los proveedores de dispositivos en aras de la eficiencia y la transparencia. Como parte de esta investigación, los investigadores de VDOO encontraron vulnerabilidades de día cero en los dispositivos de varios proveedores.

Estas vulnerabilidades se divulgaron a los proveedores, de conformidad con las mejores prácticas de divulgación responsable ( Reportes CVE), y se compartirán gradualmente después de que los períodos de divulgación hayan concluido.

Uno de los proveedores para los que encontramos dispositivos vulnerables era Axis Communications.

Cuáles son las vulnerabilidades encontradas en  las cámaras Axis

Nuestro equipo descubrió una cadena crítica de vulnerabilidades en las cámaras Axis. Las vulnerabilidades permiten a un adversario que obtuvo la dirección IP de la cámara tomar control remoto de las cámaras (a través de LAN o Internet). En total, VDOO ha revelado responsablemente siete vulnerabilidades al equipo de seguridad de Axis.

Los ID de las vulnerabilidades son:  CVE-2018-10658 ,  CVE-2018-10659 ,  CVE-2018-10660 ,  CVE-2018-10661 ,  CVE-2018-10662 ,  CVE-2018-10663  y  CVE-2018-10664 .

Encadenando tres de las vulnerabilidades informadas juntas, permite a un atacante remoto no autenticado que tiene acceso a la página de inicio de sesión de la cámara a través de la red (sin acceso previo a la cámara o credenciales a la cámara) controlar completamente la cámara afectada. Un atacante con dicho control podría hacer lo siguiente:

• Acceso a la transmisión de video de la cámara
• Congelar la transmisión de video de la cámara
• Controle la cámara – mueva la lente al punto deseado, active / desactive la detección de movimiento
• Agrega la cámara a una botnet
• Alterar el software de la cámara
• Use la cámara como un punto de infiltración para la red (realizando movimientos laterales)
• Renderiza la cámara inútil
• Usa la cámara para realizar otras tareas infames (ataques DDoS, minería Bitcoin, otras)

Los productos vulnerables incluyen 390 modelos de cámaras Axis IP. La lista completa de productos afectados se puede encontrar aquí . Axis usa el identificador ACV-128401 para relacionarse con los problemas que descubrimos.

Hasta donde sabemos, estas vulnerabilidades no se explotaron en el campo y, por lo tanto, no condujeron a ninguna violación concreta de la privacidad ni a una amenaza a la seguridad de los clientes de Axis.

Recomendamos encarecidamente a los clientes de Axis que no actualizaron el firmware de su cámara que lo hagan inmediatamente o que mitiguen los riesgos de formas alternativas. Vea las instrucciones en la sección de preguntas frecuentes a continuación.

También recomendamos que otros proveedores de cámaras sigan nuestras recomendaciones al final de este informe para evitar y mitigar amenazas similares.

Acerca de VDOO

VDOO es una empresa impulsada por la tecnología que se esfuerza por cambiar la realidad de los dispositivos conectados sin protección. VDOO está construyendo una línea de productos para ayudar a los fabricantes de dispositivos a integrar la seguridad en sus dispositivos conectados en la etapa de desarrollo y habilitar la seguridad posterior al desarrollo.

Además de desarrollar productos y servicios, VDOO invierte esfuerzos significativos en una amplia investigación de dispositivos conectados. Las cámaras de seguridad son un área de enfoque de esta investigación.

El objetivo de investigación de VDOO es aportar conocimiento y herramientas para mitigar los riesgos, así como alentar a los fabricantes de los dispositivos a implementar la seguridad adecuada para sus productos. En VDOO creemos que una implementación adecuada de los elementos esenciales de seguridad disminuirá drásticamente las posibilidades de aprovechar vulnerabilidades en el dispositivo.

Este es el segundo informe de nuestra serie de investigaciones centradas en equipos de videovigilancia.

El primer informe, que se centra en los equipos Foscam, está disponible aquí . Para obtener más detalles sobre nuestro enfoque de investigación, haga clic aquí .

Resumen técnico

Las cámaras Axis funcionan con un sistema operativo Linux y la interfaz web de la cámara se basa en el servidor web Apache httpd con módulos patentados desarrollados por Axis.

El acceso a los archivos en el directorio raíz del servidor web se rige por el código de autorización personalizado de Axis dentro del módulo mod_authz_axisgroupfile.so.

Al usar un módulo propietario, mod_trax.so , el servidor web reenvía ciertas solicitudes para que sean manejadas por otros procesos usando directivas especiales (como TransferMime ) en los archivos de configuración de Apache.

Por ejemplo, las solicitudes de archivos que terminan en extensión .shtm , .shtml o .srv se envían al proceso / bin / ssid .

El proceso ssid se ejecuta como root, y sirve diferentes funcionalidades para solicitudes .srv que para .shtm o .shtml .

Las solicitudes de un archivo .srv solo están permitidas para usuarios con privilegios. Algunos de los daemons del sistema se comunican mediante el uso del mecanismo de comunicación dbus entre procesos.

Además, la cámara tiene un sistema patentado para administrar los parámetros internos. El proceso / bin / parhand (controlador de parámetros) es responsable de almacenar, recuperar y actualizar los parámetros y sus valores.

Por ejemplo, cuando un usuario establece un parámetro a través de la interfaz web, la secuencia de comandos CGI relevante (param.cgi) reenvía la solicitud de parámetro establecido al proceso parhand, que verifica los derechos de acceso, y almacena el valor del parámetro en el archivo de configuración relevante.

Algunos de los parámetros (los que están «montados en Shell») terminan en archivos de configuración en formato de asignación de variable de shell (por ejemplo, FOO = Bar), que luego se importan (ejecutan) en los scripts de inicio de algunos servicios. Otro proceso de interés es / usr / sbin / policykit_parhand , que ofrece la interfaz dbus de PolicyKitParhand que también incluye funciones para establecer los valores de parhand -parameters .

Al explotar tres de las siete vulnerabilidades recientemente descubiertas en una secuencia específica, un atacante con acceso a la red a la cámara puede ejecutar remotamente comandos de shell con privilegios de administrador.

La secuencia de ataque es la siguiente:

• Paso 1: el atacante usa una vulnerabilidad de omisión de autorización ( CVE-2018-10661 ). Esta vulnerabilidad permite al atacante la posibilidad de enviar solicitudes HTTP no autenticadas que lleguen a la funcionalidad .srv (que maneja solicitudes .srv) dentro de / bin / ssid . Normalmente, esta funcionalidad solo debería ser accesible para los usuarios administrativos.
• Paso 2: El atacante luego utiliza una interfaz que permite enviar cualquier mensaje dbus al bus del dispositivo, sin restricción ( CVE-2018-10662 ), que se puede acceder desde / bin / ssid ‘s . Srv .
• Debido a que / bin / ssid se ejecuta como root, estos mensajes dbus están autorizados a invocar la mayoría de las interfaces de los servicios dbus-services (que estaban sujetas a una estricta política de autorización).
• El atacante elige enviar mensajes dbus a una de las interfaces del servicio dbus – PolicyKitParhand , que ofrece funciones para configurar los parámetros de parhand . El atacante ahora tiene control sobre cualquiera de los parhand del dispositivovalores paramétricos. (Ver la próxima vulnerabilidad).
• Paso 3: una vulnerabilidad de inyección de comandos de shell ( CVE-2018-10660 ) es luego explotada.
• Algunos parámetros parhand (del tipo «montado en Shell») terminan en archivos de configuración en formato de asignación de variable de shell, que luego se incluyen en el script de inicio del servicio que se ejecuta como raíz.
• Debido al paso 2, el atacante puede enviar solicitudes no autenticadas para establecer valores de parhand parhand.
• Al hacerlo, el atacante ahora puede aprovechar esta vulnerabilidad configurando el valor de un parámetro con caracteres especiales que provocarán la inyección de comandos, para ejecutar comandos como el usuario raíz.

Deep-dive técnico

Esta sección proporciona detalles para cada una de las vulnerabilidades utilizadas en la secuencia de ataque completa.

CVE-2018-10661: vulnerabilidad de omisión de autorización

Esta vulnerabilidad permite a un atacante para eludir el mecanismo de autorización del servidor web mediante el envío de solicitudes no autenticadas que llegan a la / bin / SSID ‘s .srv funcionalidad; no se requieren credenciales de usuario.

Esta vulnerabilidad reside en mod_authz_axisgroupfile.so : un módulo de autorización personalizado para Apache httpd que fue escrito por el proveedor.

Como se mencionó anteriormente, el dispositivo ejecuta un servidor httpd de Apache y las solicitudes a las rutas dentro de la carpeta raíz-documento deben ser otorgadas por el módulo de autorización mod_authz_axisgroupfile.so para continuar.

El único archivo .srv dentro de la carpeta raíz del documento es /sm/sm.srv (ruta relativa), y el código de autorización verifica que el usuario autenticado tenga suficientes privilegios para pasar.

Al otorgar la autorización, el servidor web está configurado para manejar las solicitudes con un controlador específico a las rutas que terminan en la extensión .srv (el ‘código del controlador’ .srv ‘ ).

Para resumir el problema, las solicitudes a un archivo legible por todo el mundo que van seguidas de una barra diagonal inversa y finalizan con la extensión .srv (por ejemplo, http: //CAMERA_IP/index.html/a.srv )

Son tratadas por el código de autorización como solicitudes estándar. al index.html y, por lo tanto, al acceso otorgado, mientras que las solicitudes también se tratan como solicitudes legítimas a una ruta de acceso .srv, y así son manejadas por el controlador .srv , de forma simultánea.

Esto sucede debido a una característica de los servidores web que trata cadenas de nombre de ruta posteriores que siguen un nombre de archivo real, llamado PATH_INFO (ver  https://tools.ietf.org/html/rfc3875#section-4.1.5)

La siguiente lógica (abstraída) ocurre al recibir una solicitud HTTP a http: //CAMERA_IP/index.html/a.srv :

1. Cuando Apache httpd analiza el URI de la solicitud, establece los siguientes campos miembros en la solicitud ‘s request_rec estructura:

• uri = «/index.html/a.srv»
• filename = «/usr/html/index.html» # Asumiendo que Document Root del servidor es «/ usr / html»
• path_info = «/a.srv»

2. El acceso a los archivos en el directorio raíz de documentos se rige por el código de autorización personalizado del eje por lo que el módulo (debido a la Requerir eje-grupo-archivo de directiva en el directorio / usr / html directiva de directorio en el httpd archivo de configuración).

El código de autorización personalizado realiza comprobaciones de autorización basadas únicamente en request.filename (consulte la captura de pantalla de IDA con una explicación a continuación), ignorando la existencia de la función path_info y, por lo tanto, concede acceso a /index.html/a.srv , porque el la solicitud se percibe como intencionada para el archivo /usr/html/index.html que es legible en todo el mundo (y no requiere ninguna autenticación).

3. Ahora que la solicitud está autorizada, la directiva <LocationMatch «. + . (Shtml | shtm | srv) ($ | &)»> de la configuración coincide con su patrón de expresiones regex frente a uri (la URL completa de nuestra solicitud, consulte más arriba), y porque termina con » .srv «, la expresión regular coincide y procede a ejecutar el ‘código controlador .srv’ : – «TransferMime / var / run / ssid / ssidsocket» – que transfiere la solicitud a / var / run / zócalo unix ssid / ssidsocket para el manejo por el proceso / bin / ssid.
4. Más tarde, el proceso / bin / ssid recibe la solicitud, verifica su URI (completo) y trata la solicitud como una solicitud legítima a un archivo .srv, lo que permite que la solicitud llegue a la funcionalidad .srv .

Esta captura de pantalla IDA de mod_authz_axisgroupfile.so muestra la función axis_group_file_provider , que está registrada (por la función ap_register_auth_provider de apache ) como un proveedor de autorización para rutas que están sujetas a las directivas ‘Require axis-group-file’. Se puede observar (en la parte superior de la captura de pantalla) que el componente request.filename se usa para verificar si el archivo es legible por todo el mundo. En nuestro ejemplo anterior, request.filename es la ruta del archivo /usr/html/index.html legible en todo el mundo y, por lo tanto, el flujo procede a llamar a la función check_user_authz_by_file_owner_gid , con group_name param como NULL. Cuando se invoca con group_name como NULL , la última función omite todas las verificaciones de autorización y otorga acceso a la solicitud.

Por lo tanto, el atacante tiene acceso no autenticado a la funcionalidad .srv de / bin / ssid

PoC

Para mostrar que tenemos la capacidad de acceder a la funcionalidad .srv / bin / ssid , enviamos una solicitud con el parámetro ‘query_page’ string de consulta. Este es un parámetro especial utilizado para la redirección HTTP. Sabemos que hemos llegado a la funcionalidad .srv / bin / ssid , ya que devuelve una redirección con el valor del parámetro (la cadena «it_worked») en la respuesta.

CVE-2018-10662 – Acceso dbus no restringido para usuarios de la funcionalidad .srv

Peticiones legítimas que llegan a / bin / SSID ‘s funcionalidad .srv puede elegir una de varias acciones mediante el establecimiento de la acción de parámetros de cadena de consulta de la solicitud. Una acción posible es dbus , que permite al usuario invocar cualquier solicitud de dbus como raíz (el uid y el gid del proceso / bin / ssid ), sin ninguna restricción sobre el destino o el contenido. Debido a la solicitud dbus que se origina en un proceso raíz, se otorga acceso sin restricciones a muchas interfaces de los servicios dbus. Esto sucede porque el mecanismo de autorización que está destinado a limitar tales solicitudes, PolicyKit , está configurado para otorgar automáticamente acceso a las solicitudes originadas desde el usuario raíz.

Si bien la interfaz de dbus en / bin / ssid solo sirve para obtener valores específicos de algunos servicios específicos de dbus, expone una funcionalidad mucho más amplia, que tiene consecuencias de seguridad sin justificación.

Por ejemplo, esta interfaz les da a los usuarios la capacidad de controlar cualquiera de los valores de los parámetros de parhand del dispositivo . El control se puede lograr mediante el envío de solicitudes de dbus para invocar las funciones de policykit_parhand process ‘dbus-interface (PolicyKitParhand). Esta interfaz ofrece los métodos SetParameter y SynchParameter que son evocables por root dbus-clients. Al ejecutar SetParameter seguido de SynchParameter , un usuario puede establecer el valor de cualquier parámetro de parhand y aplicar los cambios.

PoC

De la cámara parhand parámetro Image.I0.Overlay.Enabled controla si para mostrar una imagen en la parte superior de la salida de vídeo de la cámara. Como ejemplo, usamos la vulnerabilidad para alternar su valor de ‘no’ a ‘sí’.

Como resultado de ejecutar estos comandos en una cámara vulnerable, la imagen superpuesta (por defecto, un pequeño logotipo del eje) aparecerá en la esquina superior izquierda de la secuencia de video. Uno puede iniciar sesión en la interfaz web para verlo:

CVE-2018-10660: vulnerabilidad de inyección de comandos de shell

Para aprovechar esta vulnerabilidad, debe tener permisos para cambiar ciertos parámetros de parhand . Esto se puede lograr por uno de:

1. Alcanzar / tener privilegios de administrador (usando la interfaz cgi )
2. Ejecutando código dentro del daemon upnp
3. Encontrar otras formas de controlar ciertos parámetros parhand , como lo logró CVE-2018-10662 en el ejemplo de invocar directamente las funciones de policykit_parhand (ver arriba).

El manejador de parámetros parhand es responsable de obtener, almacenar y cambiar muchos de los parámetros internos del dispositivo. Cuando un usuario establece un parámetro a través de la interfaz web, el script CGI relevante (param.cgi) reenvía la solicitud de parámetro de ajuste al parhand binary, que verifica los derechos de acceso, y almacena el valor del parámetro en el archivo de configuración relevante.

Algunos de los parámetros se utilizan para alimentar scripts de shell, y se definen como Shell montado (mount = «Shell {…}» en el archivo de configuración parhand ). Los valores de los parámetros son analizados por el parlante ShellParser, que no desinfecta los caracteres especiales del shell y tampoco cita los valores de los parámetros. Algunos de estos parámetros (por ejemplo, el parámetro Time.DST.Enabled que explotamos ) terminan en archivos de configuración (por ejemplo, /etc/sysconfig/openntpd.conf ) en el formato de asignación de variable de shell (por ejemplo, FOO = Bar). Estos parámetros son luego utilizados por los guiones de inicio del shell (por ejemplo, parhand-systemctl restart time-source.service) que se ejecuta como resultado del comando setter, que se ejecuta cuando se aplica un nuevo valor para un parámetro – al ejecutar el comando sync.

Los scripts de shell ejecutan directamente el archivo de configuración (con el fin de incluir los parámetros de configuración) y al establecer el valor del parámetro con un punto y coma («;»), pudimos inyectar comandos de shell arbitrarios con privilegios de administrador.

Los factores clave en esta vulnerabilidad son:

• Falta de desinfección de entrada al analizar valores que terminan en un entorno de shell
• El dispositivo utiliza un método obsoleto, utilizando scripts de shell para establecer los parámetros almacenándolos en archivos como expresiones de asignación de shell y luego ejecutando los archivos.

Tenga en cuenta también que los parámetros que puede establecer el daemon upnp de la cámara también se pueden usar para aprovechar esta vulnerabilidad para escalar privilegios, en caso de que el atacante tenga la capacidad de ejecutar código dentro del daemon UPnP.

PoC

Fuera de las posibles opciones, elegimos activar esta vulnerabilidad utilizando la interfaz param.cgi , que requiere credenciales de administrador. Inyectamos el comando id , que imprime información de usuario y grupo del usuario actual a la salida estándar. En nuestro caso, la salida estándar se redirige al registro del sistema.

Como una prueba de que el PoC funcionaba, después de ejecutar los comandos, iniciamos sesión como administrador en la interfaz de administración de la cámara para ver el registro del sistema http: //CAMERA_IP/axis-cgi/admin/systemlog.cgi , y pudimos ver el salida del comando id (ver uid y gid en la línea inferior):

Vulnerabilidades adicionales

Esta sección proporciona detalles para cuatro vulnerabilidades más, que no se usaron en la secuencia de ataque descrita anteriormente.

CVE-2018-10664: bloqueo del proceso httpd

Esta vulnerabilidad permite que un adversario no autenticado bloquee el proceso httpd, lo que provoca (al menos) una pantalla negra para los usuarios que ya han iniciado sesión en la cámara mediante la interfaz web con la configuración predeterminada. Esta vulnerabilidad no requiere credenciales de usuario.

La siguiente línea (seguida de un volcado de emergencia) se agrega al registro del sistema después de activar la vulnerabilidad:

[ERR] kernel: [2819.017996] httpd: httpd: señal fatal potencialmente inesperada 11.

CVE – PoC

Esta vulnerabilidad se desencadena al emitir una solicitud HTTP a una URL de script .cgi , con un PATH_INFO que finaliza con la extensión .srv .

CVE-2018-10663 Vulnerabilidad de fuga de información en el proceso / bin / ssid

Esta vulnerabilidad no requiere credenciales de usuario. El ‘ return_page ‘ y ‘ servermanager_return_page parámetros de cadena de consulta’ en / bin / SSID ‘s .srv funcionalidad son controlados por el usuario, y volvieron de nuevo a ella en la respuesta a la petición del usuario. Cuando se trata en el código de construcción de respuestas, los valores de estos campos se recortan a un tamaño de 0x200 bytes y se copian a un espacio mal clasificado de 0x200 bytes utilizando la función segura __snprintf_chk . Luego, el valor de retorno de la   función __snprintf_chk ( supuestamente su longitud) se guarda en una variable de miembro de estructura para luego calcular la longitud del contenido de la respuesta.

El problema es que el valor de retorno de la función __snprintf_chk es «El número de caracteres que se habría escrito si n hubiera sido lo suficientemente grande …» (tomado del manual de sprintf ). Esto hace que la longitud del contenido calculado sea más grande que el búfer de datos real y, como resultado, se filtran bytes adicionales de la memoria en la respuesta.

PoC

Mira cómo cambia el final de la respuesta devuelta. Los símbolos y caracteres adicionales son bytes filtrados que están adyacentes al buffer de la respuesta en la memoria.

CVE-2018-10658 Se bloqueó el proceso / bin / ssid

Esta vulnerabilidad no requiere credenciales de usuario. El usuario no autenticado puede enviar (por / bin / ssid .srv interface) dbus-request con una cadena especialmente diseñada para bloquear el servicio ssid . Este bloqueo surge del código dentro del objeto compartido libdbus-send.so o similar, ya que produce el siguiente mensaje de registro:

[INFO] ssid [2334]: proceso 2334: argumentos a dbus_message_new_method_call () fueron incorrectos, aserción «iface == NULL || _dbus_check_is_valid_interface (iface) «falló en el archivo ../../dbus-1.10.14/dbus/dbus-message.c línea 1373.

Como los bloqueos también se producen al invocar directamente «/ usr / bin / dbus-send » con una cadena similar, esto puede afectar a otros procesos que incluyen este código. Tenga en cuenta que el proceso / bin / ssid se volverá a generar.

PoC

CVE-2018-10659 Fallo del proceso / bin / ssid.

Un usuario no autenticado puede enviar (mediante / bin / ssid .srv interfaz) un comando especialmente diseñado que dará como resultado una ruta de código que llama a la instrucción ARM indefinida UND (y posiblemente un escenario similar en MIPS u otras cámaras de arquitectura) que causa el proceso para bloquearse. Tenga en cuenta que el proceso / bin / ssid se volverá a generar.

La siguiente línea de registro (seguida del volcado de emergencia) aparece después de activarla:

[ERR] kernel: [2390.374778] ssid: ssid: señal fatal potencialmente inesperada 11.

Esta vulnerabilidad no requiere credenciales de usuario.

PoC

Recomendaciones para creadores de dispositivos

Nos gustaría relacionarnos con algunas malas prácticas arquitectónicas que se encontraron en las cámaras analizadas en esta investigación, que hacen que sea más fácil para un atacante descubrir y explotar vulnerabilidades. Alentamos a los fabricantes de dispositivos a tener en cuenta las siguientes recomendaciones.

• Falta de separación de privilegios: Esto viola el concepto de separación de privilegios ( https://en.wikipedia.org/wiki/Privilege_separation ), que establece que un programa debe dividirse en partes, cada parte se limita a sus propios privilegios necesarios. Si bien cada proceso en el sistema se ejecuta como root, un error de ejecución de código en cualquiera de los procesos del sistema permitirá al atacante escalar a los privilegios de root. Por otro lado, si se ejecutaban menos procesos con privilegios altos, un atacante tendría que descubrir vulnerabilidades en un conjunto de procesos más restringido para escalar los privilegios, lo cual es una tarea más difícil.
  • Como ejemplo, en CVE-2018-10662 , / bin / ssid tenía una interfaz dbus no restringida, que permitía a un atacante llamar a las funciones del servicio dbus. Si el proceso no se ejecutaba como root, la política de autorización dbus no permitiría invocar muchas funciones de los servicios dbus privilegiados. Pero debido a que el proceso / bin / ssid se ejecuta como root, todas las funciones de dbus están expuestas al atacante sin barreras de permisos.
• Falta de una correcta desinfección de la entrada: cuando se recibe información de una interfaz externa, la entrada se debe desinfectar a partir de los caracteres que tienen potencial de daño. Esto podría haber evitado CVE-2018-10660 , en el que no se han podido escapar los caracteres especiales del intérprete de comandos.
• Minimizar el uso de scripts de shell: se desaconseja el uso extendido de scripts de shell que toman como parámetros la entrada del usuario. Este enfoque habilitó CVE-2018-10660 . En otra nota, en lugar de ejecutar directamente los comandos dbus, se podría usar la infraestructura parhand (junto con los comandos dbus y getters).
• Falta de cifrado de firmware binario : el cifrado de firmware elevará la barra y dificultará que los adversarios analicen el firmware en busca de errores, y utilizará específicamente métodos de diferenciación binaria entre el último firmware y el anterior para buscar y analizar los parches y de esta manera: descubrir las vulnerabilidades que aún existen en la versión anterior. Además, el dispositivo contenía binarios sin tirar con símbolos como nombres de funciones. Esto nos ayudó a entender cómo funciona el código. Por otro lado, vale la pena señalar que el enfoque de seguridad por oscuridad para el contenido de firmware puede contribuir a una situación en la que existen problemas, pero que no se están descubriendo y solucionando, ya que el firmware está encriptado correctamente. Los vendedores deben considerar este compromiso con cuidado.

Reconocimiento

Nos gustaría agradecer al equipo de seguridad de Axis Communications por el manejo eficiente y rápido de este problema de seguridad y por su conducta profesional de comunicación.

Crédito

O pieles ( @peles_o ) VDOO

Sección de preguntas frecuentes

Q1. ¿Cómo puedo saber si mi dispositivo es vulnerable?

Para verificar si su dispositivo es vulnerable o no, debe verificar la lista de productos afectados de ACV-128401 . Si el firmware de su cámara es una versión anterior o la versión que aparece en la lista de productos afectados de ACV-128401, su dispositivo es vulnerable, y recomendamos encarecidamente actualizar el firmware del dispositivo. Para verificar qué versión de firmware usa su cámara, puede hacer lo siguiente:

1. Usando un navegador web, acceda a su cámara.
2. Ingrese su nombre de usuario y contraseña
3. Haga clic en «Sistema» -> «Opciones» -> «Soporte» -> «Descripción general del sistema».
4. Busque la versión de firmware

Si tiene varios dispositivos, puede valer la pena recuperar el firmware utilizando el software Axis Device Manager o mediante programación a través de Axis VAPIX API (consulte la sección 2.2 en la documentación oficial de VAPIX ).

Q2. ¿Cómo puedo saber si mi dispositivo fue violado?

Las posibilidades de que su dispositivo haya sido violado son muy bajas ya que no hay malware conocido que utilice estas vulnerabilidades en el momento de la publicación.
Como el malware de IoT normalmente está diseñado para pasar desapercibido, no existe una manera fácil de saberlo con certeza. Cualquier cambio sospechoso en el dispositivo puede indicar la existencia de un malware de botnet en su dispositivo.

Algunas formas de verificar:

1. Su contraseña ya no funciona (y no porque simplemente lo haya olvidado): esta es una buena indicación para un dispositivo que ha sido tomado.
2. La configuración de su dispositivo fue modificada ; por ejemplo, los videos ahora se envían a un servidor diferente.
3. Aumento del tráfico de la red : si es posible, examine las estadísticas de la red del enrutador. Una botnet podría aumentar la cantidad de tráfico de red originado desde la cámara. Cualquier pico debe alertarlo, ya que a menos que esté transmitiendo video de la cámara, este número debería ser relativamente bajo.

Q3. ¿Hay alguna manera de remediar mi dispositivo si se incumplió?

En el momento de la publicación, no tenemos conocimiento de ningún malware que abuse de este problema. Si sospecha que su cámara está violada, restaure la cámara a su configuración de fábrica. Al hacerlo, restaurará la configuración a la configuración predeterminada, lo que le permitirá conectarse y actualizar el firmware. Tenga en cuenta que si está usando un firmware susceptible a las vulnerabilidades detectadas por VDOO, el dispositivo podría ser el objetivo y podría infectarse nuevamente en breve. Por lo tanto, después de reiniciar el dispositivo, asegúrese de realizar inmediatamente la actualización del firmware, antes de conectar la cámara directamente a Internet.

Q4. ¿Cómo mitigar el riesgo si no puedo actualizar el firmware de la cámara?

Para reducir la exposición de la cámara y la capacidad de administrarla de forma remota, se recomienda colocar el dispositivo detrás de un cortafuegos que bloquea los puertos 80 y 443 (o los puertos especificados en la configuración de la cámara) y considerar no permitir que la cámara inicie ninguna salida conexiones. Otra opción es colocar el dispositivo detrás de un proxy inverso que bloquea las URL que estamos usando para el exploit (ver arriba para detalles adicionales). Por favor, póngase en contacto con security@vdoo.com si necesita ayuda adicional.

Q5. ¿Cómo actualizar el firmware en la cámara?

Para actualizar a la última versión del firmware, puede usar Axis Device Manager, la interfaz web de la cámara o FTP.https://www.axis.com/en-in/support/tecnical-notes/how-to-upgrade  para encontrar las instrucciones del proveedor para la actualización del firmware.