syssec-kaist/ltesnifferEin Open-Source LTE Downlink/Uplink Abhörer
LTESniffer ist ein Open-Source-LTE-Downlink/Uplink-Abhörgerät.
Es dekodiert zunächst den Physical Downlink Control Channel (PDCCH), um die Downlink Control Information (DCIs) und Radio Network Temporary Identifiers (RNTIs) aller aktiven Nutzer zu erhalten. Mithilfe der dekodierten DCIs und RNTIs dekodiert LTESniffer weiter den Physical Downlink Shared Channel (PDSCH) und den Physical Uplink Shared Channel (PUSCH), um Uplink- und Downlink-Datenverkehr zu erfassen.
LTESniffer unterstützt eine API mit drei Funktionen für Sicherheitsanwendungen und Forschung. Viele LTE-Sicherheitsforschungen gehen von einem passiven Sniffer aus, der datenschutzrelevante Pakete aus der Luft erfassen kann. Allerdings erfüllt keiner der derzeitigen Open-Source-Sniffer ihre Anforderungen, da sie keine Protokollpakete in PDSCH und PUSCH dekodieren können. Wir haben eine Proof-of-Concept-Sicherheits-API entwickelt, die drei Aufgaben unterstützt, die in früheren Arbeiten vorgeschlagen wurden: 1) Identitätszuordnung, 2) IMSI-Sammlung und 3) Fähigkeitsprofilierung.
Weitere Informationen finden Sie in unserem Paper.
LTESniffer ist ein Werkzeug, das die drahtlosen LTE-Nachrichten erfassen kann, die zwischen einer Basisstation und den damit verbundenen Smartphones gesendet werden. LTESniffer unterstützt das Erfassen der Nachrichten in beide Richtungen: von der Basisstation zu den Smartphones und von den Smartphones zurück zur Basisstation.
LTESniffer KANN KEINE verschlüsselten Nachrichten zwischen der Basisstation und den Smartphones entschlüsseln. Es kann zur Analyse unverschlüsselter Teile der Kommunikation zwischen Basisstation und Smartphones verwendet werden. Beispielsweise erlaubt es bei verschlüsselten Nachrichten die Analyse unverschlüsselter Teile wie Header in der MAC- und der Bitübertragungsschicht. Nachrichten, die im Klartext gesendet werden, können jedoch vollständig analysiert werden. Beispielsweise sind die von der Basisstation gesendeten Broadcast-Nachrichten oder die Nachrichten zu Beginn der Verbindung vollständig sichtbar.
Der Hauptzweck von LTESniffer ist die Unterstützung von Sicherheits- und Analyseforschung im Mobilfunknetz. Aufgrund der Erfassung von Uplink-Downlink-Nutzerdaten muss jede Nutzung von LTESniffer die örtlichen Vorschriften zum Abhören von LTE-Datenverkehr einhalten. Wir übernehmen keine Verantwortung für illegale Zwecke wie das absichtliche Sammeln von datenschutzrelevanten Informationen der Nutzer.
LTESniffer-record-subframe-Branch und in dessen README.LTESniffer-multi-usrp-Branch und in dessen README.LTESniffer ist auf Basis von FALCON unter Verwendung der srsRAN-Bibliothek implementiert. LTESniffer unterstützt:
Derzeit läuft LTESniffer stabil auf Ubuntu 18.04/20.04/22.04.
Um eine Echtzeit-Dekodierung des LTE-Datenverkehrs zu erreichen, ist eine leistungsstarke CPU mit mehreren physischen Kernen erforderlich, insbesondere während Spitzenzeiten, wenn die Basisstation viele aktive Nutzer hat. LTESniffer erreichte erfolgreich die Echtzeit-Dekodierung, als es auf einem Intel i7-9700K-PC eingesetzt wurde und Datenverkehr einer Basisstation mit 150 aktiven Nutzern dekodierte.
Die folgende Hardware wird empfohlen
LTESniffer benötigt unterschiedliche SDRs für den Uplink- und Downlink-Sniffing-Modus.
Zum reinen Abhören des Downlink-Datenverkehrs von der Basisstation ist LTESniffer mit den meisten SDRs kompatibel, die von der srsRAN-Bibliothek unterstützt werden (z. B. USRP oder BladeRF). Das SDR sollte über einen USB-3.0-Anschluss mit dem PC verbunden sein. Zudem sollte es über zwei RX-Antennen verfügen, um Downlink-Nachrichten in den Übertragungsmodi 3 und 4 zu dekodieren. Wenn Ihr SDR nur eine RX-Antenne hat, dekodiert LTESniffer nur Downlink-Nachrichten im Übertragungsmodus 1. Beachten Sie, dass GPSDO für das Downlink-Sniffing optional ist; es verbessert die Synchronisation, ist aber nicht zwingend erforderlich.
Andererseits muss LTESniffer zum Abhören des Uplink-Datenverkehrs von Smartphones zur Basisstation gleichzeitig zwei verschiedene Frequenzen (Uplink und Downlink) überwachen. Um dieses Problem zu lösen, unterstützt LTESniffer zwei Optionen:
main-Branch von LTESniffer.LTESniffer-multi-usrp-Branch von LTESniffer und in dessen README.Wichtiger Hinweis: Um unerwartete Fehler zu vermeiden, befolgen Sie bitte die folgenden Schritte auf Ubuntu 18.04/20.04/22.04.
Abhängigkeiten
UHD-Abhängigkeiten:
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
UHD aus dem Quellcode klonen und bauen (stellen Sie sicher, dass der aktuelle Branch höher als 4.0 ist):
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
Firmware für USRPs herunterladen:
sudo uhd_images_downloader
Wir verwenden eine 10-Gb-Karte, um den USRP X310 mit dem PC zu verbinden. Informationen zur Konfiguration des USRP X310 und der 10-Gb-Kartenschnittstelle finden Sie im UHD-Handbuch [1], [2]. Für USRP B210 sollte dieser über einen USB-3.0-Anschluss mit dem PC verbunden werden.
Verbindung und Firmware testen (nur für 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
LTESniffer aus dem Quellcode bauen:
git clone https://github.com/SysSec-KAIST/LTESniffer.git
cd LTESniffer
mkdir build
cd build
cmake ../
make -j 4 (use 4 threads)
LTESniffer hat 3 Hauptfunktionen:
Nach dem Bau aus dem Quellcode befindet sich LTESniffer in <build-dir>/src/LTESniffer.
Beachten Sie, dass vor der Nutzung von LTESniffer im kommerziellen Umfeld die örtlichen Vorschriften zum Abhören von LTE-Datenverkehr geprüft werden müssen, wie unter Ethische Überlegungen erläutert.
Um die Basisstation und das Uplink-Downlink-Band zu ermitteln, mit dem das Test-Smartphone verbunden ist, installieren Sie die App Cellular-Z auf dem Test-Smartphone (die App unterstützt nur Android). Sie zeigt die Zellen-ID und das Uplink-/Downlink-Band/die Frequenz an, mit der das Test-Smartphone verbunden ist. Stellen Sie sicher, dass LTESniffer ebenfalls mit derselben Zelle und Frequenz verbunden ist.
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
Hinweis: Um LTESniffer mit USRP B210 im Downlink-Modus auszuführen, fügen Sie die Option -a "num_recv_frames=512" zur Befehlszeile hinzu.
Diese Option erweitert den Empfangspuffer für USRP B210, um eine bessere Synchronisation zu erreichen.
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"
Hinweis: Im Uplink-Sniffing-Modus sollten sich die Test-Smartphones in der Nähe des Sniffers befinden, da die Uplink-Signalleistung des UE deutlich schwächer ist als das Downlink-Signal der Basisstation.
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 kann auf einer bestimmten Basisstation lauschen, indem die Optionen -I <Physical Cell ID (PCI)> -p <number of Physical Resource Block (PRB)> verwendet werden. In diesem Fall führt LTESniffer keine Zellensuche durch, sondern verbindet sich direkt mit der angegebenen Zelle.
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
Der Debug-Modus kann mit der Option -d aktiviert werden. In diesem Fall werden Debug-Meldungen auf dem Terminal ausgegeben.
LTESniffer liefert pcap-Dateien als Ausgabe. Die pcap-Datei kann mit WireShark zur weiteren Analyse und Paketverfolgung geöffnet werden.
Der Name der Downlink-pcap-Datei: sniffer_dl_mode.pcap, der der Uplink-pcap-Datei: sniffer_ul_mode.pcap und der der API-pcap-Datei: api_collector.pcap.
Die pcap-Dateien befinden sich im selben Verzeichnis, in dem LTESniffer ausgeführt wurde.
Damit WireShark die dekodierten Pakete korrekt analysieren kann, beachten Sie bitte die WireShark-Konfigurationsanleitung hier. Es gibt auch einige Beispiele für pcap-Dateien unter dem Link.
Hinweis: Die Uplink-pcap-Datei enthält sowohl Uplink- als auch Downlink-Nachrichten. Verwenden Sie in WireShark diesen Filter, um nur Uplink-Nachrichten zu überwachen: mac-lte.direction == 0; oder diesen Filter, um nur Downlink-Nachrichten zu überwachen: mac-lte.direction == 1.
Die effektive Reichweite zum Abhören des Uplinks ist bei LTESniffer aufgrund der Fähigkeiten des HF-Frontends der Hardware (d. h. SDR) begrenzt. Die Uplink-Signalleistung des UE ist deutlich schwächer als das Downlink-Signal, da das UE ein Handgerät ist, das den Akkuverbrauch optimiert, während die eNB ausreichend Leistung verwendet, um einen großen Bereich abzudecken. Um den Uplink-Datenverkehr erfolgreich zu erfassen, kann LTESniffer die Signalleistung erhöhen, indem es i) physisch nahe am UE ist oder ii) die Signalempfangsfähigkeit mit spezieller Hardware wie einer Richtantenne, einem dedizierten HF-Frontend und einem Signalverstärker verbessert.
Downlink-Sniffing-Modus
Processed 1000/1000 subframes: Anzahl der Subframes, die von LTESniffer in der letzten Sekunde verarbeitet wurden. Es gibt konstruktionsbedingt 1000 LTE-Subframes pro Sekunde.
RNTI: Radio Network Temporary Identifier der UEs.
Table: Das maximale Modulationsschema, das von Smartphones im Downlink verwendet wird. LTESniffer unterstützt bis zu 256QAM im Downlink. Weitere Informationen finden Sie in unserem Paper.
Active: Anzahl der erkannten Nachrichten der RNTIs.
Success: Anzahl der erfolgreich dekodierten Nachrichten im Verhältnis zu den erkannten Nachrichten (Active).
New TX, ReTX, HARQ, Normal: Statistik neuer und erneut gesendeter Nachrichten. Diese Funktion befindet sich in der Entwicklung.
W_MIMO, W_pinfor, Other: Anzahl der Nachrichten mit falscher Funkkonfiguration, nur zum Debuggen.
Uplink-Sniffing-Modus
Max Mod: Das maximale Modulationsschema, das von Smartphones im Uplink verwendet wird. Es kann 16/64/256QAM sein, abhängig von der Unterstützung der Smartphones und der Konfiguration des Netzwerks. Weitere Informationen finden Sie in unserem Paper.
SNR: Signal-Rausch-Verhältnis (dB). Ein niedriger SNR bedeutet, dass die Uplink-Signalqualität des Smartphones schlecht ist. Ein möglicher Grund ist, dass das Smartphone weit vom Sniffer entfernt ist.
DL-UL_delay: Die durchschnittliche Zeitverzögerung zwischen dem Downlink-Signal der Basisstation und dem Uplink-Signal des Smartphones.
Other Info: Nur Informationen zum Debuggen.
API-Modus
Detected Identity: Der Name der erkannten Identität.
Value: Der Wert der erkannten Identität.
From Message: Der Name der Nachricht, die die erkannte Identität enthält.
Wir danken dem FALCON-Team und dem SRS-Team aufrichtig für die Bereitstellung ihrer großartigen Software.
Besonderer Dank gilt allen Mitwirkenden, die uns halfen, Fehler zu beheben und LTESniffer zu verbessern:
Weitere Informationen finden Sie in unserem Paper.
@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}
}
F: Ist es zwingend erforderlich, GPSDO mit dem USRP zu verwenden, um LTESniffer auszuführen?
A: GPSDO ist für eine stabilere Synchronisation nützlich. Im Downlink-Sniffing-Modus kann LTESniffer jedoch auch ohne GPSDO mit dem LTE-Signal synchronisieren, um Pakete zu dekodieren. Im Uplink-Sniffing-Modus ist GPSDO nur erforderlich, wenn 2 USRP-B-Serien verwendet werden, da es als Zeit- und Taktreferenz für die Synchronisation zwischen Uplink- und Downlink-Kanälen dient. Eine andere Uplink-SDR-Option, die Verwendung eines einzelnen USRP X310, benötigt kein GPSDO.
F: Kann ich für den Downlink-Datenverkehr ein günstigeres SDR verwenden?
A: Technisch gesehen kann jedes von der srsRAN-Bibliothek unterstützte SDR wie Blade RF verwendet werden, um LTESniffer im Downlink-Sniffing-Modus auszuführen. Wir haben die Downlink-Sniffing-Funktion von LTESniffer jedoch nur mit USRP B210 und X310 getestet.
F: Ist es illegal, LTESniffer zum Abhören von LTE-Datenverkehr zu verwenden?
A: Sie sollten die örtlichen Vorschriften zum Abhören (unverschlüsselten) LTE-Datenverkehrs prüfen. Eine andere Möglichkeit, LTESniffer zu testen, ist die Einrichtung eines persönlichen LTE-Netzwerks mit srsRAN – einer Open-Source-LTE-Implementierung in einem Faraday-Käfig.
F: Kann LTESniffer verwendet werden, um den Inhalt von Nachrichten zwischen zwei Benutzern einzusehen?
A: Man kann nur den „unverschlüsselten“ Teil der Nachrichten sehen. Beachten Sie, dass der Datenverkehr zwischen der Basisstation und den Benutzern größtenteils verschlüsselt ist.
F: Wird im LTE-Netzwerk eine Geräteidentität im Klartext preisgegeben?
A: Ja, die Literatur zeigt, dass mehrere Identitäten preisgegeben werden, wie z. B. TMSI, GUTI, IMSI und RNTI. Weitere Informationen finden Sie in der akademischen Literatur, z. B. Watching the Watchers: Practical Video Identification Attack in LTE Networks.