LTESniffer: Open-Source-Sniffer für LTE-Downlink/Uplink

 (github.com/SysSec-KAIST)
1 Punkte von GN⁺ 2024-10-23 | 1 Kommentare | Auf WhatsApp teilen
  • LTESniffer ist ein Open-Source-Tool, das Downlink- und Uplink-Funknachrichten zwischen LTE-Basisstationen und Smartphones erfasst. Es gewinnt zunächst DCI und RNTI aus dem PDCCH und dekodiert anschließend PDSCH und PUSCH, um Datenverkehr zu analysieren.
  • Verschlüsselte Nachrichten können nicht entschlüsselt werden; analysierbar sind nur unverschlüsselte Teile wie MAC- und Physical-Layer-Header, Broadcast-Nachrichten der Basisstation sowie anfängliche Klartextnachrichten beim Verbindungsaufbau.
  • Die API für Sicherheitsforschung unterstützt drei Funktionen: identity mapping, IMSI collecting und UE capability profiling. Die Implementierung soll die in bisherigen LTE-Sicherheitsstudien angenommene Anforderung an passive Sniffer durch Dekodierung von PDSCH- und PUSCH-Protokollpaketen ergänzen.
  • Der Funktionsumfang umfasst LTE Advanced und LTE Advanced Pro, bis zu 256QAM im Uplink und Downlink, FDD, Basisstationen mit bis zu 20 MHz, DCI formats 0/1A/1/1B/1C/2/2A/2B sowie transmission modes 1–4.
  • Für Echtzeit-Dekodierung sind eine CPU mit mehreren physischen Kernen und eine SDR-Konfiguration erforderlich. Das Sammeln von Uplink-Traffic ist wegen des schwachen UE-Signals nur möglich, wenn sich der Sniffer nahe am Smartphone befindet oder Hardware-Erweiterungen wie Richtantenne, RF-Frontend oder Verstärker eingesetzt werden.

Was LTESniffer macht

  • LTESniffer ist ein Open-Source-Sniffer, der sowohl LTE-Downlink als auch LTE-Uplink erfasst.
  • Der Ablauf: Zuerst wird der PDCCH dekodiert, um DCI und RNTI aktiver Nutzer zu erhalten; damit werden anschließend PDSCH und PUSCH weiter dekodiert, um Uplink- und Downlink-Datenverkehr zu gewinnen.
  • Aus Sicht normaler Nutzer ist es ein Tool, das LTE-Funknachrichten, die zwischen einer Basisstation und verbundenen Smartphones ausgetauscht werden, in beide Richtungen erfasst.
  • Verschlüsselte Nachrichten können nicht entschlüsselt werden.
    • In verschlüsselten Nachrichten lassen sich unverschlüsselte Teile wie MAC- und Physical-Layer-Header analysieren.
    • Im Klartext übertragene Broadcast-Nachrichten der Basisstation oder anfängliche Verbindungsnachrichten können vollständig analysiert werden.

API für Sicherheitsforschung und Forschungszweck

  • LTESniffer bietet 3 API-Funktionen für Sicherheitsanwendungen und Forschung.
    • identity mapping
    • IMSI collecting
    • UE capability profiling
  • Viele LTE-Sicherheitsstudien gehen von einem passiven Sniffer aus, der Privacy-relevante Pakete aus der Luft erfassen kann; bestehende Open-Source-Sniffer erfüllen diese Anforderungen laut den Autoren jedoch nicht, weil sie Protokollpakete von PDSCH und PUSCH nicht dekodieren können.
  • Details sind im Paper zusammengefasst.
  • Hauptzweck von LTESniffer ist die Unterstützung von Sicherheits- und Analyseforschung zu Mobilfunknetzen.
    • Da Uplink- und Downlink-Nutzerdaten gesammelt werden, müssen lokale Vorschriften zum Sniffing von LTE-Traffic beachtet werden.
    • Für illegale Nutzung, etwa das absichtliche Sammeln von Informationen zur Privatsphäre von Nutzern, übernehmen die Entwickler keine Verantwortung.

Unterstützte Funktionen und Implementierungsbasis

  • LTESniffer ist auf FALCON implementiert und nutzt die Bibliothek srsRAN.
  • Der wichtigste unterstützte Umfang ist wie folgt:
    • Echtzeit-Dekodierung von Uplink und Downlink der Control- und Datenkanäle PDCCH, PDSCH, PUSCH
    • LTE Advanced und LTE Advanced Pro
    • Bis zu 256QAM für Uplink und Downlink
    • DCI formats 0, 1A, 1, 1B, 1C, 2, 2A, 2B
    • transmission modes 1, 2, 3, 4

    • Nur FDD wird unterstützt

      • Basisstationen mit bis zu 20 MHz
      • Automatische Erkennung des maximalen UL/DL-Modulationsverfahrens je Smartphone
      • Automatische Erkennung der Physical-Layer-Konfiguration je UE
      • RNTI-TMSI mapping, IMSI collecting, UE Capability Profiling
      • Das Update v2.1.0 ergänzt das Schreiben von IQ raw data pro Subframe, Offline-Dekodierung anhand der aufgezeichneten Dateien sowie die Aktivierung der API im Downlink-Modus.
      • Die API im Downlink-Modus gilt nur für identity collecting und die mapping API.
      • Details dazu finden sich im Branch LTESniffer-record-subframe und im README.
      • Das Update v2.0.0 unterstützt im Uplink-Sniffing-Modus die Nutzung von zwei USRP B-series und behebt Fehler.
      • Details dazu finden sich im Branch LTESniffer-multi-usrp und im README.

Hardware- und Softwareanforderungen

  • Als stabil laufende Betriebssysteme gelten Ubuntu 18.04/20.04/22.04.
  • Für die Echtzeit-Dekodierung von LTE-Traffic ist zu Spitzenzeiten mit vielen aktiven Nutzern an der Basisstation eine leistungsstarke CPU mit mehreren physischen Kernen erforderlich.
    • Es gibt einen Fall, in dem der Traffic einer Basisstation mit 150 aktiven Nutzern auf einem PC mit Intel i7-9700K in Echtzeit dekodiert wurde.
    • Empfohlen werden eine Intel-i7-CPU mit mindestens 8 physischen Kernen, mindestens 16 GB RAM und eine 256-GB-SSD.
  • Für reines Downlink-Sniffing lassen sich die meisten von srsRAN unterstützten SDRs verwenden.
    • Beispiele sind USRP oder BladeRF.
    • Das SDR muss per USB 3.0 mit dem PC verbunden sein.
    • Zum Dekodieren von Downlink-Nachrichten in transmission modes 3 und 4 sind 2 RX-Antennen erforderlich.
    • Wenn nur 1 RX-Antenne vorhanden ist, werden nur Downlink-Nachrichten in transmission mode 1 dekodiert.
    • Ein GPSDO hilft beim Downlink-Sniffing, die Synchronisation zu verbessern, ist aber nicht zwingend erforderlich.
  • Uplink-Sniffing muss gleichzeitig auf zwei Frequenzen für Uplink und Downlink hören; daher werden zwei Konfigurationen unterstützt.
    • Einzelner USRP X310: 2 RX-Kanäle können auf unterschiedliche Uplink- und Downlink-Frequenzen eingestellt werden; GPSDO ist optional.
    • 2 USRP B-Series: B210/B200 werden jeweils für Uplink und Downlink verwendet, und GPSDO dient als clock source und time reference zur Synchronisierung der beiden USRPs.
    • In einer Konfiguration mit 2 USRP B-Series ist GPSDO zwingend erforderlich.

Installation und Ablauf der Ausführung

  • Vor dem Build aus dem Source ist die Installation von UHD 4.0 oder höher erforderlich; ein Source-Build wird empfohlen.
  • Nach der Installation der srsRAN-Abhängigkeiten und der LTESniffer-Abhängigkeiten wird das Repository geklont und mit cmake sowie make -j 4 gebaut.
  • Nach dem Build befindet sich die ausführbare Datei unter <build-dir>/src/LTESniffer.
  • Es gibt 3 Hauptbetriebsarten.
    • Sniffing von LTE-Downlink-Traffic von der Basisstation
    • Sniffing von LTE-Uplink-Traffic vom Smartphone zur Basisstation
    • Sicherheits-API
  • Vor der Nutzung in kommerziellen Netzen müssen die lokalen Vorschriften zum Sniffing von LTE-Traffic geprüft werden.
  • Um die Basisstation sowie Uplink- und Downlink-Bänder zu ermitteln, mit denen ein Test-Smartphone verbunden ist, kann Cellular-Z für Android verwendet werden.
    • LTESniffer muss mit derselben Zelle und Frequenz verbunden sein.

Ausgabe und Analyse

  • LTESniffer gibt pcap-Dateien aus, die in Wireshark weiter analysiert und zur Paketverfolgung genutzt werden können.
  • Die erzeugten Dateinamen unterscheiden sich je nach Modus.
    • Downlink: sniffer_dl_mode.pcap
    • Uplink: sniffer_ul_mode.pcap
    • API: api_collector.pcap
  • pcap-Dateien werden im selben Verzeichnis erzeugt, in dem LTESniffer ausgeführt wurde.
  • Damit Wireshark die dekodierten Pakete korrekt analysiert, sollte die Konfigurationsanleitung in pcap_file_example/README.md beachtet werden.
  • Die Uplink-pcap-Datei enthält sowohl Uplink- als auch Downlink-Nachrichten.
    • Um nur Uplink zu sehen, den Filter mac-lte.direction == 0 verwenden.
    • Um nur Downlink zu sehen, den Filter mac-lte.direction == 1 verwenden.

Entfernungsbeschränkungen beim Uplink-Sniffing

  • Die effektive Uplink-Reichweite von LTESniffer ist durch die Leistung des RF-Frontends wie etwa eines SDR begrenzt.
  • Ein UE ist ein mobiles Gerät, das den Akkuverbrauch optimiert; daher ist die Uplink-Signalleistung deutlich schwächer als das Downlink-Signal der Basisstation.
  • Um Uplink-Traffic erfolgreich zu erfassen, lässt sich die Empfangssignalleistung auf folgende Weise erhöhen:
    • Physische Nähe zum UE
    • Einsatz spezieller Hardware wie Richtantenne, dediziertes RF-Frontend oder Signalverstärker

In der FAQ genannte Einschränkungen und Alternativen

  • GPSDO ist für eine stabilere Synchronisierung nützlich, beim Downlink-Sniffing können Pakete jedoch auch ohne GPSDO durch Synchronisation mit dem LTE-Signal dekodiert werden.
  • Beim Uplink-Sniffing ist GPSDO nur erforderlich, wenn 2 USRP B-series verwendet werden.
    • Eine Konfiguration mit einem einzelnen USRP X310 benötigt kein GPSDO.
  • Downlink-Traffic ist technisch auch mit SDRs wie BladeRF möglich, die von der srsRAN-Bibliothek unterstützt werden.
    • Die Downlink-Funktion von LTESniffer wurde jedoch nur mit USRP B210 und X310 getestet.
  • Für die Rechtmäßigkeit der Nutzung von LTESniffer müssen die lokalen Vorschriften zum Sniffing unverschlüsselten LTE-Traffics geprüft werden.
    • Als alternative Testmethode wird der Aufbau eines privaten LTE-Netzes auf Basis von srsRAN in einem Faraday cage genannt.
  • Nachrichteninhalte zwischen zwei Nutzern sind nur in den unverschlüsselten Teilen einsehbar.
    • Der Funkverkehr zwischen Basisstation und Nutzer ist größtenteils verschlüsselt.
  • In der Literatur werden mehrere Kennungen beschrieben, die in LTE-Netzen im Klartext offengelegt werden, etwa TMSI, GUTI, IMSI und RNTI.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-10-23
Meinungen auf Hacker News

  • Mobilfunkstandards sind schön, weil sie voller Abkürzungen stecken.
    Falls ihr es nicht wusstet: Das Q in PHICH steht für „request“.

    • Für alle, die sich fragen, wovon oben die Rede ist: PHICH kommt im verlinkten Projekt zwar nicht vor, ist aber ein Beispiel für seltsame Mobilfunk-Abkürzungen und steht für „Physical channel HybridARQ Indicator Channel“.
      Das „ARQ“ darin lässt sich vermutlich als https://en.wikipedia.org/wiki/Automatic_repeat_request ausschreiben.
      Manche würden sagen, dass das „Q“ in „ARQ“ eigentlich für „query“ steht, und dass diejenigen, die es als „request“ auflösen, von einem niedrigen durchschnittlichen Wortschatz ausgehen.
      Persönlich halte ich es bei näherem Nachdenken für wahrscheinlicher, dass das Q weder „request“ noch „query“ bedeutet, sondern ein weiteres Überbleibsel der konventionell undurchsichtigen Q-Codes aus https://en.wikipedia.org/wiki/Q_code ist.
    • Ich dachte, das sei ein Witz.
      Hier ist das Q in PHICH: https://github.com/srsran/srsRAN_4G/blob/master/lib/src/phy/...
      Wie im Schwesterkommentar: q ist das Q in reQuest.

  • Sieht gut aus.
    Es unterstützt nur FDD und kein TDD und ist auf 20 MHz begrenzt, hat also einige Einschränkungen.
    Interessant ist, dass offenbar auch ein gewisses Maß an Echtzeit-Decoding möglich ist. In der Basisstation übernimmt zwar ein recht großer Teil der Verarbeitung ziemlich universelle Prozessoren, aber sie ist dennoch deutlich enger mit der Hardware integriert als diese Software.

  • Schade, dass die Hardware zum Ausführen viel zu teuer ist :'(

    • Es verwendet srsRAN, und srsRAN unterstützt das herstellerunabhängige SoapySDR.
      Daher sollte es auch auf limesdr laufen.
      Als günstigere Alternativen könnte man antsdr oder adalm-pluto ausprobieren: https://github.com/srsran/zynq_timestamping
      Es gibt auch viele gute Notizen: https://www.quantulum.co.uk/blog/private-lte-with-analog-ada...
    • Wenn dich ein zugänglicherer LTE-Metadaten-Decoder interessiert, schau dir https://github.com/JiaoXianjun/LTE-Cell-Scanner an.
      Einige Funktionen laufen sogar mit günstigen rtl-sdr-Dongles. Es ist ein Fork des älteren https://github.com/Evrytania/LTE-Cell-Scanner.
    • Wenn man bereits einen PC hat, scheint es mit einem bladeRF 2.0 micro xA5 für 670 Dollar möglich zu sein; in diesem Fall kann man aber nur den Downlink sniffen.
    • Es gibt auch günstigere Hardware mit ausreichender Bandbreite und Dynamikbereich, etwa Adalm Pluto, aber anscheinend wird sie nicht unterstützt.
    • Ist das wirklich so? Ich frage mich, wie Handy-Modems dann so billig sein können.

  • Etwas am Rande: Ich frage mich, ob schon jemand versucht hat, DSL abzuhören.
    Modernes DSL, insbesondere VDSL2, ist im Grunde ein Hochfrequenzsignal, das über ungeschirmte verdrillte Doppeladern läuft; mit Dingen wie Leitungsabzweigen dürfte es leicht austreten und abstrahlen.
    Tatsächlich scheint das so zu sein, dass sich Funkamateure in Großbritannien ausgiebig darüber beschweren[1]. Ich frage mich, ob man dieses Signal noch demodulieren kann oder ob es im Spektrum nur ein lästiges Grundrauschen ist.
    [1]: https://rsgb.services/public/publications/vdsl/measuring_and...

  • Eine weniger bekannte interessante Tatsache ist, dass die frühen digitalen Mobilfunkgenerationen in einer Grauzone der Entschlüsselungsschwierigkeit liegen.
    Es ist keineswegs einfach, aber einfach genug, um geknackt zu werden. Die Verschlüsselung wurde tatsächlich gebrochen.
    Die Rainbow Tables sind 2 TB groß, und ihre Erstellung hat Monate gedauert: https://github.com/0xh4di/GSMDecryption?tab=readme-ov-file
    Jetzt frage ich mich, ob es aus diesem oder jenem Grund oder wegen bestimmter staatlicher Akteure auch in späteren Generationen ein paar Entschlüsselungslücken gibt.

  • Interessante Arbeit, und schön zu sehen, dass solche Open Source noch genutzt wird.
    Vor etwa zehn Jahren habe ich in einem Uni-Labor für Netzwerksicherheit Downlink-Abhören ausprobiert.
    Eines der Projekte bestand darin zu messen, wie stark die Zellaktivität während der Spring Break zurückging; ein anderes darin, per Timing-Angriff auf eine bekannte Telefonnummer an einem bekannten Ort herauszufinden, ob man eine temporäre ID extrahieren kann, und dann durch wiederholte Anrufe zu sehen, ob sie sich noch in der Gegend befindet.
    Diese temporäre ID war meiner Meinung nach nicht annähernd temporär genug. Jetzt bekomme ich Lust, mich wieder damit zu beschäftigen.

  • Es gibt auch 4G-Dongles mit bekannten kaputten Debug-Modi, über die man Informationen extrahieren kann.

  • LTESniffer wird zwar als Open Source bezeichnet, aber es scheint weder eine LICENSE-Datei auf oberster Ebene noch eine Lizenzangabe im GitHub-Repository zu geben.

    • Die meisten Quelldateien haben Copyright-Header, die angeben, dass der Code AGPLv3 ist und aus bestehenden Projekten mit LICENSE-Datei auf oberster Ebene geforkt wurde: https://github.com/falkenber9/falcon und https://github.com/srsran/srsRAN_Project.
      Um auch Build-Dateien und andere unterstützende Dateien abzudecken, sollte eine LICENSE-Datei auf oberster Ebene hinzugefügt werden.