Los dispositivos Long Range Wide Area Network (LoRaWAN) han sido blancos de ataques desde hace tiempo. Exploramos los ataques que los actores maliciosos pueden usar contra ellos y evaluamos el estado de la seguridad LoRaWAN. Esta es la primera de una serie de tres partes.
El despliegue de dispositivos del Internet de las Cosas (IoT) permite operaciones de gran escala y servicios de gran alcance en ciudades inteligentes, instalaciones industriales y áreas agrícolas conectadas para poder correr de forma eficiente y sin fricciones. Muchas organizaciones están buscando tecnologías asequibles que permitan lograr despliegues de IoT extensos y estables. Un ejemplo es el protocolo LoRa (long-range), el cual ayuda a las empresas a conectar dispositivos de bajo poder al internet usando una conexión inalámbrica. Long Range Wide Area Network (LoRaWAN) es una tecnología basada en radio que funciona en conjunto con LoRa. Los dispositivos LoRaWAN que se encuentren diseminados en áreas extensas pueden conectarse inalámbricamente al internet a través de ondas de radio. Esta tecnología puede usarse en sensores de monitoreo (clima o rastreo), administración de activos, automatización controlada, control de clima y más.
La infraestructura LoRaWAN ofrece oportunidades para las organizaciones que quieren desplegar soluciones de IoT a un costo mucho más bajo del que permiten las soluciones existentes de infraestructura celular. Varias ciudades alrededor del mundo ya han adoptado tecnología LoRaWAN para administrar los servicios públicos. Ya está establecido en Taiwán, después de que el gobierno de Taipei impulsara a que los negocios privados usaran la plataforma LoRa en el 2016. Por más de dos años, la ciudad de Tainan usó dispositivos LoRaWAN para monitorear camiones de basura y los niveles de agua de los ríos. Otras ciudades en Taiwán despliegan LoRaWAN en varios casos de uso diferentes: para administrar presas, entregar comida fresca e incluso monitorear bicicletas en el camino. En el 2019, el proveedor de servicios de acceso a internet líder en China, Tencent, colaboró con The Things Network para expandir el ecosistema LoRaWAN del país. En el Reino Unido, nuevas inversiones en el 2020 aseguran la existencia de redes e infraestructura LoRaWAN más amplias en el futuro. Y en Alemania, medidores digitales de agua que usan la tecnología LoRaWAN también se están instalando en diferentes ciudades.
De acuerdo con LoRa Alliance, un grupo global de más de 500 empresas dedicadas al desarrollo de LoRaWAN, existen operadores de red LoRaWAN en 162 países y se espera que ese número crezca. Sin embargo aunque diferentes sectores alrededor del mundo han adoptado esta tecnología, no su seguridad no ha sido completamente explorada o desarrollado todavía. Debido a estos factores, los dispositivos LoRaWAN han sido blancos de ataques por algún tiempo. Este blog cubre algunos ataques que los actores maliciosos pueden usar contra los dispositivos LoRaWAN vulnerables, seguido de una visión del estado de la seguridad de LoRaWAN.
Ataques contra LoRaWAN
Las organizaciones que usan LoRaWAN son en su mayoría instalaciones e industrial o agriculturales de gran escala, proveedores de servicio o gobiernos locales. Los dispositivos que usan la tecnología a menudo no usan mucha energía y a menudo se distribuyen ampliamente, por lo que las organizaciones podrían no tener la inclinación de proteger exhaustivamente los dispositivos o la red. Sin embargo, los dispositivos LoRaWAN comprometidos podrían usarse en ataques que resulten en la interrupción de las operaciones, brechas de datos o información falsificada.
Por ejemplo, si se interrumpe la comunicación entre un medidor de agua inteligente y la red, los criminales podrían manipular la facturación de los servicios. De forma similar, un ataque a un sensor de monitoreo en las carreteras podría afectar la seguridad de quienes transitan por ella.
DoS en modo ABP
En el 2018, investigadores de los Países Bajos lanzaron un reporte describiendo diferentes ataques en LoRaWAN. Uno involucró LoRa 1.0, derivándose del hecho de que el counter en FRMPayload tiene una longitud de solamente 16 bits. Demostraron que era posible volver a ejecutar un packet capturado; esperar hasta el que counter se sature y volver a ejecutar este packet para ralizar un ataque de denegación de servicio (DoS):
[image url=”https://www.trendmicro.com/content/dam/trendmicro/global/en/research/21/a/low-powered-but-high-risk-evaluating-possible-attacks-on-lorawan-devices/fig-6-01.jpg” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″]
Figura 1. Ejemplo de un ataque para ABP
Las keys de la sesión siguen siendo las mismas hasta que se cambien manualmente o con una actualización del firmware: Over the Air Activation (OTAA) or Activation by Personalization (ABP). ABP es más vulnerable a un ataque de criptoanálisis a comparación de OTAA.
Bit-Flipping
Sin importar la versión, la integridad de los mensajes de LoRaWAN es protegida por el Message Integrity Code (MIC), el cual previene encripción y manipulación intencional. Sin embargo, los mensajes descifrados por el servidor de red y enviados al servidor de la aplicación ya no están protegidos:
[image url=”https://www.trendmicro.com/content/dam/trendmicro/global/en/research/21/a/low-powered-but-high-risk-evaluating-possible-attacks-on-lorawan-devices/fig-7-01.jpg” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″]
Figura 2. La configuración de un ataque de bit-flipping, de acuerdo con investigadores de los Países Bajos
Proteger la comunicación es una tarea complicada, porque el mensaje termina de forma temprana. Protegerlo requeriría diseñar la red para usar un túnel SSL (de preferencia con un certificado de cliente SSL) u otro campo MIC dentro del MAC Layer Payload computado por el AppSKey.
Ack Spoofing
Un mecanismo de reconocimiento fue introducido en LoRaWAN para maximizar la vida de las baterías por medio de la reducción del tiempo que se necesita usar el radio. Pero como destacan Xueying Yang, Evgenios Karampatzakis, Christian Doerr y Fernando Kuiper en su reporte, el mensaje ACK no determina cuál es el mensaje que se está confirmando.
[image url=”https://www.trendmicro.com/content/dam/trendmicro/global/en/research/21/a/low-powered-but-high-risk-evaluating-possible-attacks-on-lorawan-devices/fig-8-01.jpg” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″]
Figura 3. Se le puede dar un nuevo uso a los mensajes ACK para reconocer marcos que no son los que originalmente recibía el proveedor de la aplicación
Para ilustrar este tema, los investigadores propusieron bloquear selectivamente el downlink cuando un dispositivo final manda un mensaje de confirmación al gateway receptor. El dispositivo final nunca recibirá el mensaje de confirmación y volverá a transmitir el mensaje de confirmación siete veces. Entonces considerará este mensaje como perdido o refutado, dando como estatus “mac_err”.
Pero durante el bloqueo, el atacante puede capturar el mensaje de downlink para la confirmación y ejecutar la confirmación para el primer mensaje cuando el dispositivo final manda un segundo mensaje de confirmación.
Ataques a LoRa Clase B
La mayoría de las configuraciones usan el modo clase A de LoRaWAN, el cual especifica que el tráfico de downlink debe/puede seguir un uplink. La clase B tiende a reducir la cantidad de energía que se utiliza al decirle a los dispositivos finales que se “despierten” periódicamente para recibir mensajes entrantes durante una ventana de tiempo.
Las duraciones de las ventanas se especifican por medio de mensajes que consisten en un header con una capa PHY seguido de un beacon:payload.
[image url=”https://www.trendmicro.com/content/dam/trendmicro/global/en/research/21/a/low-powered-but-high-risk-evaluating-possible-attacks-on-lorawan-devices/lorawan4.png” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″]
Figura 4. Contenido del marco del beacon para la banda EU 863- 870MHz ISM
Los investigadores demostraron que un atacante puede calcular fácilmente los diferentes campos públicos conocidos con parámetros maliciosos para:
- Encontrar la ubicación de un gateway LoRa (gracias a un campo GwSpecific con un subcampo de InfoDesc que contiene las coordenadas GPS).
- Drenar la batería al mandar beacons marcados con un valor de tiempo alto.
De acuerdo con su investigación (así como otro reporte de evaluación de seguridad de LoRaWAN por Frank Hessel, Lars Almon, Flor Álvarez) y las especificación LoRaWAN v1.1, la integridad de los marcos de beacon sigue siendo un problema, y sería mejor usar un MIC en lugar de un CRC para verificar la integridad del tiempo en el campo.
Administración de Root Keys
Encima de todos los mecanismos de seguridad previamente discutidos, la administración de keys también es crítica para la seguridad. Las root keys se usan en dispositivos OTAA; derivan keys de sesión cuando el dispositivo OTAA ejecuta un procedimiento para unirse con la red.
Debido a que el backend está expuesto al internet, un actor malicioso podría usar debilidades y vulnerabilidades críticas (LFI, SQL injection, vulnerabilidad de deserialización, etc.) para obtener la key secreta, leer los datos, crear packets de downlinks y conducir otras actividades ilícitas.
Para mitigar estos riesgos, presentamos una lista de cosas para revisar en una configuración de LoRaWAN:
- Use keys generadas al azar
- Evite la exposición de servidores y servicios de administración de keys (servicio de administración de keys expuestos y accesibles en el internet)
- Use de preferencia HSM (Hardware Security Module) para mantener las keys
- Use preferiblemente el modo OTAA y LoRa versión 1.1
El estado de la seguridad para LoRaWAN
Son pocas las herramientas de seguridad para la tecnología LoRaWAN que fueron lanzadas en el 2020. Investigadores de IOActive lanzaron un framework llamado LAF (LoRaWAN Auditing Framework) ofrecieron una herramienta que puede buscar, mandar, crear, analizar y auditar una configuración y descifrar algunos packets de LoRaWAN usando keys débiles o por defecto. Los investigadores también publicaron una investigación presentando ataques en LoRaWAN 1.0.3, usando principalmente su herramienta.
Sin embargo, este framework aún tiene algunas limitaciones que deben superarse:
- Sólo funciona con un Gateway
- Solamente puede escuchar para hacer uplink de los packets
- Solamente puede escuchar en 8 de los 64 canales
- La generación depende de que LoRaWAN (Go) use un formato no flexible como JSON
En el mismo periodo, otro tipo de herramienta llamada “LoRa Craft” fue liberado para interceptar packets usando Software Defined-Radio, y crear packets usando capas dedicadas de LoRaWAN v1.0 y v1.1 desarrolladas para los propósitos de esta herramienta. Pero esta herramienta tiene un enfoque de “hágalo usted mismo” que necesita mucho más soporte qué otras que ya han sido lanzadas, como crypto helpers para payloads de Join-Accept y MIC para ayudar a romper las keys débiles.
En mayom SEEMOO Lab lanzó un framework llamado ChirpOTLE que mostró dos ataques que afectaron la disponibilidad de redes LoRaWAN como time drifting en LoRa clase B y un nuevo ataque de spoofing ADR para manipular los metadatos del marco. Pero aún así, los investigadores se vieron limitados por su configuración al escoger solamente algunos canales por defecto para demostrar su ataque con cada nodo.
Esto muestra que, aunque se están desarrollando soluciones de seguridad, la protección integral y accesible para LoRaWAN aún tiene mucho camino por recorrer. Para conocer más acerca de los ataques a LoRaWAN y los demás temas discutidos arriba, descargue el brief técnico completo.
Leave a Reply