mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00

Translator 89740ec067 Translated ['src/blockchain/smart-contract-security/mutation-testing-wit

2025-09-30 22:37:17 +00:00

11 KiB

Raw Blame History

32100/UDP - Pentesting PPPP (CS2) P2P Caméras

Aperçu

PPPP (a.k.a. “P2P”) est une pile propriétaire de connectivité d'appareils par CS2 Network largement intégrée dans des caméras IP bon marché et d'autres appareils IoT. Elle fournit des rendezvous, NAT traversal (UDP hole punching), un flux "fiable" au niveau applicatif sur UDP, et un schéma d'adressage basé sur l'ID, permettant à une application mobile/desktop d'atteindre des appareils n'importe où sur Internet en connaissant seulement l'ID de l'appareil.

Traits clés pertinents pour les attaquants :

Les appareils s'enregistrent auprès de trois serveurs de rendezvous opérés par le vendor par préfixe d'ID. Les clients interrogent les mêmes serveurs pour trouver l'adresse externe/relay de l'appareil, puis tentent le UDP hole punching. Un fallback par relay existe.
Le listener par défaut du serveur est joignable sur UDP/32100. Une sonde minimale "hello" suffit à fingerprint les serveurs et certains appareils.
Un cipher global optionnel et un mode spécial "CRCEnc" existent mais sont faibles par conception et sont typiquement désactivés dans les écosystèmes populaires (ex. LookCam).
Le plan de contrôle est généralement des commandes JSON sur le stream PPPP et souffre couramment d'absence d'auth et de bugs de sécurité mémoire.

Format d'ID d'appareil typique (famille LookCam) : PREFIX-######-CCCCC, raccourci dans les apps (ex. GHBB-000001-NRLXW → G000001NRLXW). Préfixes observés : BHCC ("hekai"), FHBB et GHBB ("mykj").

Découverte et énumération

Exposition Internet : de nombreux super-nœuds PPPP répondent à une sonde 32100/UDP. Des réponses en clair connues et des chaînes d'erreur en font des cibles faciles à identifier dans des captures de trafic et avec des scanners Internet.
Découverte LAN : les appareils répondent souvent à une recherche non chiffrée sur le broadcast local. Utilisez le script de Paul Marrapese pour énumérer :
https://github.com/pmarrapese/iot/tree/master/p2p/lansearch

Remarques :

Les apps embarquent des "init strings" qui contiennent des listes IP de serveurs obfusquées et des clés de protocole. Ces chaînes sont trivialement extractibles des clients Android/iOS/Windows et sont souvent réutilisées à travers de nombreuses gammes de produits.

NAT Traversal et Transport

Les serveurs de rendezvous apprennent la mapping publique de l'appareil via des keepalives périodiques de l'appareil. Les clients interrogent les serveurs pour obtenir la mapping puis tentent des flux UDP directs en utilisant le hole punching. Si la traversal NAT échoue, le trafic est relayé par des hosts relais PPPP désignés.
Le "stream" applicatif implémente sa propre logique ACK/retx au-dessus d'UDP ; les boucles de retransmission sont dupliquées sur de nombreux chemins de code et peuvent inonder des liens sujets à perte.

"Encryption" faible et récupération de clé

Deux mécanismes inefficaces existent dans la stack CS2 :

Blanket cipher (optional) – P2P_Proprietary_Encrypt

Généralement désactivé par les OEM utilisant LookCam.
L’ "init string" côté app fournit le matériau de clé qui est réduit à une clé effective de 4 octets (~espace 2^32).
Known-plaintext pratique : les 4 premiers octets de MSG_HELLO vers UDP/32100 sont connus et valent F1 00 00 00. L'observation d'une seule poignée de main chiffrée permet une récupération ou validation rapide de la clé.
Certains messages de contrôle (ex. MSG_REPORT_SESSION_READY) sont toujours chiffrés avec une clé codée en dur dans la librairie et partagée entre les apps.

Registration “encryption” – PPPP_CRCEnc

Malgré son nom, ce n'est pas un CRC. C'est un keystream XOR répétitif fixe avec une vérification de padding de 4 octets (non authentifiée).
Les réseaux LookCam utilisent typiquement CRCEnc uniquement pour l'enregistrement device → server (MSG_DEV_LGN_CRC). La plupart des autres trafics restent en clair.

Récupération simple du keystream pour 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)])

Mauvaise correspondance du modèle de menace : les documents CS2 se concentrent sur la prévention des DoS via de faux enregistrements d'appareils, pas sur la confidentialité. Cela explique le chiffrement sélectif des enregistrements tandis que la vidéo/le contrôle restent optionnels ou en clair. Les serveurs PPPP historiques n'appliquent pas de rate limiting, ce qui permet du brute-force/abuse à grande échelle.

Plan de contrôle: JSON Commands and Auth Bypass

De nombreux firmwares de caméras PPPP échangent des messages JSON une fois la session établie. Exemple “login” que le client envoie:

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

Vulnérabilité courante dans les appareils de classe LookCam :

Le firmware ignore à la fois le flux LoginDev et les champs pwd par requête (CWE-287, CWE-306). L'appareil accepte des commandes opérationnelles sans valider de mot de passe.
Exploitation : ne pas envoyer LoginDev ou ignorer son résultat ; envoyer les commandes directement.

Commandes utiles observées :

searchWiFiList – exécute iwlist ; laisse la sortie brute dans /tmp/wifi_scan.txt.
DownloadFile – primitive de lecture de chemin arbitraire sans restriction de chemin.

Workflow pour désanonymiser l'emplacement via des artefacts transitoires :

Send {"cmd":"searchWiFiList"}.
Read /tmp/wifi_scan.txt via DownloadFile.
Submit BSSID MACs to a geolocation API (e.g., Google Geolocation API) to localize the camera to tens of meters.

De la sécurité mémoire à la RCE sur le firmware embarqué

Exemple typique de pattern non sûr (pseudocode extrait des handlers):

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

Déclencheur : any cmd string > 255 bytes causes a stack buffer overflow (CWE-120/121).
Protections : pas de stack canary ; DEP/NX et ASLR souvent désactivés sur ces builds.
Impact : exécution directe de single-stage shellcode ou classique ROP/ret2libc sur le CPU de l’appareil (p.ex. ARM) pour compromission totale et pivot LAN.

Voir aussi :

{{#ref}} ../binary-exploitation/stack-overflow/README.md {{#endref}}

{{#ref}} ../binary-exploitation/rop-return-oriented-programing/ret2lib/README.md {{#endref}}

Cloud Storage Abuse (HTTP, Device-ID only)

De nombreux firmwares de marque LookCam uploadent des enregistrements vers api.l040z.com (apicn.l040z.com pour BHCC) via HTTP uniquement. Observations :

Pas de TLS dans le firmware ; transport en clair HTTP.
L’API “authentication” est uniquement device-ID : quiconque connaît l’ID peut récupérer les enregistrements.
Le découpage en chunks de 5 MiB est hardcodé.
Activation à distance : au démarrage l’appareil appelle http://api.l040z.com/camera/signurl ; la réponse du serveur décide si les uploads commencent. L’app mobile peut afficher le cloud “désactivé” même lorsque des uploads ont lieu. Un tiers peut acheter/activer le cloud pour un ID victime et collecter silencieusement les vidéos.

Il s’agit d’une transmission sensible en clair classique (CWE-319) avec authZ côté serveur manquant.

Device-ID Enumeration and Guessing

Format d’ID : PREFIX-######-CCCCC et forme raccourcie par l’app (p.ex. GHBB-000001-NRLXW → G000001NRLXW).
Familles de préfixes : BHCC (hekai servers), FHBB et GHBB (mykj servers). Chaque préfixe mappe sur trois rendezvous servers pour HA.
Le vérificateur à 5 lettres utilise un alphabet de 22 lettres majuscules (A, I, O, Q exclus) → 22^5 ≈ 5.15M combinaisons par base numérique.
Des travaux antérieurs ont observé l’absence de rate-limiting côté serveur, rendant le guessing distribué pratique. L’algorithme du verifier est propriétaire et probablement devinable ou obtenable en reverse des apps/firmwares.

Sources pratiques d’IDs :

Affichés partout dans les apps officielles et souvent leaked dans des captures d’écran/vidéos d’utilisateurs.
Le SSID en mode AP est égal au device ID ; beaucoup d’appareils exposent un AP ouvert durant l’onboarding.

Forcing Remote Reachability

Certains firmwares rebootent en boucle tant que les rendezvous servers ne sont pas atteignables. Si l’egress est bloqué, l’appareil restera en cycle de reboot, contraignant efficacement les propriétaires à le laisser Internet-reachable et exposé au PPPP rendezvous.

Practical Exploitation Playbook (for repro/defense testing)

Obtain device ID

Depuis l’UI de l’app ou l’AP SSID ; sinon énumérer PREFIX+number et bruteforcer l’espace 22^5 du verifier.

Establish PPPP session

Utiliser un client CS2 PPPP ou du code custom ; extraire les listes IP des serveurs et les init keys depuis la app init string ; tenter UDP hole punching ; fallback sur relay.

Bypass auth

Ignorer LoginDev ou son résultat ; envoyer directement le JSON opérationnel.

Exfiltrate files / geo-locate

Envoyer {"cmd":"searchWiFiList"} ; puis DownloadFile "/tmp/wifi_scan.txt" ; soumettre les BSSIDs à une API de géolocalisation.

Achieve RCE

Envoyer un cmd > 255 bytes pour déclencher le stack overflow ; construire ROP/ret2libc ou déposer du shellcode (pas de canary/DEP/ASLR).

Cloud access

Interagir avec les endpoints api.l040z.com en n’utilisant que le device ID ; noter le chunking à 5 MiB ; l’activation cloud est contrôlée par /camera/signurl indépendamment de l’état affiché dans l’app UI.

{{#ref}} 554-8554-pentesting-rtsp.md {{#endref}}

{{#ref}} ../generic-methodologies-and-resources/pentesting-wifi/README.md {{#endref}}

11 KiB Raw Blame History Unescape Escape