syssec-kaist/ltesnifferUn outil open-source d'écoute LTE (liaison descendante/montante)
LTESniffer est un espion LTE open-source pour liaison descendante et montante.
Il décode d'abord le canal de contrôle physique descendant (PDCCH) pour obtenir les informations de contrôle descendant (DCI) et les identifiants temporaires de réseau radio (RNTI) de tous les utilisateurs actifs. À l'aide des DCI et RNTI décodés, LTESniffer décode ensuite le canal partagé physique descendant (PDSCH) et le canal partagé physique montant (PUSCH) pour récupérer le trafic de données montant et descendant.
LTESniffer prend en charge une API avec trois fonctions pour la recherche et les applications de sécurité. De nombreuses recherches en sécurité LTE supposent un renifleur passif capable de capturer les paquets liés à la vie privée sur les ondes. Cependant, aucun des renifleurs open-source actuels ne répond à leurs exigences car ils ne peuvent pas décoder les paquets de protocole dans PDSCH et PUSCH. Nous avons développé une API de sécurité de preuve de concept qui prend en charge trois tâches proposées par des travaux antérieurs : 1) Mappage d'identités, 2) Collecte d'IMSI, et 3) Profilage de capacités.
Veuillez consulter notre article pour plus de détails.
LTESniffer est un outil capable de capturer les messages sans fil LTE envoyés entre une station de base et les smartphones qui y sont connectés. LTESniffer prend en charge la capture des messages dans les deux sens, de la station de base vers les smartphones, et des smartphones vers la station de base.
LTESniffer NE PEUT PAS DÉCRYPTER les messages chiffrés entre la station de base et les smartphones. Il peut être utilisé pour analyser les parties non chiffrées de la communication entre la station de base et les smartphones. Par exemple, pour les messages chiffrés, il peut permettre à l'utilisateur d'analyser les parties non chiffrées, comme les en-têtes des couches MAC et physique. Cependant, les messages envoyés en clair peuvent être complètement analysables. Par exemple, les messages de diffusion envoyés par la station de base, ou les messages au début de la connexion sont entièrement visibles.
Le but principal de LTESniffer est de soutenir la recherche en sécurité et en analyse sur le réseau cellulaire. En raison de la collecte de données utilisateur montantes et descendantes, toute utilisation de LTESniffer doit respecter les réglementations locales concernant le reniflage du trafic LTE. Nous ne sommes pas responsables des utilisations illégales telles que la collecte intentionnelle d'informations personnelles des utilisateurs.
LTESniffer-record-subframe et son README pour plus de détails.LTESniffer-multi-usrp et son README pour plus de détails.LTESniffer est implémenté sur la base de FALCON avec l'aide de la bibliothèque srsRAN. LTESniffer prend en charge :
Actuellement, LTESniffer fonctionne de manière stable sous Ubuntu 18.04/20.04/22.04.
Pour un décodage en temps réel du trafic LTE, un processeur hautes performances avec plusieurs cœurs physiques est nécessaire, surtout pendant les heures de pointe où la station de base a de nombreux utilisateurs actifs. LTESniffer a réussi un décodage en temps réel sur un PC Intel i7-9700K, en décodant le trafic d'une station de base avec 150 utilisateurs actifs.
Le matériel suivant est recommandé
LTESniffer nécessite des SDR différentes pour ses modes de reniflage montant et descendant.
Pour ne renifler que le trafic descendant de la station de base, LTESniffer est compatible avec la plupart des SDR prises en charge par la bibliothèque srsRAN (par exemple, USRP ou BladeRF). La SDR doit être connectée au PC via un port USB 3.0. De plus, elle doit être équipée de deux antennes RX pour décoder les messages descendants dans les modes de transmission 3 et 4. Si votre SDR n'a qu'une seule antenne RX, LTESniffer ne décodera que les messages descendants en mode de transmission 1. Notez que le GPSDO est optionnel pour le reniflage descendant ; il aide à améliorer la synchronisation mais n'est pas obligatoire.
D'autre part, pour renifler le trafic montant des smartphones vers les stations de base, LTESniffer doit écouter deux fréquences différentes (montante et descendante) simultanément. Pour résoudre ce problème, LTESniffer prend en charge deux options :
main de LTESniffer.LTESniffer-multi-usrp de LTESniffer et à son README.Remarque importante : pour éviter des erreurs inattendues, veuillez suivre les étapes suivantes sur Ubuntu 18.04/20.04/22.04.
Dépendances
Dépendances 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
Cloner et compiler UHD à partir des sources (assurez-vous que la branche actuelle est supérieure à 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
Télécharger les firmware pour les USRP :
sudo uhd_images_downloader
Nous utilisons une carte 10Gb pour connecter l'USRP X310 au PC, référez-vous au manuel UHD [1], [2] pour configurer l'USRP X310 et l'interface de la carte 10Gb. Pour l'USRP B210, il doit être connecté au PC via un port USB 3.0.
Testez la connexion et le firmware (pour USRP X310 uniquement) :
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
Compiler LTESniffer à partir des sources :
git clone https://github.com/SysSec-KAIST/LTESniffer.git
cd LTESniffer
mkdir build
cd build
cmake ../
make -j 4 (utiliser 4 threads)
LTESniffer a 3 fonctions principales :
Après compilation, LTESniffer se trouve dans <build-dir>/src/LTESniffer
Notez qu'avant d'utiliser LTESniffer sur un réseau commercial, il faut vérifier les réglementations locales concernant le reniflage du trafic LTE, comme expliqué dans la Considération éthique.
Pour déterminer la station de base et la bande montante/descendante à laquelle le smartphone de test est connecté, installez l'application Cellular-Z sur le smartphone de test (l'application ne prend en charge qu'Android). Elle affichera l'ID de cellule et la bande/fréquence montante/descendante à laquelle le smartphone de test est connecté. Assurez-vous que LTESniffer se connecte également à la même cellule et à la même fréquence.
sudo ./<build-dir>/src/LTESniffer -A 2 -W <nombre de threads> -f <Fréq DL> -C -m 0
exemple : sudo ./src/LTESniffer -A 2 -W 4 -f 1840e6 -C -m 0
-A : nombre d'antennes
-W : nombre de threads
-f : fréquence descendante
-C : activer la recherche de cellule
-m : mode du renifleur, 0 pour le reniflage descendant et 1 pour le reniflage montant
Remarque : pour exécuter LTESniffer avec USRP B210 en mode descendant, ajoutez l'option -a "num_recv_frames=512" à la ligne de commande.
Cette option étend le tampon de réception pour l'USRP B210 afin d'obtenir une meilleure synchronisation.
sudo ./<build-dir>/src/LTESniffer -A 2 -W <nombre de threads> -f <Fréq DL> -C -m 0 -a "num_recv_frames=512"
exemple : sudo ./src/LTESniffer -A 2 -W 4 -f 1840e6 -C -m 0 -a "num_recv_frames=512"
Remarque : en mode reniflage montant, les smartphones de test doivent se trouver à proximité du renifleur, car la puissance du signal montant provenant de l'UE est significativement plus faible que celle du signal descendant de la station de base.
sudo ./<build-dir>/src/LTESniffer -A 2 -W <nombre de threads> -f <Fréq DL> -u <Fréq UL> -C -m 1
exemple : sudo ./src/LTESniffer -A 2 -W 4 -f 1840e6 -u 1745e6 -C -m 1
-u : fréquence montante
sudo ./<build-dir>/src/LTESniffer -A 2 -W <nombre de threads> -f <Fréq DL> -u <Fréq UL> -C -m 1 -z 3
exemple : sudo ./src/LTESniffer -A 2 -W 4 -f 1840e6 -u 1745e6 -C -m 1 -z 3
-z : 3 pour activer les 3 fonctions du renifleur, à savoir le mappage d'identités, la collecte d'IMSI et le profilage de capacités UE.
2 pour le profilage de capacités UE
1 pour la collecte d'IMSI
0 pour le mappage d'identités
LTESniffer peut renifler sur une station de base spécifique en utilisant les options -I <ID physique de cellule (PCI)> -p <nombre de blocs de ressources physiques (PRB)>. Dans ce cas, LTESniffer n'effectue pas la recherche de cellule mais se connecte directement à la cellule spécifiée.
sudo ./<build-dir>/src/LTESniffer -A 2 -W <nombre de threads> -f <Fréq DL> -I <PCI> -p <PRB> -m 0
sudo ./<build-dir>/src/LTESniffer -A 2 -W <nombre de threads> -f <Fréq DL> -u <Fréq UL> -I <PCI> -p <PRB> -m 1
exemple : sudo ./src/LTESniffer -A 2 -W 4 -f 1840e6 -u 1745e6 -I 379 -p 100 -m 1
Le mode débogage peut être activé avec l'option -d. Dans ce cas, les messages de débogage seront affichés sur le terminal.
LTESniffer fournit des fichiers pcap en sortie. Le fichier pcap peut être ouvert avec WireShark pour une analyse plus approfondie et un traçage des paquets.
Le nom du fichier pcap descendant : sniffer_dl_mode.pcap, fichier pcap montant : sniffer_ul_mode.pcap, et fichier pcap API : api_collector.pcap.
Les fichiers pcap se trouvent dans le même répertoire où LTESniffer a été exécuté.
Pour permettre à WireShark d'analyser correctement les paquets décodés, veuillez consulter le guide de configuration WireShark ici. Il y a également quelques exemples de fichiers pcap dans le lien.
Remarque : Le fichier pcap montant contient à la fois les messages montants et descendants. Dans WireShark, utilisez ce filtre pour surveiller uniquement les messages montants : mac-lte.direction == 0 ; ou ce filtre pour surveiller uniquement les messages descendants : mac-lte.direction == 1.
La portée effective pour le reniflage montant est limitée dans LTESniffer en raison des capacités de la partie frontale RF du matériel (c'est-à-dire la SDR). La puissance du signal montant provenant de l'UE est significativement plus faible que celle du signal descendant, car l'UE est un appareil portable qui optimise l'utilisation de la batterie, tandis que l'eNB utilise une puissance suffisante pour couvrir une grande zone. Pour capturer avec succès le trafic montant, LTESniffer peut augmenter la force du signal en i) étant physiquement proche de l'UE, ou ii) en améliorant la capacité de réception du signal avec du matériel spécialisé, tel qu'une antenne directionnelle, un front-end RF dédié et un amplificateur de signal.
Mode reniflage descendant
Processed 1000/1000 subframes : Nombre de sous-trames traitées par LTESniffer la dernière seconde. Il y a 1000 sous-trames LTE par seconde par conception.
RNTI : Identifiant temporaire de réseau radio des UE.
Table : Le schéma de modulation maximal utilisé par les smartphones en liaison descendante. LTESniffer prend en charge jusqu'à 256QAM en liaison descendante. Référez-vous à notre article pour plus de détails.
Active : Nombre de messages détectés des RNTI.
Success : Nombre de messages décodés avec succès par rapport au nombre de messages détectés (Active).
New TX, ReTX, HARQ, Normal : Statistiques des nouveaux messages et des messages retransmis. Cette fonction est en cours de développement.
W_MIMO, W_pinfor, Other : Nombre de messages avec une mauvaise configuration radio, uniquement pour le débogage.
Mode reniflage montant
Max Mod : Le schéma de modulation maximal utilisé par les smartphones en liaison montante. Il peut être 16/64/256QAM selon le support des smartphones et la configuration du réseau. Référez-vous à notre article pour plus de détails.
SNR : Rapport signal sur bruit (dB). Un SNR faible signifie que la qualité du signal montant provenant du smartphone est mauvaise. Une raison possible est que le smartphone est loin du renifleur.
DL-UL_delay : La moyenne du délai entre le signal descendant de la station de base et le signal montant du smartphone.
Other Info : Informations uniquement pour le débogage.
Mode API
Detected Identity : Le nom de l'identité détectée.
Value : La valeur de l'identité détectée.
From Message : Le nom du message qui contient l'identité détectée.
Nous remercions sincèrement l'équipe FALCON et l'équipe SRS pour avoir mis à disposition leurs excellents logiciels.
Un grand merci à tous les contributeurs qui nous ont aidés à corriger des bugs et à améliorer LTESniffer
Veuillez consulter notre article pour plus de détails.
@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}
}
Q: Est-il obligatoire d'utiliser un GPSDO avec l'USRP pour exécuter LTESniffer ?
R: Le GPSDO est utile pour une synchronisation plus stable. Cependant, pour le mode reniflage descendant, LTESniffer peut toujours se synchroniser avec le signal LTE pour décoder les paquets sans GPSDO. Pour le mode reniflage montant, le GPSDO n'est requis que lors de l'utilisation de 2 USRP série B, car il constitue la source d'horloge et de référence temporelle pour la synchronisation entre les canaux montant et descendant. L'autre option SDR montante, utilisant un seul USRP X310, ne nécessite pas de GPSDO.
Q: Pour le trafic descendant, puis-je utiliser une SDR moins chère ?
R: Techniquement, toute SDR prise en charge par la bibliothèque srsRAN, comme Blade RF, peut être utilisée pour exécuter LTESniffer en mode reniflage descendant. Cependant, nous n'avons testé la fonction de reniflage descendant de LTESniffer qu'avec USRP B210 et X310.
Q: Est-il illégal d'utiliser LTESniffer pour renifler le trafic LTE ?
R: Vous devez vérifier les réglementations locales concernant le reniflage du trafic LTE (non chiffré). Une autre façon de tester LTESniffer est de mettre en place un réseau LTE personnel en utilisant srsRAN - une implémentation LTE open-source dans une cage de Faraday.
Q: LTESniffer peut-il être utilisé pour voir le contenu des messages entre deux utilisateurs ?
R: On ne peut voir que la partie "non chiffrée" des messages. Notez que le trafic aérien entre la station de base et les utilisateurs est principalement chiffré.
Q: Y a-t-il des identités d'appareils exposées en clair dans le réseau LTE ?
R: Oui, la littérature montre que plusieurs identités sont exposées, comme TMSI, GUTI, IMSI et RNTI. Veuillez consulter la littérature académique pour plus de détails, par exemple Watching the Watchers: Practical Video Identification Attack in LTE Networks.