MÓDULO 17 — IoT & EMBEDDED (com análise de firmware completa)

MÓDULO 17 — IoT & EMBEDDED (com análise de firmware completa) Objetivo: obter um firmware, extrair o filesystem, analisar o sistema de arquivos (segredos, senhas hardcoded, backdoors), emular o dispositivo e explorar as falhas encontradas — rodando tudo no seu Kali sem hardware físico.

MÓDULO 17 — IoT & Embedded: Tópico 1 — O que é IoT/Embedded IoT = Internet of Things: câmeras, roteadores, sensores, fechaduras, campainhas, lâmpadas, TVs, termostatos, tratores, bombas de insulina, usinas. Tudo com um chip, um firmware e (quase sempre) uma conexão de rede.

Embedded = sistemas dedicados embarcados em hardware específico, rodando Linux embarcado (OpenWRT, Buildroot, Yocto) ou RTOS (FreeRTOS).

Por que é um FILÃO de vulnerabilidades:

- Firmware raramente é atualizado (patch = comprar um novo)
- Senhas HARDCODED no código (admin:admin, root:root)
- Serviços de depuração em portas de produção (telnet, SSH debug, serial/UART)
- Backdoors intencionais do fabricante (para suporte técnico — e para você)
- HTTP em vez de HTTPS, sem criptografia
- Chaves privadas/certificados embutidos no firmware
- Protocolos inseguros (MQTT sem auth, Modbus sem criptografia)
- (Módulo 15 — IoT na nuvem: a mesma câmera manda dados para um bucket S3 público)

A cadeia de ataque típica:

• Obter firmware (download do site, dump via hardware, update OTA)
• Analisar firmware (extrair, descomprimir, montar filesystem)
• Enumerar (credenciais, backdoors, endpoints, chaves, serviços)
• Emular (rodar o firmware em QEMU para testes dinâmicos)
• Explorar (logar com as credenciais, abusar serviços, interceptar tráfego)
• Escalar (se for roteador/câmera → pivô para rede interna — Módulo 7/14)
• Laboratório para este módulo: 100% no Kali com firmware reais de dispositivos de código aberto (OpenWRT, DD-WRT, firmware de câmeras antigas) ou firmware de laboratório (OWASP IoT Goat, DAMN-VULNERABLE-IOT). Nunca baixe firmware de dispositivos de terceiros sem autorização — mas firmwares open source como OpenWRT e dd-wrt são públicos e livres para estudo.

MÓDULO 17 — IoT & Embedded: Tópico 2 — Fundamentos sobre firmware O que é um firmware É a imagem de software que roda no dispositivo. Geralmente é um arquivo binário que contém:

firmware.bin ├── bootloader (u-boot, barebox) ├── kernel (Linux zImage) ├── filesystem (squashfs, jffs2, ubifs, cramfs, ext4, initramfs) ├── dispositivo tree (.dtb) └── (às vezes: assinatura criptográfica no cabeçalho) Como identificar o formato do filesystem

# O binário pode ser um archive, um squashfs, ou um dump cru.
# Três formas de descobrir:
file firmware.bin
binwalk firmware.bin            # ★ a ferramenta principal (analisa e extrai)
strings firmware.bin | grep -i "squashfs|ubifs|jffs2|cramfs|initramfs"
As proteções comuns (e como quebrá-las)


| Proteção | Bypass / Nota |
| --- | --- |
| Assinatura criptográfica | Se a chave pública estiver no firmware, você pode assinar seus próprios firmwares. Se não, extraia o filesystem por dump físico (UART/JTAG) ou busque versão não assinada. |
| Criptografia do firmware | Raro — a chave geralmente está no bootloader ou no hardware. Para este módulo, assumimos firmware sem criptografia (80% dos casos). |
| Secure Boot | Requer dump físico ou ataque ao bootloader. Fora do escopo deste módulo introdutório. |
| TPM / SE / Enclaves | Hardware de segurança avançado. Não abordamos aqui. |
Regra do módulo: firmware sem criptografia = 80% dos casos reais. Firmware com assinatura mas chave pública extraível = outros 15%. Os 5% restantes (Secure Boot + criptografia) são o estado da arte.

## MÓDULO 17 — IoT & Embedded: Tópico 3 — A caixa de ferramentas do embedded hacker

bash

# Ferramentas essenciais (todas no Kali): sudo apt install binwalk firmware-mod-kit qemu-system-arm qemu-system-mips qemu-user-static binfmt-support uml-utilities mtd-utils gdbserver pip install cstruct # (para binwalk) # EXTRA: # - FAT (flash app tester) — para testes de interface # - Firmwalker (script de enumeração pós-extração) # - Fritsi / GreatFET / USBArmory — hardware (não vamos usar neste módulo)

# Firmwalker — baixe: git clone https://github.com/craig/owasp-firmware-analysis-toolkit # (ou manualmente: https://github.com/craig/firmwalker)

| Ferramenta | Papel |
| --- | --- |
| binwalk | Escanear e extrair firmware (assinaturas, compressão, filesystem) |
| sasquatch | Extrair squashfs (variações não padrão) |
| jefferson | Extrair JFFS2 |
| firmware-mod-kit | Extrair/recompactar firmwares conhecidos |
| firmwalker | Enumerar firmware extraído (procura senhas, chaves, endpoints) |
| strings | O canivete — sempre comece com strings |
| QEMU | Emular o firmware (arquitetura ARM/MIPS) |
| tcpdump / socat | Simular rede para o firmware emulado |

MÓDULO 17 — IoT & Embedded: Tópico 4 — Análise de firmware completa Vamos usar o firmware do OpenWRT (legítimo, open source, download público) ou o DAMN-VULNERABLE-IOT-FIRMWARE (de lab). Para a prática, baixe um firmware de roteador antigo (TP-Link, D-Link) de sites de suporte — desde que seja para estudo de segurança em laboratório e você não esteja visando um dispositivo ativo.

PASSO 1 — Obter o firmware

# Firmware de laboratório (OpenWRT — qualquer versão antiga):
wget https://downloads.openwrt.org/releases/19.07.7/targets/.../openwrt-19.07.7-bcm47xx...trx

# OU firmware de lab vulnerável (recomendado para estudo):
git clone https://github.com/scriptingxss/owasp-iot-goat
# OU baixe o firmware de um roteador antigo TP-Link/D-Link do site do fabricante
# (para estudo local — nunca em produção)

PASSO 2 — Análise inicial (file + strings + binwalk)

# 2a. Identificar o tipo
file firmware.bin
# Saída: data, ou "TRX firmware image"

# 2b. Strings rápidas (o que o firmware contém?)
strings firmware.bin | head -200
strings firmware.bin | grep -i "admin|root|password|passwd|telnet|ssh|debug|backdoor|version"
strings firmware.bin | grep -iE "https?://[a-zA-Z0-9./_-]+" | sort -u
strings firmware.bin | grep -iE "AKIA|sk-|secret|token"   # credenciais de nuvem!

# 2c. Binwalk — a ferramenta principal
binwalk firmware.bin
# Saída:
# DECIMAL    HEX        DESCRIPTION
# 0          0x0        TRX firmware header, little-endian
# 126        0x7E       LZMA compressed data
# 2166528    0x210D80   Squashfs filesystem, little-endian

# Extrair TUDO:
binwalk -e firmware.bin
# Cria diretório _firmware.bin.extracted/ com os componentes

PASSO 3 — Extrair o filesystem (quando o binwalk não extrai sozinho)

# Se o binwalk não extraiu o squashfs sozinho (assinatura não reconhecida):
# Tente manualmente:
# 1. Achar o offset do squashfs (pelo binwalk ou forca bruta com ranges)
# 2. Extrair:
dd if=firmware.bin of=squashfs_part.bin bs=1 skip=<OFFSET>
unsquashfs squashfs_part.bin
# (se falhar: sasquatch ou jefferson)

# firmware-mod-kit (para firmwares comuns de roteador):
./extract-firmware.sh firmware.bin

PASSO 4 — Montar o filesystem extraído

# Se o extrair gerou diretório:
ls -la _firmware.bin.extracted/
# Procure um diretório "squashfs-root/" ou "rootfs/"

cd _firmware.bin.extracted/squashfs-root
# Você está no sistema de arquivos do dispositivo!
ls -la etc/ bin/ sbin/ usr/ lib/ www/ webroot/ (varia por firmware)

PASSO 5 — Enumeração do filesystem (firmwalker + manual)

# 5a. Firmwalker (automatizado, ferramenta separada):
cd ~/firmwalker
./firmwalker.sh <caminho-do-squashfs-root>

# 5b. Manual — o checklist de ouro:

# SENHAS E CREDENCIAIS
grep -rni "password|passwd|senha" etc/ 2>/dev/null
cat etc/shadow       # hashes de senha! (root:$1$...)
cat etc/passwd       # usuários com shell
cat etc/config/*.conf 2>/dev/null | grep -i "pass|key|secret"
find . -name "*.conf" -o -name "*.cfg" -o -name "*.ini" 2>/dev/null | xargs grep -l "password|secret|key" 2>/dev/null

# BACKDOORS / SERVIÇOS
cat etc/inittab       # serviços iniciados no boot
cat etc/init.d/*     # scripts de inicialização
grep -r "telnet|ssh|debug|backdoor|shell" etc/ 2>/dev/null
find . -name "*debug*" -o -name "*backdoor*" -o -name "*test*" 2>/dev/null

# CHAVES E CERTIFICADOS
find . -name "*.pem" -o -name "*.key" -o -name "*.crt" -o -name "*.cert" 2>/dev/null
find . -name "id_rsa" -o -name "*.pub" 2>/dev/null
cat etc/ssl/certs/* 2>/dev/null

# ENDPOINTS E URLs (nuvem, MQTT, API)
grep -rE "https?://[a-zA-Z0-9./_-]+" . 2>/dev/null | grep -v ".svg|.png|.jpg" | sort -u
grep -r "mqtt|coap|amqp|dns" . 2>/dev/null

# BINÁRIOS SUSPEITOS
find . -perm -4000 -type f 2>/dev/null        # SUID (Módulo 11)
find . -name "*.sh" -exec grep -l "sh|bash|exec|system|/bin" {} ;

# ARQUIVOS DE CONFIGURAÇÃO DE REDE
cat etc/config/wireless 2>/dev/null    # WiFi — SSID e senha!
cat etc/config/network 2>/dev/null     # IPs, VLANs

PASSO 6 — Análise de binários do firmware Se você encontrar binários suspeitos (ex.: um backdoor telnetd customizado, um serviço HTTP proprietário):

# Identificar o binário:
file sbin/telnetd
strings sbin/telnetd | grep -i "password|debug|backdoor|key"
# Extrair versão:
strings sbin/telnetd | grep -i "version|v[0-9].[0-9]"
# Se for um servidor HTTP proprietário:
strings usr/sbin/httpd | grep -i "uri|login|admin|pass|cmd"

# Arquitetura (para emulação — QEMU):
readelf -h sbin/telnetd | grep Machine
# → ARM, MIPS, x86, etc.

PASSO 7 — Emular o firmware (QEMU — o ápice da análise) Emular permite rodar o firmware sem o hardware físico e interagir com ele (testar login, explorar serviços, interceptar tráfego).

# 7a. Instalar QEMU para a arquitetura correta
sudo apt install qemu-system-arm qemu-user-static binfmt-support

# 7b. Copiar o qemu-static para o filesystem extraído
cp /usr/bin/qemu-arm-static squashfs-root/usr/bin/
# (ou qemu-mips-static, qemu-aarch64-static — conforme a arquitetura)

# 7c. Usar chroot para executar dentro do filesystem
#    (se o firmware só tiver um busybox, rode /bin/sh):
sudo chroot squashfs-root /bin/sh
# Agora você está "dentro" do dispositivo emulado!

# 7d. Se o firmware for mais complexo (ex.: servidor web), configure rede:
sudo apt install uml-utilities
sudo tunctl -t tap0
sudo ifconfig tap0 10.0.0.1/24 up
# Dentro do chroot (se /etc/inittab configurar rede):
# ifconfig eth0 10.0.0.2 up
# Acesse o webserver: curl http://10.0.0.2
Ferramenta que automatiza tudo: Firmadyne (projeto de emulação automatizada de firmware). Se quiser aprofundar, instale:

bash

git clone https://github.com/firmadyne/firmadyne

⚠️ Limitação da emulação: nem todo firmware emula perfeitamente — alguns dependem de hardware específico (watchdog, GPIO, RTC). Emule o essencial: shell e serviços de rede.

## MÓDULO 17 — IoT & Embedded: Tópico 5 — Hacking de hardware (UART/JTAG)
Quando o firmware é criptografado ou assinado, a porta de entrada é o hardware físico. Aqui você precisa de:

Adaptador USB-UART (CP2102, FTDI) — ~R$20
Jumpers / probes
Multímetro (para achar pinos)
Lógica: UART = 3 fios (TX, RX, GND); JTAG = 5 (TMS, TCK, TDO, TDI, GND)
Achar UART na placa

text

• Procure por 4 pinos alinhados (geralmente próximo ao processador)
• Teste com multímetro: GND = 0V (massa), TX = ~3.3V (oscila se o dispositivo ligar)
• Conecte o adaptador: GND→GND, TX do dispositivo → RX do adaptador, RX→TX
• Abra o terminal: screen /dev/ttyUSB0 115200 (ou 9600/57600/38400)
• Ligue o dispositivo → aparecem os logs de boot! (e um shell de login)

O que o UART/JTAG dá acesso

text

• Console serial: shell (geralmente root sem senha!) no boot
• Bootloader interrompível (u-boot → parar boot e modificar parâmetros)
• Dump da flash inteira (via u-boot: tftp, md/mw, ou via shell: cat /dev/mtd*)
• JTAG → depuração total do processador (acesso a registradores, memória)

A regra de ouro: se o dispositivo tem UART exposto (mesmo que não soldado), você tem 99% de chance de conseguir um shell root — sem quebrar nada.

## MÓDULO 17 — IoT & Embedded: Tópico 6 — Protocolos IoT (MQTT, Modbus, CoAP)
MQTT (Message Queuing Telemetry Transport)
O protocolo mais comum em IoT. Funciona no modelo publish/subscribe com um broker (servidor). Se não tem autenticação (padrão!), você se inscreve em tópicos e escuta tudo:

bash

# Testar conexão sem auth: mosquitto_sub -h IP_DO_BROKER -t "#" -v # "#" é o wildcard: todos os tópicos! # Saída típica: temperatura/sensor1 25.3 # alarme/porta aberta # sensor/gps -23.5,-46.6 (localização!)

# Publicar comandos (se houver atuadores): mosquitto_pub -h IP_DO_BROKER -t "alarme/disparar" -m "1" Achados típicos: broker sem senha → ler dados de sensores, publicar comandos falsos (abrir porta, desligar alarme, mudar temperatura). É o "S3 bucket" do mundo IoT.

Ferramenta: mqtt-pwn (framework de ataque MQTT).

Modbus (controle industrial — SCADA/ICS) Protocolo serial (RTU) ou TCP (porta 502). Lê e escreve em registradores (coils, inputs, holding registers):

# Scaneamento de dispositivos Modbus TCP:
nmap -p 502 --script modbus-discover IP
# Leitura de registros (com modbus-cli ou modbus-tk):
python3 -c "
from pymodbus.client import ModbusTcpClient
c = ModbusTcpClient('IP_DO_DISPOSITIVO', port=502)
c.connect()
# Ler coils (saídas binárias):
rr = c.read_coils(0, 100)
print('Coils:', rr.bits)
# Ler holding registers (valores analógicos/config):
rr = c.read_holding_registers(0, 50)
print('Registers:', rr.registers)
# Escrever coil (ATENÇÃO: só em lab autorizado!):
c.write_coil(0, True)
"

CoAP (Constrained Application Protocol) Similar ao HTTP, mas sobre UDP. Sem DTLS (criptografia), os recursos são expostos:

# Usando libcoap:
coap-client -m get coap://IP_DO_SENSOR/temperatura
coap-client -m put coap://IP_DO_ATUADOR/lampada -e "on"

Regra de segurança nestes protocolos: autenticação é rara, criptografia é exceção, e o impacto (abrir porta, desligar sistema, ler localização) é altíssimo.

MÓDULO 17 — IoT & Embedded: Tópico 7 — A ordem do teste IoT (fluxo profissional)

• ESCOPO: qual dispositivo, versão do firmware, interface (rede/wireless/física)
• RECON:
• - Web: busca por vulnerabilidades conhecidas do modelo (Módulo 6)
• - Shodan: portas expostas do modelo (Módulo 4)
• - Firmware: baixar e analisar (este módulo)
• ANÁLISE DE FIRMWARE (estática — 17.4):
• - Extrair filesystem → senhas, chaves, endpoints, backdoors
• - Binwalk + strings + firmwalker
• ANÁLISE DE REDE:
• - Portas abertas (nmap), protocolos (MQTT, Modbus, HTTP), credenciais padrão
• - Interceptar tráfego (se o dispositivo permite)
• EMULAÇÃO (se possível — 17.4 Passo 7):
• - Rodar firmware no QEMU → testar login, serviços, exploits
• EXPLORAÇÃO:
• - Login com credenciais padrão/hardcoded
• - Backdoor no firmware (telnet, depuração)
• - Comando no shell do dispositivo (shell reverso — Módulo 7)
• PÓS-EXPLORAÇÃO (se ganhar shell):
• - Escalar para root (Módulo 11 — geralmente já é root em IoT)
• - Coletar dados, interceptar tráfego da rede interna (pivô — Módulo 7/12)
• - Persistência (Módulo 12 — chave SSH)
• RELATÓRIO (Módulo 3): cada achado com evidência (strings, protocolo, login)
• ## MÓDULO 17 — IoT & Embedded: Tópico 8 — Defesas e correções

Setup: instale binwalk, firmwalker, QEMU (17.3) Baixe um firmware: OpenWRT antigo (ex.: 19.07.x para bcm47xx) ou firmware de câmera antiga de um site de suporte público Análise inicial: file, strings (credenciais, URLs), binwalk — documente os achados Extraia: binwalk -e — monte o squashfs-root Enumere: firmwalker + checklist manual (17.4 Passo 5) — encontre: 1 senha hardcoded (ex.: em /etc/shadow) 1 endpoint/URL (ex.: nuvem do fabricante) 1 binário com SUID ou backdoor Emule (se possível): copie qemu-arm-static, chroot, rode /bin/sh MQTT (lab): suba um broker mosquito sem senha no Kali (mosquitto -p 1883), publique e subscreva com mosquitto_pub/sub; veja como é trivial Modbus (lab): suba um simulador Modbus (ex.: modbus-server-simulator ou pymodbus) e leia registros com o script Python do 17.6 UART (se tiver hardware): conecte o adaptador a um dispositivo de teste (roteador antigo, placa de desenvolvimento como Raspberry Pi em modo UART); capture o boot log e veja o shell Desafio — a análise completa de firmware: crie iot_firmware_report.md em ~/pentest/evidencias/iot/ com:

firmware usado (origem, versão, arquitetura, download) análise inicial (file + strings — screenshots) extração do filesystem (binwalk + comandos) enumeração (firmwalker + manual): tabela de senhas, chaves, endpoints, backdoors encontrados emulação (se funcionou): tela do QEMU, comandos rodados para cada achado: impacto (senha hardcoded = acesso root ao dispositivo) + correção (17.8) ### ✅ Checklist de conclusão do Módulo 17 Entendo o que é firmware e sua estrutura (bootloader, kernel, filesystem) Uso binwalk para analisar e extrair firmware Extraio o filesystem (squashfs, jffs2) e monto em diretório Enumero com firmwalker + manual: senhas, chaves, endpoints, backdoors Analiso binários do firmware (strings, arquitetura, SUID) Emulo firmware com QEMU (qemu-user-static + chroot) Conheço UART e JTAG (conceito: o que são e o que entregam) Sei testar MQTT (mosquitto_sub/pub sem auth) e Modbus (pymodbus) Conheço CoAP e o básico de protocolos industriais Sei o fluxo profissional de teste IoT do começo ao relatório Documento achados e recomendo correções (17.8)

---