titiomathias/sec-for-ble
GitHub: titiomathias/sec-for-ble
Stars: 0 | Forks: 0
# Offensive Security for Bluetooth Low Energy
Laboratório didático para demonstrar ataques em BLE usando duas ESP32 vulneráveis e uma API externa que simula a casa inteligente em tempo real.
## Objetivo do cenário
Este projeto foi desenhado para aulas práticas de segurança ofensiva em Bluetooth Low Energy:
- `ESPA (home)` atua como periférico BLE vulnerável e controla o estado da casa.
- `ESPB (client)` atua como central BLE e envia comandos.
- `Smart Home API` representa a casa no navegador, registra eventos e facilita visualizar o impacto dos ataques.
O foco é reproduzir, observar e explicar comportamentos inseguros como escrita não autenticada, replay e personificação de cliente BLE.
## Arquitetura
[ESPB_CLIENT_VULN] --BLE plaintext--> [ESPA_HOME_VULN] --HTTP--> [Smart Home API + UI]
| | |
(comandos) (sem auth BLE) (estado + eventos)
## Estrutura do repositório
.
├── espa_home_vuln/
│ └── espa_home_vuln.ino # ESPA: periférico BLE vulnerável + integração HTTP com API
├── espb_client_vuln/
│ └── espb_client_vuln.ino # ESPB: central BLE vulnerável (auto/demo/manual)
└── smarthome/
├── app/main.py # FastAPI + WebSocket + painel visual
├── app/state_store.py # Persistência e trilha de eventos
├── data/state.json # Estado da casa
└── requirements.txt
## Vulnerabilidades intencionais
No firmware `espa_home_vuln`:
- Sem pairing/bonding obrigatório.
- Sem criptografia de enlace BLE.
- Comandos em texto plano (`SALA:ON`, `COZINHA:OFF`, etc.).
- Sem nonce/counter/token anti-replay.
- Characteristic de comando com permissão aberta para escrita.
No firmware `espb_client_vuln`:
- Cliente envia comandos em texto puro.
- Fluxo de automação facilita gerar tráfego repetível para replay/demonstração.
## Protocolo BLE usado no lab
- `BLE_DEVICE_NAME` (home): `ESP32_HOME_VULN`
- `SERVICE_UUID`: `b7e15000-7d99-4c80-9a9e-b8d537d9e111`
- `CMD_CHAR_UUID`: `b7e15001-7d99-4c80-9a9e-b8d537d9e111` (write)
- `STATE_CHAR_UUID`: `b7e15002-7d99-4c80-9a9e-b8d537d9e111` (read/notify)
Comandos aceitos pela casa:
- `SALA:ON` / `SALA:OFF`
- `COZINHA:ON` / `COZINHA:OFF`
- `BANHEIRO:ON` / `BANHEIRO:OFF`
- `STATUS`
- `RESET`
## Subindo a API da casa (simulador externo)
Pré-requisitos:
- Python 3.10+
Passos:
cd smarthome
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
cd app
python3 main.py
A API sobe em:
- `http://127.0.0.1:8080`
- `http://SEU_IP_LOCAL:8080` (para acesso na mesma rede das ESPs)
## Configuração das ESPs
### ESPA (casa vulnerável)
Arquivo: `espa_home_vuln/espa_home_vuln.ino`
Ajuste estes valores antes do upload:
- `WIFI_SSID`
- `WIFI_PASS`
- `API_BASE_URL` (ex.: `http://192.168.0.10:8080`)
Compile com stack NimBLE-Arduino e faça upload para a ESP32 da casa.
### ESPB (cliente vulnerável)
Arquivo: `espb_client_vuln/espb_client_vuln.ino`
Faça upload para a ESP32 cliente. Ela faz scan, conecta no serviço BLE e permite:
- Modo automático (comandos aleatórios periódicos)
- Modo demo (sequência guiada)
- Modo manual via serial (qualquer comando de texto)
## Como rodar a demonstração
1. Suba a API (`python3 main.py`) e abra o painel web.
2. Ligue a ESPA (`ESP32_HOME_VULN`) e confirme que está em advertising.
3. Ligue a ESPB e aguarde conexão BLE.
4. Envie comandos via serial da ESPB (`demo`, `STATUS`, `SALA:ON`, etc.).
5. Observe no painel a alteração em tempo real (WebSocket + eventos).
## Cenários de ataque para visualizar em aula
1. Escrita BLE não autenticada
Use outro central BLE (ex.: app genérico BLE no celular) para escrever direto em `CMD_CHAR_UUID`.
Resultado esperado: estado da casa muda sem necessidade do cliente legítimo.
2. Replay de comando
Reenvie comandos válidos capturados anteriormente.
Resultado esperado: ações se repetem porque não há nonce/counter nem verificação de frescor.
3. Personificação de cliente
Um atacante enviando payloads no formato esperado (`SALA:ON`, `COZINHA:OFF`, etc.) obtém o mesmo efeito operacional.
Resultado esperado: API registra eventos com origem técnica, mas sem garantia de identidade confiável.
## Endpoints principais da API
- `GET /api/state` -> snapshot atual da casa
- `POST /api/command` -> aplica ação por alvo
- `PATCH /api/state/{device_type}/{device_id}` -> muda estado direto
- `GET /api/events?limit=20` -> histórico de eventos
- `POST /api/reset` -> reseta cenário
- `WS /ws` -> atualizações em tempo real para o painel
Exemplo de comando via API:
curl -X POST http://127.0.0.1:8080/api/command \
-H 'Content-Type: application/json' \
-d '{"target":"doors.front","action":"open","source":"attacker-replay"}'
## Uso responsável
Projeto destinado a laboratório controlado, ambiente de ensino e pesquisa autorizada. Não utilize estas técnicas em dispositivos, redes ou sistemas sem permissão explícita.