32100/UDP - Pentesting PPPP (CS2) P2P Cameras

Reading time: 8 minutes

Огляд

PPPP (a.k.a. “P2P”) — пропрієтарний стек підключення пристроїв від CS2 Network, що широко вбудований у недорогі IP-камери та інші IoT-пристрої. Він надає rendezvous, NAT traversal (UDP hole punching), прикладний «reliable» stream поверх UDP та схему адресації на основі ID, що дозволяє мобільному/десктопному app зв’язуватися з пристроями будь-де в Інтернеті, знаючи лише device ID.

Ключові риси, важливі для атакуючих:

• Пристрої реєструються на трьох vendor-operated rendezvous servers для кожного префіксу ID. Клієнти запитують ті самі сервери, щоб дізнатися зовнішню/relay-адресу пристрою, а потім намагаються виконати UDP hole punching. Існує relay fallback.
• За замовчуванням server listener доступний по UDP/32100. Мінімальний «hello» probe достатній для fingerprint серверів і деяких пристроїв.
• Існують optional blanket cipher та спеціальний режим «CRCEnc», але вони слабкі за дизайном і зазвичай вимкнені в популярних екосистемах (наприклад, LookCam).
• Control plane зазвичай — JSON commands поверх PPPP stream і часто страждає від missing auth та memory-safety bugs.

Типовий формат device ID (сімейство LookCam): PREFIX-######-CCCCC, скорочений в apps (e.g., GHBB-000001-NRLXW → G000001NRLXW). Спостережувані префікси: BHCC ("hekai"), FHBB та GHBB ("mykj").

Discovery and Enumeration

• Internet exposure: багато PPPP super-nodes відповідають на 32100/UDP probe. Known plaintext та error-string responses роблять їх легкими для ідентифікації в traffic captures та за допомогою Internet scanners.
• LAN discovery: пристрої часто відповідають на unencrypted search на локальному broadcast. Використовуйте скрипт Paul Marrapese для enumeration:
• https://github.com/pmarrapese/iot/tree/master/p2p/lansearch

Примітки:

• Apps вбудовують «init strings», що містять обфусцовані списки IP серверів і протокольні ключі. Ці рядки тривіально витягуються з Android/iOS/Windows клієнтів і часто повторно використовуються в багатьох лінійках продуктів.

NAT Traversal and Transport

• Rendezvous servers дізнаються public mapping пристрою через періодичні keepalives від пристрою. Клієнти запитують сервери про mapping і потім намагаються встановити прямі UDP flows з використанням hole punching. Якщо NAT traversal не вдається, трафік ретранслюється призначеними PPPP relay hosts.
• Прикладний «stream» реалізує власну логіку ACK/retx поверх UDP; retransmission loops дублюються у багатьох code paths і можуть затопити lossy links.

Weak “Encryption” and Key Recovery

У стеку CS2 існують два неефективні механізми:

1. Blanket cipher (optional) – P2P_Proprietary_Encrypt

• Зазвичай вимкнений OEM-виробниками, які використовують LookCam.
• App-side «init string» постачає матеріал ключа, який зводиться до ефективного 4-байтного ключа (~2^32 простір).
• Практичний known-plaintext: перші 4 байти MSG_HELLO до UDP/32100 відомі і рівні F1 00 00 00. Спостереження одного зашифрованого handshake дозволяє швидко відновити ключ або підтвердити його.
• Деякі контрольні повідомлення (наприклад, MSG_REPORT_SESSION_READY) завжди шифруються з library-hardcoded key, що спільно використовується між apps.

2. Registration “encryption” – PPPP_CRCEnc

• Незважаючи на назву, це не CRC. Це фіксований повторюваний XOR keystream з 4-байтовою padding check (без автентифікації).
• Мережі LookCam зазвичай використовують CRCEnc лише для реєстрації device → server (MSG_DEV_LGN_CRC). Більшість іншого трафіку залишається plaintext.

Просте відновлення keystream для 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)])

Невідповідність моделі загроз: матеріали CS2 зосереджені на запобіганні DoS через фейкові реєстрації пристроїв, а не на конфіденційності. Це пояснює вибіркове “encryption” самої реєстрації, тоді як відео/керування залишаються опційними або у cleartext. Історичні PPPP сервери не мають rate limiting, що дозволяє brute-force/abuse у великому масштабі.

Контрольна площина: JSON-команди and Auth Bypass

Багато прошивок PPPP-камер обмінюються JSON-повідомленнями після встановлення сесії. Приклад “login”, який надсилає клієнт:

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

Common vulnerability in LookCam-class devices:

• Прошивка ігнорує як LoginDev flow, так і поля pwd у кожному запиті (CWE-287, CWE-306). Пристрій приймає операційні команди без перевірки pwd.
• Exploitation: не надсилати LoginDev або ігнорувати його результат; надсилати команди безпосередньо.

Useful commands observed:

• searchWiFiList – викликає iwlist; залишає необроблений вивід у /tmp/wifi_scan.txt.
• DownloadFile – примітив читання довільного шляху без обмежень.

Workflow to deanonymize location via transient artifacts:

1. Надіслати {"cmd":"searchWiFiList"}.
2. Прочитати /tmp/wifi_scan.txt via DownloadFile.
3. Надіслати BSSID MACs до geolocation API (наприклад, Google Geolocation API), щоб локалізувати камеру з точністю до десятків метрів.

Memory-Safety to RCE on Embedded Firmware

Типовий небезпечний патерн (псевдокод з handlers):

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

• Тригер: будь-який рядок cmd > 255 байт спричиняє stack buffer overflow (CWE-120/121).
• Захист: немає stack canary; DEP/NX і ASLR зазвичай вимкнені в цих збірках.
• Наслідок: можлива пряма реалізація single-stage shellcode або класичний ROP/ret2libc на CPU пристрою (наприклад, ARM) для повної компрометації і LAN pivoting.

See also:

Stack Overflow

Ret2lib

Зловживання хмарним сховищем (HTTP, Device-ID only)

Багато прошивок бренду LookCam завантажують записи на api.l040z.com (apicn.l040z.com для BHCC) виключно по HTTP. Спостереження:

• У прошивці немає TLS; транспорт — відкритий HTTP.
• API “authentication” — тільки device-ID: будь-хто, хто знає ID, може отримати записи.
• Розбивка на шматки по 5 MiB жорстко прописана.
• Віддалене увімкнення: при завантаженні пристрій звертається до http://api.l040z.com/camera/signurl; відповідь сервера вирішує, чи починаються завантаження. Мобільний додаток може показувати cloud “disabled” навіть коли завантаження відбуваються. Третя сторона може придбати/увімкнути cloud для чужого ID та таємно збирати відео.

Це класична передача чутливих даних у відкритому вигляді (cleartext sensitive transmission) (CWE-319) з відсутньою server-side authZ.

Перебір і вгадування Device-ID

• Формат ID: PREFIX-######-CCCCC та скорочена форма в додатку (наприклад, GHBB-000001-NRLXW → G000001NRLXW).
• Сімейства префіксів: BHCC (hekai servers), FHBB і GHBB (mykj servers). Кожний префікс відповідає трьом rendezvous серверам для HA.
• 5-литерний верифікатор використовує алфавіт з 22 великих літер (букви A, I, O, Q виключені) → 22^5 ≈ 5.15M комбінацій на числову основу.
• Попередні дослідження виявили відсутність server-side rate-limiting, що робить розподілене вгадування практичним. Алгоритм верифікації спеціальний і, ймовірно, піддається вгадуванню або отриманню шляхом реверсу додатків/прошивки.

Практичні джерела ID:

• Відображається у офіційних додатках і часто leaked у скриншотах/відео користувачів.
• SSID у режимі AP дорівнює device ID; багато пристроїв відкривають open AP під час onboarding.

Примусове забезпечення віддаленої доступності

Деякі прошивки перезавантажуються в циклі, доки rendezvous servers не стануть доступні. Якщо egress заблокований, пристрій залишатиметься в циклі перезавантажень, фактично змушуючи власників залишити його Internet-reachable та відкритим для PPPP rendezvous.

Практичний сценарій експлуатації (для repro/тестування захисту)

1. Отримати device ID

• З UI додатка або AP SSID; інакше перебрати PREFIX+номер і brute простір 22^5 верифікатора.

2. Встановити PPPP сесію

• Використати CS2 PPPP client або власний код; витягнути списки IP серверів та init keys з init string додатка; спробувати UDP hole punching; при невдачі перейти на relay.

3. Обійти auth

• Пропустити LoginDev або ігнорувати його результат; відправляти operational JSON напряму.

4. Екзфільтрувати файли / визначити геолокацію

• Відправити {"cmd":"searchWiFiList"}; потім DownloadFile "/tmp/wifi_scan.txt"; відправити BSSIDs до geolocation API.

5. Досягти RCE

• Відправити cmd > 255 байт, щоб викликати stack overflow; побудувати ROP/ret2libc або вкинути shellcode (немає canary/DEP/ASLR).

6. Доступ до cloud

• Взаємодіяти з endpoint'ами api.l040z.com, використовуючи лише device ID; зверніть увагу на 5 MiB chunking; увімкнення cloud контролюється /camera/signurl незалежно від стану UI додатка.

Суміжні протоколи/сервіси

554,8554 - Pentesting RTSP

Pentesting Wifi

References

• 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