
Un espía de enlace descendente/ascendente LTE de código abierto
LTESniffer es un espía de enlace descendente/ascendente LTE de código abierto.
Primero decodifica el Canal de Control de Enlace Descendente Físico (PDCCH) para obtener las Informaciones de Control de Enlace Descendente (DCI) y los Identificadores Temporales de Red de Radio (RNTI) de todos los usuarios activos. Usando las DCI y los RNTI decodificados, LTESniffer decodifica además el Canal Compartido de Enlace Descendente Físico (PDSCH) y el Canal Compartido de Enlace Ascendente Físico (PUSCH) para recuperar el tráfico de datos de enlace ascendente y descendente.
LTESniffer soporta una API con tres funciones para aplicaciones e investigación en seguridad. Muchas investigaciones de seguridad en LTE asumen un sniffer pasivo que pueda capturar paquetes relacionados con la privacidad en el aire. Sin embargo, ninguno de los sniffers de código abierto actuales satisface sus requisitos, ya que no pueden decodificar paquetes de protocolo en PDSCH y PUSCH. Desarrollamos una API de seguridad de prueba de concepto que soporta tres tareas propuestas por trabajos anteriores: 1) Mapeo de identidad, 2) Recolección de IMSI y 3) Perfilado de capacidades.
Consulte nuestro artículo para más detalles.
LTESniffer es una herramienta que puede capturar los mensajes inalámbricos LTE enviados entre una torre celular y los teléfonos inteligentes conectados a ella. LTESniffer permite capturar los mensajes en ambas direcciones: desde la torre hacia los teléfonos inteligentes y desde los teléfonos inteligentes de vuelta a la torre celular.
LTESniffer NO PUEDE DESCIFRAR mensajes cifrados entre la torre celular y los teléfonos inteligentes. Puede utilizarse para analizar las partes no cifradas de la comunicación entre la torre celular y los teléfonos inteligentes. Por ejemplo, en el caso de mensajes cifrados, permite al usuario analizar partes no cifradas, como las cabeceras en las capas MAC y física. Sin embargo, aquellos mensajes enviados en texto plano pueden analizarse por completo. Por ejemplo, los mensajes de difusión enviados por la torre celular, o los mensajes al inicio de la conexión, son completamente visibles.
El propósito principal de LTESniffer es apoyar la investigación en seguridad y análisis de la red celular. Debido a la recolección de datos de usuario de enlace ascendente-descendente, cualquier uso de LTESniffer debe cumplir con las regulaciones locales sobre la interceptación (sniffing) del tráfico LTE. No somos responsables de ningún uso ilegal, como la recolección intencional de información relacionada con la privacidad del usuario.
LTESniffer-record-subframe y su README para más detalles.LTESniffer-multi-usrp y su README para más detalles.LTESniffer está implementado sobre FALCON con la ayuda de la librería srsRAN. LTESniffer soporta:
Actualmente, LTESniffer funciona de manera estable en Ubuntu 18.04/20.04/22.04.
Lograr la decodificación en tiempo real del tráfico LTE requiere una CPU de alto rendimiento con múltiples núcleos físicos, especialmente durante las horas pico cuando la estación base tiene muchos usuarios activos. LTESniffer logró decodificación en tiempo real al ser desplegado en una PC con Intel i7-9700K, decodificando el tráfico de una estación base con 150 usuarios activos.
Se recomienda el siguiente hardware
LTESniffer requiere diferentes SDR para sus modos de interceptación de enlace ascendente y descendente.
Para interceptar solo el tráfico de enlace descendente de la estación base, LTESniffer es compatible con la mayoría de los SDR soportados por la librería srsRAN (por ejemplo, USRP o BladeRF). El SDR debe conectarse a la PC mediante un puerto USB 3.0. Además, debe estar equipado con dos antenas RX para decodificar mensajes de enlace descendente en los modos de transmisión 3 y 4. Si su SDR solo tiene una antena RX, LTESniffer solo decodificará mensajes de enlace descendente en el modo de transmisión 1. Tenga en cuenta que GPSDO es opcional para la interceptación de enlace descendente; ayudará a mejorar la sincronización pero no es obligatorio.
Por otro lado, para interceptar el tráfico de enlace ascendente desde los teléfonos inteligentes hacia las estaciones base, LTESniffer necesita escuchar dos frecuencias diferentes (Enlace Ascendente y Descendente) de forma concurrente. Para resolver este problema, LTESniffer soporta dos opciones:
main de LTESniffer.LTESniffer-multi-usrp de LTESniffer y su README.Nota importante: Para evitar errores inesperados, siga los siguientes pasos en Ubuntu 18.04/20.04/22.04.
Dependencias
Dependencias de UHD:
sudo apt update
sudo apt-get install autoconf automake build-essential ccache cmake cpufrequtils doxygen ethtool \
g++ git inetutils-tools libboost-all-dev libncurses5 libncurses5-dev libusb-1.0-0 libusb-1.0-0-dev \
libusb-dev python3-dev python3-mako python3-numpy python3-requests python3-scipy python3-setuptools \
python3-ruamel.yaml
Clone y compile UHD desde el código fuente (asegúrese de que la rama actual sea superior a 4.0)
git clone https://github.com/EttusResearch/uhd.git
cd <uhd-repo-path>/host
mkdir build
cd build
cmake ../
make -j 4
make test
sudo make install
sudo ldconfig
Descargue los firmware para USRP:
sudo uhd_images_downloader
Usamos una tarjeta de 10Gb para conectar el USRP X310 a la PC; consulte el Manual de UHD [1], [2] para configurar el USRP X310 y la interfaz de la tarjeta de 10Gb. Para el USRP B210, debe conectarse a la PC mediante un puerto USB 3.0.
Pruebe la conexión y el firmware (solo para USRP X310):
sudo sysctl -w net.core.rmem_max=33554432
sudo sysctl -w net.core.wmem_max=33554432
sudo ifconfig <10Gb card interface> mtu 9000
sudo uhd_usrp_probe
sudo apt-get install build-essential git cmake libfftw3-dev libmbedtls-dev libboost-program-options-dev libconfig++-dev libsctp-dev
sudo apt-get install libglib2.0-dev libudev-dev libcurl4-gnutls-dev libboost-all-dev qtdeclarative5-dev libqt5charts5-dev
Compile LTESniffer desde el código fuente:
git clone https://github.com/SysSec-KAIST/LTESniffer.git
cd LTESniffer
mkdir build
cd build
cmake ../
make -j 4 (use 4 threads)
LTESniffer tiene 3 funciones principales:
Después de compilar desde el código fuente, LTESniffer se encuentra en <build-dir>/src/LTESniffer
Tenga en cuenta que antes de usar LTESniffer en una red comercial, se debe verificar las regulaciones locales sobre la interceptación de tráfico LTE, como explicamos en Consideración Ética.
Para averiguar la estación base y la banda de enlace ascendente-descendente a la que está conectado el teléfono inteligente de prueba, instale la aplicación Cellular-Z en el teléfono (la aplicación solo es compatible con Android). Esta mostrará el ID de celda y la banda/frecuencia de enlace ascendente-descendente a la que está conectado el teléfono de prueba. Asegúrese de que LTESniffer también se conecte a la misma celda y frecuencia.
sudo ./<build-dir>/src/LTESniffer -A 2 -W <number of threads> -f <DL Freq> -C -m 0
example: sudo ./src/LTESniffer -A 2 -W 4 -f 1840e6 -C -m 0
-A: number of antennas
-W: number of threads
-f: downlink frequency
-C: turn on cell search
-m: sniffer mode, 0 for downlink sniffing and 1 for uplink sniffing
Nota: para ejecutar LTESniffer con USRP B210 en el modo de enlace descendente, agregue la opción -a "num_recv_frames=512" a la línea de comandos.
Esta opción amplía el búfer de recepción para USRP B210 y así lograr una mejor sincronización.
sudo ./<build-dir>/src/LTESniffer -A 2 -W <number of threads> -f <DL Freq> -C -m 0 -a "num_recv_frames=512"
example: sudo ./src/LTESniffer -A 2 -W 4 -f 1840e6 -C -m 0 -a "num_recv_frames=512"
Nota: En el modo de interceptación de enlace ascendente, los teléfonos inteligentes de prueba deben ubicarse cerca del sniffer, porque la potencia de la señal de enlace ascendente del UE es significativamente más débil en comparación con la señal de enlace descendente de la estación base.
sudo ./<build-dir>/src/LTESniffer -A 2 -W <number of threads> -f <DL Freq> -u <UL Freq> -C -m 1
example: sudo ./src/LTESniffer -A 2 -W 4 -f 1840e6 -u 1745e6 -C -m 1
-u: uplink frequency
sudo ./<build-dir>/src/LTESniffer -A 2 -W <number of threads> -f <DL Freq> -u <UL Freq> -C -m 1 -z 3
example: sudo ./src/LTESniffer -A 2 -W 4 -f 1840e6 -u 1745e6 -C -m 1 -z 3
-z: 3 for turnning on 3 functions of sniffer, which are identity mapping, IMSI collecting, and UECapability profiling.
2 for UECapability profiling
1 for IMSI collecting
0 for identity mapping
LTESniffer puede interceptar una estación base específica usando las opciones -I <ID de Celda Física (PCI)> -p <número de Bloque de Recursos Físicos (PRB)>. En este caso, LTESniffer no realiza la búsqueda de celda, sino que se conecta directamente a la celda especificada.
sudo ./<build-dir>/src/LTESniffer -A 2 -W <number of threads> -f <DL Freq> -I <PCI> -p <PRB> -m 0
sudo ./<build-dir>/src/LTESniffer -A 2 -W <number of threads> -f <DL Freq> -u <UL Freq> -I <PCI> -p <PRB> -m 1
example: sudo ./src/LTESniffer -A 2 -W 4 -f 1840e6 -u 1745e6 -I 379 -p 100 -m 1
El modo de depuración se puede habilitar usando la opción -d. En este caso, los mensajes de depuración se imprimirán en la terminal.
LTESniffer proporciona archivos pcap en la salida. El archivo pcap se puede abrir con WireShark para un análisis más detallado y rastreo de paquetes.
El nombre del archivo pcap de enlace descendente es: sniffer_dl_mode.pcap, el de enlace ascendente: sniffer_ul_mode.pcap y el de la API: api_collector.pcap.
Los archivos pcap se encuentran en el mismo directorio donde se ejecutó LTESniffer.
Para que WireShark analice correctamente los paquetes decodificados, consulte la guía de configuración de WireShark aquí. También hay algunos ejemplos de archivos pcap en el enlace.
Nota: El archivo pcap de enlace ascendente contiene tanto mensajes de enlace ascendente como descendente. En WireShark, use este filtro para monitorear solo mensajes de enlace ascendente: mac-lte.direction == 0; o este filtro para monitorear solo mensajes de enlace descendente: mac-lte.direction == 1.
El rango efectivo para la interceptación del enlace ascendente es limitado en LTESniffer debido a la capacidad del front-end de RF del hardware (es decir, el SDR). La potencia de la señal de enlace ascendente del UE es significativamente más débil en comparación con la señal de enlace descendente, porque el UE es un dispositivo de mano que optimiza el uso de la batería, mientras que el eNB usa suficiente potencia para cubrir un área amplia. Para capturar con éxito el tráfico de enlace ascendente, LTESniffer puede aumentar la intensidad de la señal mediante i) acercarse físicamente al UE, o ii) mejorar la capacidad de recepción de señal con hardware especializado, como una antena direccional, un front-end de RF dedicado y un amplificador de señal.
Modo de interceptación de enlace descendente
Processed 1000/1000 subframes: Número de subtramas procesadas por LTESniffer en el último segundo. Hay 1000 subtramas LTE por segundo por diseño.
RNTI: Identificador Temporal de Red de Radio de los UE.
Table: El esquema de modulación máximo utilizado por los teléfonos inteligentes en el enlace descendente. LTESniffer soporta hasta 256QAM en el enlace descendente. Consulte nuestro artículo para más detalles.
Active: Número de mensajes detectados de RNTI.
Success: Número de mensajes decodificados con éxito sobre el número de mensajes detectados (Active).
New TX, ReTX, HARQ, Normal: Estadística de mensajes nuevos y mensajes retransmitidos. Esta función está en desarrollo.
W_MIMO, W_pinfor, Other: Número de mensajes con configuración de radio incorrecta, solo para depuración.
Modo de interceptación de enlace ascendente
Max Mod: El esquema de modulación máximo utilizado por los teléfonos inteligentes en el enlace ascendente. Puede ser 16/64/256QAM dependiendo del soporte de los teléfonos y de la configuración de la red. Consulte nuestro artículo para más detalles.
SNR: Relación señal-ruido (dB). Un SNR bajo significa que la calidad de la señal de enlace ascendente del teléfono inteligente es mala. Una posible razón es que el teléfono esté lejos del sniffer.
DL-UL_delay: El promedio del retardo de tiempo entre la señal de enlace descendente de la estación base y la señal de enlace ascendente del teléfono inteligente.
Other Info: Información solo para depuración.
Modo API
Detected Identity: El nombre de la identidad detectada.
Value: El valor de la identidad detectada.
From Message: El nombre del mensaje que contiene la identidad detectada.
Agradecemos sinceramente al FALCON y al equipo SRS por poner a disposición sus excelentes programas.
Un agradecimiento especial a todos los colaboradores que nos ayudaron a corregir errores y mejorar LTESniffer
Consulte nuestro artículo para más detalles.
@inproceedings{hoang:ltesniffer,
title = {{LTESniffer: An Open-source LTE Downlink/Uplink Eavesdropper}},
author = {Hoang, Dinh Tuan and Park, CheolJun and Son, Mincheol and Oh, Taekkyung and Bae, Sangwook and Ahn, Junho and Oh, BeomSeok and Kim, Yongdae},
booktitle = {16th ACM Conference on Security and Privacy in Wireless and Mobile Networks (WiSec '23)},
year = {2023}
}
P: ¿Es obligatorio usar GPSDO con el USRP para ejecutar LTESniffer?
R: GPSDO es útil para una sincronización más estable. Sin embargo, para el modo de interceptación de enlace descendente, LTESniffer aún puede sincronizarse con la señal LTE para decodificar los paquetes sin GPSDO. Para el modo de interceptación de enlace ascendente, GPSDO solo se requiere cuando se usan 2 USRP de la serie B, ya que es la fuente de referencia de tiempo y reloj para la sincronización entre los canales de enlace ascendente y descendente. Otra opción de SDR para enlace ascendente, usando un solo USRP X310, no requiere GPSDO.
P: Para el tráfico de enlace descendente, ¿puedo usar un SDR más económico?
R: Técnicamente, cualquier SDR soportado por la librería srsRAN, como Blade RF, puede usarse para ejecutar LTESniffer en el modo de interceptación de enlace descendente. Sin embargo, solo probamos la función de interceptación de enlace descendente de LTESniffer con USRP B210 y X310.
P: ¿Es ilegal usar LTESniffer para interceptar el tráfico LTE?
R: Debe verificar las regulaciones locales sobre la interceptación de tráfico LTE (no cifrado). Otra forma de probar LTESniffer es configurar una red LTE personal usando srsRAN, una implementación LTE de código abierto, dentro de una jaula de Faraday.
P: ¿Puede LTESniffer usarse para ver el contenido de los mensajes entre dos usuarios?
R: Solo se puede ver la parte "no cifrada" de los mensajes. Tenga en cuenta que el tráfico inalámbrico entre la estación base y los usuarios está mayormente cifrado.
P: ¿Hay alguna identidad de dispositivo expuesta en texto plano en la red LTE?
R: Sí, la literatura muestra que hay múltiples identidades expuestas, como TMSI, GUTI, IMSI y RNTI. Consulte la literatura académica para más detalles. Por ejemplo, Watching the Watchers: Practical Video Identification Attack in LTE Networks