LTESniffer : sniffer open source des liaisons descendante et montante LTE

 (github.com/SysSec-KAIST)
1 points par GN⁺ 2024-10-23 | 1 commentaires | Partager sur WhatsApp
  • LTESniffer est un outil open source qui capture les messages radio de liaison descendante et montante entre une station de base LTE et un smartphone, récupère d’abord les DCI et RNTI depuis le PDCCH, puis décode le PDSCH et le PUSCH pour analyser le trafic de données
  • Il ne peut pas déchiffrer les messages chiffrés ; il peut seulement analyser les parties non chiffrées comme les en-têtes MAC et de couche physique, les messages de diffusion de la station de base et les messages en clair du début de connexion
  • L’API destinée à la recherche en sécurité prend en charge trois fonctions : identity mapping, collecte d’IMSI et profilage des capacités UE ; il s’agit d’une implémentation visant à compléter l’hypothèse de sniffer passif utilisée dans les travaux existants sur la sécurité LTE par le décodage des paquets de protocole PDSCH et PUSCH
  • Le périmètre fonctionnel couvre LTE Advanced et LTE Advanced Pro, jusqu’à 256QAM en liaison montante et descendante, le FDD, des stations de base jusqu’à 20 MHz, les formats DCI 0/1A/1/1B/1C/2/2A/2B et les modes de transmission 1 à 4
  • Le décodage en temps réel nécessite une configuration SDR et un CPU multicœur physique, et la collecte du trafic montant demande, en raison de la faiblesse du signal UE, que le sniffer soit proche du smartphone ou bénéficie d’un renfort matériel comme une antenne directionnelle, un front-end RF ou un amplificateur

Ce que fait LTESniffer

  • LTESniffer est un sniffer open source capable de capturer à la fois les liaisons descendante et montante LTE
  • Son fonctionnement consiste d’abord à décoder le PDCCH pour obtenir les DCI et RNTI des utilisateurs actifs, puis à s’en servir pour décoder davantage le PDSCH et le PUSCH afin de récupérer le trafic de données montant et descendant
  • Du point de vue d’un utilisateur classique, c’est un outil qui capture dans les deux sens les messages radio LTE échangés entre la station de base et les smartphones qui y sont connectés
  • Il ne peut pas déchiffrer les messages chiffrés
    • Dans les messages chiffrés, il peut analyser les parties non chiffrées comme les en-têtes MAC et de couche physique
    • Les messages de diffusion de la station de base transmis en clair ainsi que les messages initiaux de connexion peuvent être analysés intégralement

API de recherche en sécurité et objectif du projet

  • LTESniffer fournit 3 fonctions API pour les applications et la recherche en sécurité
    • identity mapping
    • collecte d’IMSI
    • profilage des capacités UE
  • De nombreux travaux sur la sécurité LTE supposent l’existence d’un sniffer passif capable de capturer dans l’air des paquets liés à la vie privée, mais les sniffers open source existants ne décodent pas les paquets de protocole du PDSCH et du PUSCH et ne satisfont donc pas cette exigence
  • Plus de détails sont réunis dans ce papier
  • LTESniffer a pour objectif principal de soutenir la recherche en sécurité et en analyse des réseaux cellulaires
    • Comme il collecte les données utilisateur en liaison montante et descendante, il faut respecter la réglementation locale sur le sniffing du trafic LTE
    • Les développeurs déclinent toute responsabilité en cas d’usage illégal, notamment la collecte intentionnelle d’informations liées à la vie privée des utilisateurs

Fonctions prises en charge et base d’implémentation

  • LTESniffer est implémenté au-dessus de FALCON et utilise la bibliothèque srsRAN
  • Les principales fonctions prises en charge sont les suivantes
    • Décodage en temps réel, en liaison montante et descendante, des canaux de contrôle et de données PDCCH, PDSCH, PUSCH
    • LTE Advanced et LTE Advanced Pro
    • Jusqu’à 256QAM en liaison montante et descendante
    • Formats DCI 0, 1A, 1, 1B, 1C, 2, 2A, 2B
    • Modes de transmission 1, 2, 3, 4

    • FDD uniquement

      • Stations de base jusqu’à 20 MHz
      • Détection automatique du mode de modulation UL/DL maximal selon le smartphone
      • Détection automatique de la configuration de couche physique par UE
      • Mapping RNTI-TMSI, collecte d’IMSI, profilage des capacités UE
      • La mise à jour v2.1.0 ajoute l’enregistrement des fichiers de données brutes IQ de sous-trame, le décodage hors ligne à partir des fichiers enregistrés et l’activation de l’API en mode liaison descendante
      • L’API du mode liaison descendante s’applique uniquement aux API de collecte d’identité et de mapping
      • Les détails associés figurent dans la branche LTESniffer-record-subframe et le README
      • La mise à jour v2.0.0 prend en charge l’utilisation de deux USRP série B en mode sniffing montant et corrige des bugs
      • Les détails associés figurent dans la branche LTESniffer-multi-usrp et le README

Exigences matérielles et logicielles

  • Les OS dont le fonctionnement stable est confirmé sont Ubuntu 18.04/20.04/22.04
  • Le décodage en temps réel du trafic LTE nécessite un CPU puissant avec plusieurs cœurs physiques, notamment aux heures de pointe où de nombreux utilisateurs sont actifs sur la station de base
    • Un cas de décodage en temps réel du trafic d’une station de base avec 150 utilisateurs actifs a été démontré sur un PC Intel i7-9700K
    • La configuration recommandée est un CPU Intel i7 avec au moins 8 cœurs physiques, 16 Go de RAM minimum et un SSD de 256 Go minimum
  • Pour le sniffing de la seule liaison descendante, la plupart des SDR pris en charge par srsRAN peuvent être utilisés
    • Exemples : USRP ou BladeRF
    • Le SDR doit être connecté au PC en USB 3.0
    • Deux antennes RX sont nécessaires pour décoder les messages de liaison descendante en modes de transmission 3 et 4
    • Avec une seule antenne RX, seuls les messages de liaison descendante en mode de transmission 1 sont décodés
    • Un GPSDO peut améliorer la synchronisation en sniffing descendant, mais n’est pas indispensable
  • Le sniffing montant doit écouter simultanément deux fréquences, montante et descendante ; deux configurations sont donc prises en charge
    • USRP X310 unique : ses deux canaux RX peuvent être réglés sur des fréquences montante et descendante distinctes, et le GPSDO reste optionnel
    • Deux USRP série B : un B210/B200 pour la liaison montante et un autre pour la liaison descendante, avec GPSDO comme source d’horloge et référence temporelle pour synchroniser les deux USRP
    • Dans la configuration avec deux USRP série B, le GPSDO est obligatoire

Installation et flux d’exécution

  • Avant de compiler depuis les sources, l’installation de UHD 4.0 ou supérieur est nécessaire, et la compilation depuis les sources est recommandée
  • Après l’installation des dépendances srsRAN et des dépendances de LTESniffer, il faut cloner le dépôt puis compiler avec cmake et make -j 4
  • Une fois la compilation terminée, l’exécutable se trouve dans <build-dir>/src/LTESniffer
  • Il existe trois principaux modes d’exécution
    • Sniffing du trafic LTE descendant provenant de la station de base
    • Sniffing du trafic LTE montant allant du smartphone vers la station de base
    • API de sécurité
  • Avant une utilisation sur un réseau commercial, il faut vérifier la réglementation locale concernant le sniffing du trafic LTE
  • Pour identifier la station de base à laquelle le smartphone de test est connecté ainsi que ses bandes montante et descendante, on peut utiliser Cellular-Z sur Android
    • LTESniffer doit lui aussi être connecté à la même cellule et à la même fréquence

Sortie et analyse

  • LTESniffer produit en sortie des fichiers pcap, qui peuvent être analysés plus en détail et suivis dans Wireshark
  • Les noms de fichiers générés diffèrent selon le mode
    • Liaison descendante : sniffer_dl_mode.pcap
    • Liaison montante : sniffer_ul_mode.pcap
    • API : api_collector.pcap
  • Les fichiers pcap sont créés dans le même répertoire que celui où LTESniffer est exécuté
  • Pour que Wireshark analyse correctement les paquets décodés, il faut suivre le guide de configuration de pcap_file_example/README.md
  • Le fichier pcap de liaison montante contient à la fois les messages montants et descendants
    • Pour n’afficher que la liaison montante, utiliser le filtre mac-lte.direction == 0
    • Pour n’afficher que la liaison descendante, utiliser le filtre mac-lte.direction == 1

Contraintes de distance du sniffing montant

  • La portée effective du mode montant de LTESniffer est limitée par les performances du front-end RF tel qu’un SDR
  • Les UE étant des appareils mobiles optimisés pour l’autonomie, la puissance de leur signal montant est bien plus faible que celle du signal descendant de la station de base
  • Pour capturer avec succès le trafic montant, il est possible d’augmenter la puissance du signal reçu des façons suivantes
    • Se placer physiquement à proximité de l’UE
    • Utiliser du matériel spécialisé comme une antenne directionnelle, un front-end RF dédié ou un amplificateur de signal

Limites et alternatives indiquées dans la FAQ

  • Un GPSDO est utile pour une synchronisation plus stable, mais en sniffing descendant il est possible de se synchroniser sur le signal LTE et de décoder les paquets même sans GPSDO
  • En sniffing montant, le GPSDO n’est requis que lors de l’utilisation de deux USRP série B
    • La configuration avec un seul USRP X310 n’en a pas besoin
  • Le trafic descendant peut aussi fonctionner techniquement avec des SDR comme BladeRF pris en charge par la bibliothèque srsRAN
    • Cependant, les fonctions descendantes de LTESniffer n’ont été testées qu’avec des USRP B210 et X310
  • La légalité d’utilisation de LTESniffer dépend de la réglementation locale sur le sniffing de trafic LTE non chiffré
    • Comme autre méthode de test, il est proposé de monter un réseau LTE privé basé sur srsRAN dans une cage de Faraday
  • Le contenu des messages entre deux utilisateurs n’est visible que dans ses parties non chiffrées
    • La majeure partie du trafic radio entre la station de base et l’utilisateur est chiffrée
  • La littérature sur les réseaux LTE mentionne plusieurs identifiants exposés en clair, comme TMSI, GUTI, IMSI et RNTI

À lire aussi

1 commentaires

 
GN⁺ 2024-10-23
Avis sur Hacker News

  • C’est bien que les standards des réseaux mobiles soient remplis d’acronymes
    Au cas où vous ne le sauriez pas, le Q de PHICH signifie « request »

    • Pour ceux qui se demandent de quoi il est question ci-dessus : PHICH n’apparaît pas dans le projet cité, mais c’est un exemple d’acronyme bizarre des réseaux mobiles ; il signifie « Physical channel HybridARQ Indicator Channel »
      Le « ARQ » qu’il contient peut probablement se développer en https://en.wikipedia.org/wiki/Automatic_repeat_request
      Certains pourraient dire que le « Q » de « ARQ » signifie en réalité « query », et que ceux qui le développent en « request » supposent un niveau moyen de vocabulaire assez bas
      Personnellement, en y réfléchissant, je pense qu’il est plus probable que le Q ne vienne ni de « request » ni de « query », mais soit une autre trace des conventionnels et opaques codes Q de https://en.wikipedia.org/wiki/Q_code
    • Je croyais que c’était une blague
      Voici le Q dans PHICH : https://github.com/srsran/srsRAN_4G/blob/master/lib/src/phy/...
      Comme dans le commentaire voisin, q est le Q de reQuest

  • Ça a l’air bien
    Il y a quand même quelques limites : seul FDD est pris en charge, pas TDD, et c’est limité à 20 MHz
    Il semble aussi qu’un certain décodage en temps réel soit possible, ce qui est intéressant. Dans une station de base, une grande partie du traitement est assurée par des processeurs assez généralistes, mais ils restent bien plus étroitement intégrés au matériel que ce logiciel

  • Dommage que le matériel pour faire tourner ça soit trop cher :'(

    • Il utilise srsRAN, qui prend en charge SoapySDR, indépendant des fournisseurs
      Donc cela devrait aussi fonctionner sur limesdr
      Pour moins cher, on peut essayer antsdr ou adalm-pluto : https://github.com/srsran/zynq_timestamping
      Il y a aussi beaucoup de bonnes notes : https://www.quantulum.co.uk/blog/private-lte-with-analog-ada...
    • Si vous vous intéressez à un décodeur de métadonnées LTE plus accessible, regardez https://github.com/JiaoXianjun/LTE-Cell-Scanner
      Certaines fonctionnalités marchent même avec des dongles rtl-sdr bon marché. C’est un fork de l’ancien https://github.com/Evrytania/LTE-Cell-Scanner
    • Si vous avez déjà un PC, il semble possible d’acheter un bladeRF 2.0 micro xA5 à 670 dollars, mais dans ce cas on ne peut sniffer que le downlink
    • Il existe du matériel moins cher avec suffisamment de bande passante et de plage dynamique, comme Adalm Pluto, mais il semble ne pas être pris en charge
    • Vraiment ? Je me demande comment les modems de téléphone peuvent être aussi bon marché

  • C’est un peu hors sujet, mais je me demande si quelqu’un a déjà essayé d’écouter du DSL
    Le DSL moderne, en particulier VDSL2, est essentiellement un signal haute fréquence qui circule sur une paire torsadée non blindée ; avec en plus des dérivations de ligne, il devrait facilement fuir et rayonner
    Apparemment, c’est suffisamment vrai pour que les radioamateurs britanniques s’en plaignent beaucoup[1]. Je me demande si ce signal peut encore être démodulé, ou s’il n’est qu’un bruit de fond gênant dans le spectre
    [1]: https://rsgb.services/public/publications/vdsl/measuring_and...

  • Un fait intéressant et moins connu, c’est que les premières générations de téléphones mobiles numériques se trouvent dans une zone intermédiaire de difficulté de déchiffrement
    Ce n’est pas du tout facile, mais suffisamment pour être cassable. Le chiffrement a effectivement été cassé
    La rainbow table fait 2 To et a pris des mois à générer : https://github.com/0xh4di/GSMDecryption?tab=readme-ov-file
    Maintenant, je me demande si, dans les générations suivantes, il existe aussi quelques failles de déchiffrement, pour diverses raisons ou à cause de certains acteurs étatiques

  • Travail intéressant, et ça fait plaisir de voir que ce genre d’open source est encore utilisé
    Il y a une dizaine d’années, dans le labo de recherche en sécurité réseau de mon université, nous avions fait de l’écoute du downlink
    L’un des projets consistait à mesurer à quel point l’activité cellulaire baissait pendant les vacances de printemps ; un autre consistait à voir si l’on pouvait extraire un identifiant temporaire via une attaque temporelle sur un numéro de téléphone connu à un emplacement connu, puis à vérifier par des appels répétés s’il se trouvait encore dans la zone
    À mon avis, cet identifiant temporaire n’était pas assez temporaire. Ça me donne envie de remettre les mains dedans

  • Il existe aussi des dongles 4G connus pour avoir des modes de debug cassés permettant d’extraire des informations

  • LTESniffer est présenté comme open source, mais il ne semble pas y avoir de fichier LICENSE à la racine, ni de licence configurée pour le dépôt GitHub

    • La plupart des fichiers source ont des en-têtes de copyright indiquant que le code est sous AGPLv3 et qu’il a été forké à partir de projets existants disposant d’un fichier LICENSE à la racine, https://github.com/falkenber9/falcon et https://github.com/srsran/srsRAN_Project
      Pour couvrir aussi les fichiers de build et les autres fichiers de support, il vaudrait mieux ajouter un fichier LICENSE à la racine