LTESniffer: sniffer open source de enlace descendente/ascendente LTE

 (github.com/SysSec-KAIST)
1 puntos por GN⁺ 2024-10-23 | 1 comentarios | Compartir por WhatsApp
  • LTESniffer es una herramienta open source que captura mensajes inalámbricos de enlace descendente y ascendente entre una estación base LTE y un smartphone, obtiene primero DCI y RNTI desde el PDCCH, y luego decodifica PDSCH y PUSCH para analizar el tráfico de datos
  • No puede descifrar mensajes cifrados; solo puede analizar partes no cifradas como encabezados MAC y de capa física, mensajes broadcast de la estación base y mensajes iniciales de conexión en texto plano
  • La API para investigación de seguridad soporta tres funciones: identity mapping, recolección de IMSI y perfilado de capacidades de UE; es una implementación que busca complementar el requisito de sniffer pasivo asumido por investigaciones previas de seguridad LTE mediante la decodificación de paquetes de protocolo PDSCH y PUSCH
  • El alcance funcional incluye LTE Advanced y LTE Advanced Pro, hasta 256QAM en enlace ascendente y descendente, FDD, estaciones base de hasta 20MHz, formatos DCI 0/1A/1/1B/1C/2/2A/2B y modos de transmisión 1~4
  • La decodificación en tiempo real requiere una CPU multinúcleo física y una configuración SDR, y la recolección de tráfico ascendente requiere que el sniffer esté cerca del smartphone o que se refuerce el hardware con antenas direccionales, front-end RF y amplificadores, ya que la señal del UE es débil

Qué hace LTESniffer

  • LTESniffer es un sniffer open source que captura tanto el enlace descendente como el ascendente de LTE
  • Su flujo de trabajo primero decodifica el PDCCH para obtener DCI y RNTI de los usuarios activos, y luego usa eso para decodificar adicionalmente PDSCH y PUSCH y extraer el tráfico de datos de subida y bajada
  • Desde la perspectiva de un usuario general, es una herramienta que captura en ambos sentidos los mensajes inalámbricos LTE que van y vienen entre la estación base y el smartphone conectado
  • No puede descifrar mensajes cifrados
    • En los mensajes cifrados, puede analizar las partes no cifradas, como los encabezados MAC y de capa física
    • Los mensajes broadcast de la estación base transmitidos en texto plano o los mensajes iniciales de conexión pueden analizarse por completo

API de investigación de seguridad y objetivo del proyecto

  • LTESniffer ofrece 3 funciones de API para aplicaciones e investigación de seguridad
    • identity mapping
    • IMSI collecting
    • UE capability profiling
  • Muchas investigaciones de seguridad LTE asumen un sniffer pasivo capaz de capturar paquetes relacionados con la privacidad en el aire, pero se señala que los sniffers open source existentes no cumplen ese requisito porque no pueden decodificar los paquetes de protocolo de PDSCH y PUSCH
  • Los detalles están resumidos en el paper
  • El objetivo principal de LTESniffer es apoyar la investigación de seguridad y análisis de redes celulares
    • Como recolecta datos de usuario en enlace ascendente y descendente, se deben seguir las regulaciones locales sobre sniffing de tráfico LTE
    • Los desarrolladores no se hacen responsables del uso con fines ilegales, como la recolección intencional de información relacionada con la privacidad de los usuarios

Funciones soportadas y base de implementación

  • LTESniffer está implementado sobre FALCON y usa la biblioteca srsRAN
  • Su alcance principal de soporte es el siguiente
    • Decodificación en tiempo real de subida y bajada de los canales de control y datos PDCCH, PDSCH, PUSCH
    • LTE Advanced y LTE Advanced Pro
    • Hasta 256QAM tanto en subida como en bajada
    • Formatos DCI 0, 1A, 1, 1B, 1C, 2, 2A, 2B
    • Modos de transmisión 1, 2, 3, 4

    • Solo soporta FDD

      • Estaciones base de hasta 20MHz
      • Detección automática del esquema máximo de modulación UL/DL por smartphone
      • Detección automática de la configuración de capa física por UE
      • RNTI-TMSI mapping, IMSI collecting, UE Capability Profiling
      • La actualización v2.1.0 agrega escritura de archivos de IQ raw data por subtrama, decodificación offline usando esos archivos grabados y activación de la API en modo de enlace descendente
      • La API del modo de enlace descendente solo aplica a las API de identity collecting y mapping
      • La información relacionada está en la rama LTESniffer-record-subframe y el README
      • La actualización v2.0.0 agrega soporte para usar dos USRP B-series en modo de sniffing de enlace ascendente y corrige errores
      • La información relacionada está en la rama LTESniffer-multi-usrp y el README

Requisitos de hardware y software

  • El sistema operativo estable es Ubuntu 18.04/20.04/22.04
  • La decodificación en tiempo real de tráfico LTE requiere una CPU potente con múltiples núcleos físicos durante horas pico cuando hay muchos usuarios activos en la estación base
    • Hay un caso de decodificación en tiempo real del tráfico de una estación base con 150 usuarios activos en una PC Intel i7-9700K
    • La especificación recomendada es una CPU Intel i7 con 8 o más núcleos físicos, 16GB o más de RAM y SSD de 256GB
  • Para sniffing solo de enlace descendente, se puede usar la mayoría de los SDR soportados por srsRAN
    • Por ejemplo, USRP o BladeRF
    • El SDR debe estar conectado a la PC por USB 3.0
    • Para decodificar mensajes de enlace descendente en modos de transmisión 3 y 4 se necesitan 2 antenas RX
    • Si solo hay 1 antena RX, solo se decodifican mensajes de enlace descendente en modo de transmisión 1
    • El GPSDO ayuda a mejorar la sincronización en el sniffing de enlace descendente, pero no es obligatorio
  • El sniffing de enlace ascendente necesita escuchar dos frecuencias al mismo tiempo, la de subida y la de bajada, por lo que se soportan dos configuraciones
    • USRP X310 único: sus 2 canales RX pueden sintonizarse a distintas frecuencias de enlace ascendente y descendente, y el GPSDO es opcional
    • 2 USRP B-Series: se usa un B210/B200 para enlace ascendente y otro para descendente, y se usa GPSDO como clock source y time reference para sincronizar ambos USRP
    • En la configuración con 2 USRP B-Series, el GPSDO es obligatorio

Instalación y flujo de ejecución

  • Antes de compilar el código fuente se requiere instalar UHD 4.0 o superior, y se recomienda compilar desde código fuente
  • Después de instalar las dependencias de srsRAN y de LTESniffer, se clona el repositorio y se compila con cmake y make -j 4
  • Tras la compilación, el ejecutable se ubica en <build-dir>/src/LTESniffer
  • Hay 3 modos principales de ejecución
    • Sniffing del tráfico LTE de enlace descendente que viene desde la estación base
    • Sniffing del tráfico LTE de enlace ascendente que va del smartphone a la estación base
    • API de seguridad
  • Antes de usarlo en una red comercial, se deben revisar las regulaciones locales sobre sniffing de tráfico LTE
  • Para verificar la estación base a la que está conectado el smartphone de prueba y las bandas de enlace ascendente y descendente, se puede usar Cellular-Z para Android
    • LTESniffer también debe conectarse a la misma celda y frecuencia

Salida y análisis

  • LTESniffer entrega como salida archivos pcap, que pueden analizarse más a fondo y seguir paquetes en Wireshark
  • El nombre del archivo generado cambia según el modo
    • Enlace descendente: sniffer_dl_mode.pcap
    • Enlace ascendente: sniffer_ul_mode.pcap
    • API: api_collector.pcap
  • Los archivos pcap se generan en el mismo directorio donde se ejecutó LTESniffer
  • Para que Wireshark analice correctamente los paquetes decodificados, se debe consultar la guía de configuración en pcap_file_example/README.md
  • El archivo pcap de enlace ascendente incluye tanto mensajes de subida como de bajada
    • Para ver solo el tráfico ascendente, usa el filtro mac-lte.direction == 0
    • Para ver solo el tráfico descendente, usa el filtro mac-lte.direction == 1

Restricciones de distancia en el sniffing de enlace ascendente

  • El alcance efectivo de enlace ascendente de LTESniffer está limitado por el rendimiento del front-end RF, como el SDR
  • Como el UE es un dispositivo portátil que optimiza el uso de batería, la potencia de su señal ascendente es mucho menor que la de la señal descendente de la estación base
  • Para capturar con éxito tráfico ascendente, se puede aumentar la potencia de la señal recibida de las siguientes maneras
    • Ubicarse físicamente cerca del UE
    • Usar hardware especializado como antenas direccionales, front-end RF dedicado o amplificadores de señal

Limitaciones y alternativas indicadas en el FAQ

  • El GPSDO es útil para una sincronización más estable, pero en el sniffing de enlace descendente se pueden decodificar paquetes sincronizándose con la señal LTE incluso sin GPSDO
  • En el sniffing de enlace ascendente, el GPSDO solo se necesita cuando se usan 2 USRP B-series
    • La configuración con un solo USRP X310 no requiere GPSDO
  • El tráfico de enlace descendente también puede ejecutarse técnicamente con SDR como BladeRF soportados por la biblioteca srsRAN
    • Sin embargo, las funciones de enlace descendente de LTESniffer solo se probaron con USRP B210 y X310
  • La legalidad del uso de LTESniffer requiere revisar las regulaciones locales sobre sniffing de tráfico LTE no cifrado
    • Como método alternativo de prueba, se propone construir una red LTE privada basada en srsRAN dentro de una jaula de Faraday
  • En el contenido de los mensajes entre dos usuarios, solo pueden verse las partes no cifradas
    • La mayor parte del tráfico inalámbrico entre la estación base y el usuario está cifrada
  • En la literatura sobre redes LTE aparecen varios identificadores expuestos en texto plano, como TMSI, GUTI, IMSI y RNTI

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-10-23
Opiniones en Hacker News

  • Me encanta que los estándares de redes móviles estén llenos de siglas.
    Por si no lo sabías, la Q de PHICH significa "request".

    • Para quien se pregunte de qué hablan arriba: PHICH no aparece en el proyecto referenciado, pero es un ejemplo de sigla rara de redes móviles; significa "Physical channel HybridARQ Indicator Channel".
      Ahí, "ARQ" probablemente se puede expandir como https://en.wikipedia.org/wiki/Automatic_repeat_request
      Algunos podrían decir que la "Q" de "ARQ" en realidad significa "query", y que quienes la expanden como "request" están subestimando el nivel promedio de vocabulario.
      Personalmente, pensándolo bien, creo que es más probable que la Q no sea ni "request" ni "query", sino otra huella de los códigos Q convencionalmente opacos de https://en.wikipedia.org/wiki/Q_code
    • Pensé que era una broma.
      Aquí está la Q dentro de PHICH: https://github.com/srsran/srsRAN_4G/blob/master/lib/src/phy/...
      Como dice el comentario hermano, q es la Q de reQuest.

  • Se ve bien.
    Tiene algunas limitaciones: solo soporta FDD, no TDD, y está limitado a 20 MHz.
    Parece que también permite cierto grado de decodificación en tiempo real, lo cual es interesante. En la estación base, gran parte del procesamiento lo hace un procesador bastante de propósito general, pero aun así está mucho más integrado con el hardware que este software.

  • Es una lástima que el hardware para correr esto sea demasiado caro :'(

  • Un poco tangencial, pero me pregunto si alguien ha intentado hacer escucha de DSL.
    El DSL moderno, especialmente VDSL2, es básicamente una señal de alta frecuencia que viaja por un par trenzado sin blindaje, así que si hay derivaciones en la línea y cosas por el estilo, debería fugarse e irradiarse fácilmente.
    De hecho, parece ser así hasta el punto de que los radioaficionados del Reino Unido se quejan bastante de ello[1]. Me pregunto si esa señal todavía se puede demodular, o si en el espectro no es más que un ruido de fondo molesto.
    [1]: https://rsgb.services/public/publications/vdsl/measuring_and...

  • Un dato interesante y poco conocido es que las primeras generaciones de celulares digitales están en una zona gris de dificultad de descifrado.
    No es nada fácil, pero sí lo bastante fácil como para romperlo. El cifrado de hecho fue roto.
    Las tablas arcoíris ocupan 2 TB y tomó meses crearlas: https://github.com/0xh4di/GSMDecryption?tab=readme-ov-file
    Ahora me pregunto si generaciones posteriores también tienen algunos huecos de descifrado, por una u otra razón o por ciertos actores estatales.

  • Trabajo interesante, y da gusto ver que todavía se use este tipo de open source.
    Hace unos 10 años hicimos escucha de downlink en el laboratorio de seguridad de redes de mi universidad.
    Uno de los proyectos era medir cuánto bajaba la actividad celular durante las vacaciones de primavera, y otro era ver si, para un número telefónico conocido en una ubicación conocida, se podía hacer un ataque de temporización para extraer el ID temporal y luego usar llamadas repetidas para comprobar si seguía en la zona.
    En mi opinión, ese ID temporal no era lo suficientemente temporal. Me dan ganas de volver a meterle mano.

  • También hay dongles 4G con modos de depuración rotos conocidos que se pueden usar para extraer información.

  • LTESniffer dice ser open source, pero no parece tener un archivo LICENSE en el nivel superior ni configuración de licencia en el repositorio de GitHub.

    • La mayoría de los archivos fuente tienen encabezados de copyright que dicen que el código es AGPLv3 y que fue bifurcado de proyectos existentes con archivo LICENSE en el nivel superior: https://github.com/falkenber9/falcon y https://github.com/srsran/srsRAN_Project
      Para cubrir también los archivos de build y otros archivos de soporte, lo correcto sería agregar un archivo LICENSE en el nivel superior.