Visto: 120

Nuevas vulnerabilidades de Reolink P2P muestran los riesgos de IoT por medio de las cámaras de seguridad

Inicio desactivadoInicio desactivadoInicio desactivadoInicio desactivadoInicio desactivado
 

Nozomi Networks Labs ha descubierto vulnerabilidades en la función Peer-to-Peer (P2P) de una línea de cámaras de seguridad de uso común: Reolink.

Nuestra investigación ha dado como resultado una divulgación coordinada con ICS-CERT, que publicó el aviso ICSA-21-019-02: Reolink P2P Cámaras.

Las cámaras y NVRs (grabadoras de vídeo en red) de Reolink suelen ser utilizadas por propietarios de viviendas y pequeñas empresas; sin embargo, son relevantes para la infraestructura crítica y los operadores industriales de dos formas.

Uno, pueden estar en uso en sus instalaciones, incluso en sus redes OT. Dos, P2P es utilizado por varios proveedores de cámaras y, si su solución de CCTV tiene esta función, es importante comprender los riesgos potenciales.

Esta nota describe el viaje que hicimos para encontrar estas vulnerabilidades de seguridad de IoT y presenta detalles técnicos que son relevantes para los equipos de seguridad e investigadores.

 

Funcionalidad punto a punto en cámaras de seguridad
de IoT y sus implicaciones de seguridad

Peer-to-Peer (P2P), en el contexto de las cámaras de seguridad, se refiere a la funcionalidad que permite a un cliente acceder a secuencias de audio / video de forma transparente a través de Internet. Los datos de video están disponibles en las cámaras o se accede a ellos a través de NVR.

En lugar de que un usuario configure explícitamente un firewall para permitir que un cliente llegue al dispositivo con los datos de video, "P2P" establece una conexión a través de una técnica establecida comúnmente definida por el término general "perforar". Los detalles técnicos varían entre proveedores y proveedores externos de esta funcionalidad. Sin embargo, el escenario típico involucra un nodo accesible a Internet que actúa como mediador entre el cliente que desea acceder a la transmisión de audio / video y el dispositivo que entrega los datos.

En agosto de 2020, el investigador de seguridad Paul Marrapese publicó una extensa investigación que detalla los problemas de seguridad que afectan las implementaciones P2P de algunos proveedores. Al explotar estas vulnerabilidades, un atacante puede interceptar la transmisión de audio / video cuando ellos quieran.

Lo que más nos preocupó del brillante trabajo de Marrapese fue la gran cantidad de usuarios finales afectados por los problemas identificados y la falta de documentación oficial que describa cómo opera la funcionalidad P2P. Al examinar algunos dispositivos que teníamos en nuestro laboratorio, quedó claro que las implicaciones de privacidad y seguridad del uso de la función "P2P" de una cámara no se explican claramente a los usuarios.

Este descubrimiento nos llevó a investigar más a fondo la situación. Nuestros objetivos de investigación suelen ser dobles. Primero, queremos proteger a los operadores industriales que podrían estar ejecutando inconscientemente la funcionalidad P2P en cámaras en sus redes OT o en sus instalaciones. En segundo lugar, queremos arrojar algo de luz sobre el nivel de seguridad de las implementaciones P2P y compartir nuestros hallazgos con la comunidad de seguridad en general.

 

Descripción general de P2P de las cámaras de CCTV Reolink

Comenzando con un conjunto completo de cámaras CCTV Reolink y el NVR correspondiente, comenzamos a investigar si la funcionalidad P2P estaba presente en primer lugar. Como se explica en la sección de soporte del sitio web de Reolink, el término "UID" se usa en lugar de P2P en la interfaz de usuario del dispositivo. Después de arrancar un NVR con UID habilitado, inspeccionamos el tráfico de red e inmediatamente nos dimos cuenta de que la función P2P estaba funcionando, ya que se intercambiaron varios paquetes UDP con el host.

20210129 02

Después de iniciar una cámara NVR Reolink con UID habilitado, inspeccionamos el tráfico de red
y supimos que la función P2P estaba funcionando, ya que se intercambiaron varios paquetes UDP con el host.

 

Debemos destacar que el alcance de nuestra evaluación se limitó a comprender cómo se protegía la transmisión de audio / video al atravesar Internet. Registramos exclusivamente el tráfico que se origina en los dispositivos Reolink en nuestro laboratorio y analizamos cómo los dispositivos y los clientes creaban y reproducían las transmisiones. No realizamos ninguna actividad contra los servidores de Reolink ni enviamos tráfico falso de ningún tipo. El tráfico que llegaba a los servidores de Reolink siempre lo creaba el software Reolink.

La configuración que usamos en nuestro análisis refleja la descrita por el proveedor en la descripción de la arquitectura P2P:

  1. Un NVR está conectado a cámaras de seguridad a través de la misma red local y representa el servidor P2P que genera la transmisión de audio / video.
  2. Un “servidor Reolink P2P”, un servidor administrado por el proveedor actúa como intermediario permitiendo que el cliente y el NVR establezcan una conexión.
  3. Un cliente de software ya sea una aplicación móvil o de escritorio, accede a la transmisión de audio / video desde Internet.

 

¿Son seguras las cámaras de seguridad P2P?

A pesar del avance en la tecnología P2P, es probable que las cámaras IP P2P sean vulnerables a las amenazas de seguridad. Es por eso por lo que la autenticación del servidor P2P debe ser realizada por al menos 2 servidores para garantizar la seguridad y la conectividad en caso de que un servidor se caiga temporalmente.

20210129 03

La arquitectura y configuración de seguridad de Reolink P2P, según lo descrito por el proveedor

 

Por ejemplo, el servidor P2P Reolink (proporcionado por Amazon Web Server) contiene el servidor principal y confía en el servidor para asegurarse de que las cámaras P2P no sufran fallas de conexión.

Mientras tanto, tecnologías de seguridad avanzadas como cifrado SSL, cifrado WPA2-AES y SSL-TLS, se aplican en cámaras P2P y aplicaciones / software de cámaras IP P2P o visualización del cliente, asegurándose de que la transmisión no sea pirateada o escuchada por otros.

Para reducir el riesgo de seguridad de las cámaras IP P2P, elegir cámaras P2P de una marca de renombre como Reolink ayuda en gran medida a garantizar la seguridad de las cámaras WiFi P2P.

Además, el uso de transmisiones de video y transmisiones en vivo de VPN también ayuda a reducir el riesgo de que las cámaras IP de red P2P sean interceptadas o pirateadas.

Antes de lanzar nuestra investigación, realizamos una investigación de antecedentes para comprender si ya se había realizado una investigación sobre la implementación P2P de Reolink. Nos encontramos con el blog de George Hilliard, en el que documenta el protocolo propietario que utilizan los dispositivos y clientes de Reolink dentro de una red local. Esto proporcionó un lugar interesante para comenzar.

Al analizar el tráfico local con el disector proporcionado, podríamos navegar fácilmente a través de los flujos de TCP. Estos llevaban la parte de "señalización" del protocolo propietario y del componente de audio / video. En particular, notamos que los paquetes de señalización estaban ofuscados con una clave trivial de 8 bytes.

20210129 04

Tráfico local de Reolink analizado con el disector Neolink

 

Comunicación entre NVR y el servidor P2P Reolink

Primero analizamos exclusivamente el tráfico intercambiado entre nuestro NVR y el servidor P2P Reolink e inmediatamente notamos algunos patrones en los paquetes UDP intercambiados. Esta observación nos llevó a pensar que una estrategia de ofuscación, como la utilizada en el protocolo de red local, podría emplearse para el tráfico que atraviesa Internet. Al cargar el binario NVR encargado de crear estos paquetes en el desensamblador, ubicamos las funciones responsables de la I/O de la red. A partir de ahí, encontramos el código que realiza la ofuscación utilizando una clave codificada.

20210129 05

Al analizar el binario principal del NVR con el desensamblador, localizamos las funciones responsables
de la I/O de la red. A partir de ahí, encontramos el código que realiza la ofuscación utilizando una clave codificada.

 

El siguiente paso más obvio fue crear un pequeño script que intentaba revelar la carga útil UDP con la clave que acabábamos de identificar. Lo que sigue es el resultado obtenido con los tres primeros paquetes:

[UDP] nvr:46469 -> p2p.reolink.com:9999
<P2P>
 <D2M_Q>
  <uid>9527000*************</uid>
  <ver>2</ver>
  <r>3<r>
 </D2M_Q>
</P2P>
-----
[UDP] p2p.reolink.com:9999 -> nvr:46469
<P2P>
 <M2D_Q_R>
  <reg>
   <ip>35.180.210.74</ip>
   <port>58200</port>
  </reg>
  <log>
   <ip>35.180.210.74</ip>
    <port>57850</port></log>
  <timer/>
  <retry/>
  <rsp>0</rsp>
  <token>1598321923</token>
  <ac>1130209852</ac>
 </M2D_Q_R>
</P2P>
-----
[UDP] nvr:46469 -> p2p.reolink.com:58200
<P2P>
 <D2R_R>
  <uid>9527000*************</uid>
  <dev>
   <ip>192.168.0.250</ip>
   <port>46469</port>
  </dev>
  <token>1598321923</token>
  <r>3</r>
 </D2R_R>
</P2P>

Los primeros tres paquetes de la carga útil UDP se revelan mediante un pequeño script y la clave codificada identificada por nuestro equipo.

 

Acceder al protocolo de texto sin cifrar fue el primer bloque de construcción que nos permitió desarrollar una comprensión de las operaciones realizadas por el servidor P2P.

 

Comunicación entre el cliente P2P y el servidor P2P Reolink

Una vez que establecimos que podíamos acceder a las comunicaciones de texto sin cifrar entre el NVR y el servidor P2P de Reolink, llegó el momento de incorporar un cliente P2P a la imagen. Hay varias aplicaciones cliente disponibles para elegir, tanto móviles como de escritorio. Por el bien del análisis, no hay ninguna diferencia práctica, ya que todos usan el mismo protocolo.

Se procedió con la misma metodología. Al inspeccionar la comunicación desofuscada entre el cliente y el servidor Reolink, podríamos extrapolar varias cosas:

  1. El servidor Reolink proporciona la dirección IP / el par de puertos UDP del servidor NVR (etiqueta <dmap>) al cliente.
  2. El servidor Reolink también envía un valor sid que luego es utilizado por el cliente para autenticar el NVR.
  3. El cliente reconoce la dirección IP / puerto UDP de su elección para la funcionalidad de retransmisión al servidor Reolink (etiqueta <relay>).

 

[UDP] p2p_client:23878 -> p2p.reolink.com:58200
<P2P>
 <C2R_C>
  <uid>9527000*************</uid>
  <cli>
   <ip>172.20.10.2</ip>
   <port>23878</port>
  </cli>
  <relay>
   <ip>35.180.210.74</ip>
   <port>58100</port>
  </relay>
  <cid>878000</cid>
  <debug>251658240</debug>
  <family>4</family>
  <p>MAC</p>
  <r>3</r>
 </C2R_C>
</P2P>
-----
[UDP] p2p.reolink.com:58200 -> p2p_client:23878
<P2P>
 <R2C_T>
  <dev>
   <ip>192.168.0.250</ip>
   <port>48428</port>
  </dev>
  <dmap>
   <ip>62.23.60.33</ip>
   <port>48428</port>
  </dmap>
  <sid>1050376851</sid>
  <cid>878000</cid>
  <rsp>0</rsp>
 </R2C_T>
</P2P>

El código anterior muestra el servidor Reolink y el cliente comunicando la dirección IP
y la información del par de puertos UDP, así como el valor utilizado para autenticarse con el NVR.

 

Comunicación entre el NVR y el cliente P2P

Con todas las piezas en su lugar, finalmente pudimos entender cómo se comunica el cliente P2P con el NVR. La condición previa para que esto suceda es, obviamente, que el NVR se haya inscrito en el servidor Reolink, de lo contrario, el cliente sería informado de inmediato sobre la falta de datos de audio / video de origen.

Para nuestra sorpresa, incluso la comunicación entre el NVR y el cliente P2P carecía de algún tipo de intercambio de claves seguro. Más bien, la misma clave codificada que usamos hasta ahora para revelar el tráfico de la red seguía siendo efectiva. A continuación, podríamos analizar cómo el cliente P2P se autentica en el NVR, utilizando el valor sid que nos dio el servidor Reolink.

[UDP] p2p_client:23878 -> nvr:48428
<P2P>
 <C2D_T>
  <sid>1050376851</sid>
  <conn>map</conn>
  <cid>878000</cid>
  <mtu>1350</mtu>
 </C2D_T>
</P2P>
-----
[UDP] nvr:48428 -> p2p_client:23878
<P2P>
 <D2C_T>
  <sid>1050376851</sid>
  <conn>map</conn>
  <cid>878000</cid>
  <did>848</did>
 </D2C_T>
</P2P>

El cliente P2P se autentica en el NVR utilizando el mismo valor sid que le dio el servidor Reolink.

 

Antes de responder al cliente P2P, el NVR recibe una notificación de la próxima conexión del cliente del servidor Reolink a través de la etiqueta cmap, que funciona de manera similar a la de dmap que se presentó anteriormente. El cliente P2P ahora está autenticado con el NVR y puede comenzar a solicitar transmisiones de audio / video.

 

CVE-2020-25169 - Falta de cifrado de video / audio P2P y reconstrucción de transmisión

CWE-319: Transmisión de texto sin cifrar de reconstrucción de información sensible

Solicitamos transmisiones de audio / video al cliente para generar tráfico para su posterior análisis. La primera variación notable para los paquetes que transportan datos de audio / video es la magia de encabezado específica, nombrada 0x2a87cf10.

El otro elemento obvio que se destacó fue la presencia de algunas “palabras clave” de texto sin cifrar como 01dcH264. Esto sugirió que podría faltar un cifrado seguro de la carga útil. Procedimos a determinar los campos de encabezado restantes para reconstruir correctamente la secuencia tal como la ve el cliente. Una vez terminado, podríamos reproducir el contenido de audio / video en texto sin cifrar.

La consecuencia de esta elección de diseño es que cualquiera que pueda acceder al tráfico del cliente / NVR mientras atraviesa Internet puede acceder a su carga útil de audio / video, sin confidencialidad para las partes involucradas.

 

20210129 06

La secuencia de audio / video, como se ve desde Internet.

 

En algunas situaciones, la conexión entre un cliente y el NVR no es lo suficientemente estable. En estos casos, la implementación de Reolink P2P también permite que el servidor P2P actúe como un nodo de retransmisión, comportándose efectivamente como un intermediario.

Combinando la falta de un cifrado de extremo a extremo con la función de retransmisión, de facto se expone al proveedor el flujo de audio / video de texto sin cifrar.

 

CVE-2020-25173 - Desofuscación del protocolo P2P y fuga de credenciales

CWE-321: Uso de clave criptográfica codificada

Mientras investigábamos el intercambio de protocolos entre el servidor P2P de Reolink y el NVR, notamos otro problema de seguridad. El servidor del proveedor también extrae la lista de usuarios locales registrados con el NVR, junto con sus correspondientes contraseñas de texto sin cifrar.

Luchamos por comprender la razón por la que el proveedor desea acceder a este tipo de información. La consecuencia inmediata de este diseño es que un actor que puede acceder a este tráfico de red puede obtener las credenciales de los usuarios locales. Una vez que desofuscan el protocolo, como se explicó anteriormente, pueden iniciar sesión en el NVR con como un cliente Reolink normal.

<xml version="1.0" encoding="UTF-8">
 <body>
  <AbilitySuppport version="1.1">
   <userName></userName>
   <system>1</system>
   <streaming>1</streaming>
   <record>1</record>
   <network>1</network>
   <PTZ>1</PTZ>
   <IO>0</IO>
   <alarm>1</alarm>
   <image>1</image>
   <video>1</video>
   <audio>1</audio>
   <security>1</security>
   <replay>1</replay>
   <disk>1</disk>
  </AbilitySuppport>
 <UserList version="1.1">
  <User>
   <userId>0</userId>
   <userName>admin</userName>
   <password>aaaaaa</password>
   <userLevel>1</userLevel>
   <loginState>1</loginState>
   <userSetState>none</userSetState>
  </User>
 </UserList>
</body>
</xml>

Los nombres de usuario / contraseñas de texto sin cifrar del NVR se envían a los servidores de Reolink.

 

Mitigación del proveedor

Reolink ha lanzado una nueva versión del firmware que, según ellos, mitiga los problemas discutidos en esta publicación. Sin embargo, le sugerimos que evalúe cuidadosamente los riesgos potenciales relacionados con la funcionalidad P2P antes de habilitarla. También le sugerimos que considere alternativas como las VPN, que brindan mayor seguridad, aunque más esfuerzo de configuración.

 

Las vulnerabilidades de Reolink P2P destacan los riesgos
de las cámaras de seguridad de IoT

Las cámaras de seguridad de IoT son ampliamente utilizadas por la industria y el sector de infraestructura crítica. Según la firma de investigación Markets and Markets, se espera que el tamaño del mercado global de videovigilancia crezca de US $ 45.5 mil millones en 2020 a US $ 74.6 mil millones para el 2025. Se espera que el sector de infraestructura, incluido el transporte, la vigilancia de la ciudad, los lugares y los servicios públicos, crezca al CAGR más alto durante ese período.

Dada su prevalencia y uso creciente, es importante comprender los riesgos de seguridad de las cámaras IoT. Le recomendamos que tome medidas urgentes para evitar el acceso no autorizado a las transmisiones de audio / video y las credenciales de usuario de CCTV. No hacerlo podría resultar en daños a la privacidad, la confidencialidad y el negocio.

 

Fuente de información: https://www.nozominetworks.com/blog/new-reolink-p2p-vulnerabilities-show-iot-security-camera-risks/?utm_campaign=2020-Email-Blog-New-Reolink-P2P-Vulnerabilities-Show-IoT-Security-Camera-Risks&utm_medium=email&_hsmi=107244311&_hsenc=p2ANqtz-9acJsfoY-sVQDn7p_xAqpDyX17Z-MZ-4OfLqJU9CVLFTpHPXfrleQL4I3vC5DyEua3YhU7UaWATtb07kilBQN3Vr1QZw&utm_content=107244311&utm_source=hs_email