32100/UDP - Pentesting PPPP (CS2) P2P Cameras

Reading time: 9 minutes

Panoramica

PPPP (a.k.a. “P2P”) è uno stack proprietario di connettività dispositivi di CS2 Network ampiamente integrato in telecamere IP low-cost e altri dispositivi IoT. Fornisce rendezvous, NAT traversal (UDP hole punching), uno stream "affidabile" a livello applicativo sopra UDP e uno schema di indirizzamento basato su ID, permettendo a un'app mobile/desktop di raggiungere dispositivi ovunque su Internet conoscendo solo l'ID del dispositivo.

Caratteristiche chiave rilevanti per gli attaccanti:

• I dispositivi si registrano a tre server di rendezvous gestiti dal vendor per prefisso ID. I client interrogano gli stessi server per trovare l'indirizzo esterno/relay del dispositivo, quindi tentano UDP hole punching. È previsto un fallback su relay.
• Il listener di default del server è raggiungibile su UDP/32100. Una probe "hello" minima è sufficiente per effettuare il fingerprinting dei server e di alcuni dispositivi.
• Esiste un blanket cipher opzionale e una modalità speciale "CRCEnc", ma sono deboli per progettazione e tipicamente disabilitate in ecosistemi popolari (es., LookCam).
• Il control plane è solitamente composto da comandi JSON sullo stream PPPP e spesso soffre di mancanza di auth e bug di sicurezza della memoria.

Formato tipico dell'ID dispositivo (famiglia LookCam): PREFIX-######-CCCCC, abbreviato nelle app (es., GHBB-000001-NRLXW → G000001NRLXW). Prefissi osservati: BHCC ("hekai"), FHBB e GHBB ("mykj").

Scoperta e enumerazione

• Esposizione su Internet: molti super-nodi PPPP rispondono a una probe su 32100/UDP. Risposte con plaintext noti e stringhe di errore le rendono facili da identificare nei capture di traffico e con scanner Internet.
• Scoperta LAN: i dispositivi spesso rispondono a una ricerca non criptata su broadcast locale. Usa lo script di Paul Marrapese per enumerare:
• https://github.com/pmarrapese/iot/tree/master/p2p/lansearch

Note:

• Le app incorporano "init strings" che contengono liste di IP server offuscate e chiavi di protocollo. Queste stringhe sono trivialmente estraibili dai client Android/iOS/Windows e spesso riutilizzate tra molte linee di prodotto.

NAT Traversal e trasporto

• I server di rendezvous apprendono la mappatura pubblica del dispositivo tramite keepalive periodici inviati dal dispositivo. I client interrogano i server per ottenere la mappatura e poi tentano flussi UDP diretti usando hole punching. Se il NAT traversal fallisce, il traffico viene inoltrato tramite host PPPP designati (relay).
• Lo "stream" applicativo implementa la propria logica ACK/retx sopra UDP; i loop di ritrasmissione sono duplicati su molte path di codice e possono saturare link con perdita.

Debole "Encryption" e recupero delle chiavi

Nello stack CS2 esistono due meccanismi inefficaci:

1. Blanket cipher (optional) – P2P_Proprietary_Encrypt

• Di solito disabilitato dagli OEM che usano LookCam.
• L'init string lato app fornisce il materiale chiave che viene ridotto a una chiave effettiva di 4 byte (~spazio 2^32).
• Known-plaintext pratico: i primi 4 byte di MSG_HELLO a UDP/32100 sono noti e valgono F1 00 00 00. Osservare una singola handshake criptata permette un rapido recupero o validazione della chiave.
• Alcuni messaggi di controllo (es., MSG_REPORT_SESSION_READY) sono sempre criptati con una chiave hardcoded nella libreria e condivisa tra le app.

2. Registration "encryption" – PPPP_CRCEnc

• Nonostante il nome, questo non è CRC. È uno keystream XOR a ripetizione fissa con un controllo di padding di 4 byte (non autenticato).
• Le reti LookCam tipicamente usano CRCEnc solo per la registrazione device → server (MSG_DEV_LGN_CRC). La maggior parte del traffico rimane in chiaro.

Recupero semplice del keystream per 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)])

Disallineamento del modello di minaccia: i materiali CS2 si concentrano sul prevenire DoS tramite registrazioni di dispositivi false, non sulla riservatezza. Questo spiega la “encryption” selettiva della registrazione mentre video/controllo restano opzionali o in chiaro. I server PPPP storici mostrano assenza di rate limiting, permettendo brute-force/abuse su larga scala.

Piano di controllo: JSON Commands and Auth Bypass

Molti firmware di telecamere PPPP scambiano messaggi JSON una volta stabilita la sessione. Esempio di “login” che il client invia:

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

Vulnerabilità comune nei dispositivi della classe LookCam:

• Firmware ignora sia il flow LoginDev sia i campi pwd per richiesta (CWE-287, CWE-306). Il dispositivo accetta comandi operativi senza validare una password.
• Sfruttamento: non inviare LoginDev o ignorarne il risultato; inviare i comandi direttamente.

Comandi utili osservati:

• searchWiFiList – invoca iwlist; lascia l'output grezzo in /tmp/wifi_scan.txt.
• DownloadFile – primitive di lettura di percorsi arbitrari senza restrizioni di path.

Flusso di lavoro per deanonimizzare la posizione tramite artefatti transitori:

1. Invia {"cmd":"searchWiFiList"}.
2. Leggi /tmp/wifi_scan.txt tramite DownloadFile.
3. Invia i BSSID MACs a una geolocation API (es. Google Geolocation API) per localizzare la camera con una precisione di decine di metri.

Memory-Safety to RCE on Embedded Firmware

Pattern tipico insicuro (pseudocodice dai handlers):

char buf[256];
char *cmd = cJSON_GetObjectItem(request, "cmd")->valuestring;
memset(buf, 0, sizeof(buf));
memcpy(buf, cmd, strlen(cmd)); // no bound check

• Scatenante: any cmd string > 255 bytes causes a stack buffer overflow (CWE-120/121).
• Protezione: nessun stack canary; DEP/NX e ASLR comunemente disabilitati in queste build.
• Impatto: straightforward single-stage shellcode o classic ROP/ret2libc sulla CPU del dispositivo (es., ARM) per compromissione completa e LAN pivoting.

See also:

Stack Overflow

Ret2lib

Abuso dello storage cloud (HTTP, Device-ID only)

Molti firmware marchiati LookCam caricano le registrazioni su api.l040z.com (apicn.l040z.com per BHCC) usando solo HTTP. Osservazioni:

• Nessun TLS nel firmware; il trasporto è cleartext HTTP.
• L'“authentication” dell'API è solo device-ID: chiunque conosca l'ID può fetchare le registrazioni.
• Chunking a 5 MiB è hardcoded.
• Abilitazione remota: all'avvio il dispositivo chiama http://api.l040z.com/camera/signurl; la risposta del server decide se iniziano gli upload. L'app mobile può mostrare cloud “disabled” anche quando gli upload avvengono. Una terza parte può purchase/enable cloud per un ID vittima e silently collect i filmati.

Si tratta di una classica trasmissione sensibile in cleartext (CWE-319) con mancante authZ lato server.

Enumerazione e indovinamento del Device-ID

• Formato ID: PREFIX-######-CCCCC e forma abbreviata dall'app (e.g., GHBB-000001-NRLXW → G000001NRLXW).
• Famiglie di prefix: BHCC (hekai servers), FHBB e GHBB (mykj servers). Ogni prefix mappa a tre rendezvous server per HA.
• Il verificatore a 5 lettere usa un alfabeto di 22 lettere maiuscole (A, I, O, Q esclusi) → 22^5 ≈ 5.15M combo per base numerica.
• Lavori precedenti hanno osservato l'assenza di rate-limiting lato server, rendendo pratico il distributed guessing. L'algoritmo del verificatore è bespoke e probabilmente guessable o ottenibile tramite reverse engineering delle app/firmware.

Fonti pratiche di ID:

• Visualizzati ovunque nelle app ufficiali e spesso leaked in screenshot/video utente.
• L'SSID in AP mode corrisponde al device ID; molti dispositivi espongono un AP aperto durante l'onboarding.

Forzare la raggiungibilità remota

Alcuni firmware si riavviano in loop finché i rendezvous server non sono raggiungibili. Se l'egress è bloccato, il dispositivo resterà in un ciclo di reboot, costringendo di fatto i proprietari a lasciarlo Internet-reachable ed esposto al rendezvous PPPP.

Playbook pratico di sfruttamento (per repro/test difensivo)

1. Ottenere il device ID

• Dall'UI dell'app o dall'SSID AP; altrimenti enumerare PREFIX+numero e brute-force lo spazio del verificatore 22^5.

2. Stabilire la sessione PPPP

• Usare un CS2 PPPP client o codice custom; estrarre liste di IP server e init keys dalla init string dell'app; tentare UDP hole punching; fallback al relay.

3. Bypassare auth

• Saltare LoginDev o ignorarne il risultato; inviare direttamente l'operational JSON.

4. Esfiltrare file / geo-localizzare

• Inviare {"cmd":"searchWiFiList"}; poi DownloadFile "/tmp/wifi_scan.txt"; inviare i BSSID a un geolocation API.

5. Ottenere RCE

• Inviare un cmd > 255 bytes per triggerare lo stack overflow; costruire ROP/ret2libc o droppare shellcode (no canary/DEP/ASLR).

6. Accesso al cloud

• Interagire con gli endpoint api.l040z.com usando solo il device ID; notare il chunking a 5 MiB; l'abilitazione del cloud è controllata da /camera/signurl indipendentemente dallo stato dell'UI dell'app.

Protocolli/Servizi correlati

554,8554 - Pentesting RTSP

Pentesting Wifi

Riferimenti

• A look at a P2P camera (LookCam app) – Almost Secure
• PPPP device discovery on LAN (Paul Marrapese)
• LookCam analysis (Warwick University, 2023)
• General PPPP analysis – Elastic Security Labs (2024)
• CS2 Network sales deck (2016) – PPPP/threat model
• Anyka hardened community firmware