32100/UDP - Pentesting PPPP (CS2) P2P Cámaras

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Resumen

PPPP (a.k.a. “P2P”) es una pila propietaria de conectividad de dispositivos de CS2 Network ampliamente integrada en cámaras IP de bajo costo y otros dispositivos IoT. Proporciona rendezvous, NAT traversal (UDP hole punching), un “stream” de aplicación con retransmisión “fiable” sobre UDP y un esquema de direccionamiento basado en ID, permitiendo que una app móvil/desktop alcance dispositivos en cualquier lugar de Internet con sólo conocer un device ID.

Rasgos clave relevantes para atacantes:

  • Los dispositivos se registran en tres rendezvous servers operados por el vendor por cada prefijo de ID. Los clients consultan los mismos servers para encontrar la dirección externa/relay del dispositivo y luego intentan UDP hole punching. Existe fallback a relay.
  • El listener por defecto del server es accesible por UDP/32100. Una sonda mínima “hello” es suficiente para fingerprint servers y algunos devices.
  • Existe un blanket cipher opcional y un modo especial “CRCEnc”, pero son débiles por diseño y típicamente están deshabilitados en ecosistemas populares (p. ej., LookCam).
  • El control plane suele ser comandos JSON sobre el PPPP stream y comúnmente sufre de falta de auth y bugs de seguridad de memoria.

Formato típico de device ID (familia LookCam): PREFIX-######-CCCCC, acortado en apps (p. ej., GHBB-000001-NRLXW → G000001NRLXW). Prefijos observados: BHCC (“hekai”), FHBB y GHBB (“mykj”).

Discovery and Enumeration

  • Internet exposure: muchos PPPP super-nodes responden a una sonda UDP/32100. Respuestas con plaintext conocido y cadenas de error las hacen fáciles de identificar en capturas de tráfico y con scanners de Internet.
  • LAN discovery: los devices a menudo responden a una búsqueda no cifrada en broadcast local. Usa el script de Paul Marrapese para enumerar:
  • https://github.com/pmarrapese/iot/tree/master/p2p/lansearch

Notas:

  • Las apps incluyen “init strings” que contienen listas de IPs de servers ofuscadas y keys del protocolo. Estas strings son triviales de extraer de clientes Android/iOS/Windows y a menudo se reutilizan entre muchas líneas de producto.

NAT Traversal and Transport

  • Los rendezvous servers aprenden el mapping público del dispositivo mediante keepalives periódicos desde el device. Los clients consultan los servers por el mapping y luego intentan flujos UDP directos usando hole punching. Si el NAT traversal falla, el tráfico es relayed por hosts PPPP designados.
  • El “stream” de aplicación implementa su propia lógica de ACK/retx sobre UDP; los bucles de retransmisión están duplicados en muchos paths de código y pueden inundar enlaces con pérdida.

Weak “Encryption” and Key Recovery

Existen dos mecanismos ineficaces en la pila CS2:

  1. Blanket cipher (opcional) – P2P_Proprietary_Encrypt
  • Usualmente deshabilitado por OEMs que usan LookCam.
  • La “init string” del lado de la app provee el material de key que se reduce a una key efectiva de 4 bytes (~2^32 espacio).
  • Plaintext práctico conocido: los primeros 4 bytes de MSG_HELLO a UDP/32100 se conocen como F1 00 00 00. Observar un único handshake cifrado permite una recuperación o validación rápida de la key.
  • Algunos mensajes de control (p. ej., MSG_REPORT_SESSION_READY) siempre están cifrados con una key hardcodeada en la librería compartida entre apps.
  1. Registration “encryption” – PPPP_CRCEnc
  • A pesar del nombre, esto no es CRC. Es un keystream XOR repetido fijo con una verificación de padding de 4 bytes (no autenticada).
  • Las redes LookCam típicamente usan CRCEnc sólo para el registro device → server (MSG_DEV_LGN_CRC). La mayor parte del resto del tráfico permanece en plaintext.

Recuperación simple del keystream para PPPP_CRCEnc (Python):

# ciphertext: captured bytes of an encrypted registration message
# known: guessed/known plaintext region (e.g., JSON or constant header)
keystream = bytes([c ^ p for c, p in zip(ciphertext[:len(known)], known)])
# Decrypt more bytes by XORing with the repeating keystream
pt = bytes([c ^ keystream[i % len(keystream)] for i, c in enumerate(ciphertext)])

Desajuste del modelo de amenaza: los materiales de CS2 se centran en prevenir DoS mediante registros falsos de dispositivos, no en la confidencialidad. Esto explica la “encryption” selectiva del registro mientras que el video/control permanece opcional o en cleartext. Los servidores PPPP históricos no implementan rate limiting, lo que permite brute-force/abuse a escala.

Control Plane: JSON Commands and Auth Bypass

Muchos firmwares de cámaras PPPP intercambian mensajes JSON una vez que la sesión está establecida. Ejemplo de “login” que el cliente envía:

{
"cmd": "LoginDev",
"pwd": "123456"
}

Vulnerabilidad común en dispositivos de la clase LookCam:

  • El firmware ignora tanto el flujo LoginDev como los campos pwd por petición (CWE-287, CWE-306). El dispositivo acepta comandos operativos sin validar una contraseña.
  • Explotación: no envíes LoginDev o ignora su resultado; envía los comandos directamente.

Comandos útiles observados:

  • searchWiFiList – ejecuta iwlist; deja la salida cruda en /tmp/wifi_scan.txt.
  • DownloadFile – primitiva para leer rutas arbitrarias sin restricciones.

Flujo de trabajo para desanonimizar la ubicación mediante artefactos transitorios:

  1. Envía {“cmd”:“searchWiFiList”}.
  2. Lee /tmp/wifi_scan.txt mediante DownloadFile.
  3. Envía los BSSID MACs a una API de geolocalización (p. ej., Google Geolocation API) para localizar la cámara con una precisión de decenas de metros.

De seguridad de memoria a RCE en firmware embebido

Patrón inseguro típico (pseudocódigo de los manejadores):

char buf[256];
char *cmd = cJSON_GetObjectItem(request, "cmd")->valuestring;
memset(buf, 0, sizeof(buf));
memcpy(buf, cmd, strlen(cmd)); // no bound check
  • Trigger: cualquier cmd string > 255 bytes causa un stack buffer overflow (CWE-120/121).
  • Protections: no stack canary; DEP/NX and ASLR commonly disabled on these builds.
  • Impact: straightforward single-stage shellcode or classic ROP/ret2libc on the device’s CPU (e.g., ARM) for full compromise and LAN pivoting.

See also:

Stack Overflow

Ret2lib

Abuso de almacenamiento en la nube (HTTP, Device-ID only)

Muchos firmwares de la marca LookCam suben grabaciones a api.l040z.com (apicn.l040z.com para BHCC) únicamente por HTTP. Observaciones:

  • No hay TLS en el firmware; el transporte es HTTP en texto claro.
  • La “autenticación” de la API es solo Device-ID: cualquiera que conozca el ID puede obtener las grabaciones.
  • El particionado en fragmentos de 5 MiB está codificado (hardcoded).
  • Habilitación remota: al arrancar el dispositivo llama a http://api.l040z.com/camera/signurl; la respuesta del servidor decide si comienzan las subidas. La app móvil puede mostrar la nube “disabled” incluso cuando se realizan subidas. Un tercero puede comprar/habilitar cloud para un ID víctima y recolectar grabaciones en silencio.

Esto es una transmisión de datos sensibles en texto claro clásica (CWE-319) con falta de authZ en el servidor.

Enumeración y adivinanza de Device-ID

  • Formato de ID: PREFIX-######-CCCCC y forma abreviada por la app (p. ej., GHBB-000001-NRLXW → G000001NRLXW).
  • Familias de prefijos: BHCC (hekai servers), FHBB y GHBB (mykj servers). Cada prefijo mapea a tres servidores de rendezvous para HA.
  • El verificador de 5 letras usa un alfabeto de 22 letras mayúsculas (se excluyen A, I, O, Q) → 22^5 ≈ 5.15M combinaciones por base numérica.
  • Trabajos previos observaron ausencia de rate-limiting en el servidor, lo que hace práctico el adivinado distribuido. El algoritmo del verificador es bespoke y probablemente adivinable o obtenible al reversar apps/firmware.

Fuentes prácticas de IDs:

  • Mostrados en las apps oficiales y a menudo leaked en capturas/videos de usuarios.
  • El SSID en modo AP coincide con el Device ID; muchos dispositivos exponen un AP abierto durante el onboarding.

Forzar accesibilidad remota

Algunos firmwares se reinician en bucle hasta que los servidores de rendezvous sean alcanzables. Si el egress está bloqueado, el dispositivo permanecerá en un ciclo de reinicios, coaccionando efectivamente a los propietarios a dejarlo accesible por Internet y expuesto al rendezvous PPPP.

Practical Exploitation Playbook (for repro/defense testing)

  1. Obtain device ID
  • From app UI or AP SSID; otherwise enumerate PREFIX+number and brute 22^5 verifier space.
  1. Establish PPPP session
  • Use a CS2 PPPP client or custom code; extract server IP lists and init keys from the app init string; attempt UDP hole punching; fall back to relay.
  1. Bypass auth
  • Skip LoginDev or ignore its result; send operational JSON directly.
  1. Exfiltrate files / geo-locate
  • Send {“cmd”:“searchWiFiList”}; then DownloadFile “/tmp/wifi_scan.txt”; submit BSSIDs to a geolocation API.
  1. Achieve RCE
  • Send a cmd > 255 bytes to trigger the stack overflow; build ROP/ret2libc or drop shellcode (no canary/DEP/ASLR).
  1. Cloud access
  • Interact with api.l040z.com endpoints using only the device ID; note 5 MiB chunking; cloud enablement controlled by /camera/signurl regardless of the app UI state.

Protocolos/Servicios relacionados

554,8554 - Pentesting RTSP

Pentesting Wifi

References

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks