32100/UDP - Pentesting PPPP (CS2) P2P 카메라

Reading time: 8 minutes

개요

PPPP (a.k.a. “P2P”)는 CS2 Network가 만든 독점 장치 연결 스택으로, 저가형 IP 카메라 및 기타 IoT 장치에 널리 내장되어 있습니다. 이 스택은 rendezvous, NAT traversal (UDP hole punching), UDP 위의 애플리케이션 계층 “신뢰성 있는” 스트림, ID 기반 주소 지정 체계를 제공하여 모바일/데스크탑 앱이 장치 ID만 알면 인터넷 어디에서나 장치에 접속할 수 있게 합니다.

공격자 관점의 주요 특성:

• 장치는 ID 접두사별로 공급업체가 운영하는 세 개의 rendezvous 서버에 등록합니다. 클라이언트는 동일한 서버에 질의하여 장치의 외부/릴레이 주소를 찾고 UDP hole punching을 시도합니다. 릴레이 폴백이 존재합니다.
• 기본 서버 리스너는 UDP/32100으로 접근 가능합니다. 최소한의 “hello” 프로브만으로 서버와 일부 장치를 지문화할 수 있습니다.
• 선택적 blanket cipher와 특수한 “CRCEnc” 모드가 존재하지만 설계상 약하며 인기 있는 생태계(예: LookCam)에서는 일반적으로 비활성화되어 있습니다.
• 컨트롤 플레인은 보통 PPPP 스트림 위의 JSON 명령이며, 인증 누락과 메모리 안전성 버그가 흔히 존재합니다.

일반적인 장치 ID 형식(LookCam 계열): PREFIX-######-CCCCC, 앱에서는 축약되어 표시됩니다(예: GHBB-000001-NRLXW → G000001NRLXW). 관찰된 접두사: BHCC ("hekai"), FHBB 및 GHBB ("mykj").

Discovery and Enumeration

• Internet exposure: 많은 PPPP 슈퍼노드가 32100/UDP 프로브에 응답합니다. 알려진 평문 및 에러 문자열 응답으로 트래픽 캡처나 인터넷 스캐너에서 쉽게 식별됩니다.
• LAN discovery: 장치는 종종 로컬 브로드캐스트의 암호화되지 않은 검색에 응답합니다. 열거하려면 Paul Marrapese’s script를 사용하세요:
• https://github.com/pmarrapese/iot/tree/master/p2p/lansearch

참고:

• 앱에는 난독화된 서버 IP 목록과 프로토콜 키를 포함한 “init strings”가 내장되어 있습니다. 이 문자열들은 Android/iOS/Windows 클라이언트에서 쉽게 추출되며 종종 많은 제품 라인에서 재사용됩니다.

NAT Traversal and Transport

• Rendezvous 서버는 장치의 주기적 keepalive로부터 장치의 공용 매핑을 학습합니다. 클라이언트는 매핑을 위해 서버에 질의한 뒤 hole punching을 사용해 직접 UDP 플로우를 시도합니다. NAT traversal이 실패하면 지정된 PPPP 릴레이 호스트가 트래픽을 중계합니다.
• 애플리케이션 “스트림”은 UDP 위에 자체 ACK/retx 로직을 구현합니다; 재전송 루프가 여러 코드 경로에 중복되어 손실이 심한 링크를 플러딩할 수 있습니다.

약한 “암호화” 및 키 복구

CS2 스택에는 비효율적인 두 가지 메커니즘이 존재합니다:

1. Blanket cipher (optional) – P2P_Proprietary_Encrypt

• LookCam을 사용하는 OEM에서는 보통 비활성화되어 있습니다.
• 앱측 “init string”이 키 재료를 제공하며, 이는 유효한 4바이트 키(~2^32 공간)로 축소됩니다.
• 실용적인 알려진 평문: UDP/32100으로 보내는 MSG_HELLO의 처음 4바이트는 F1 00 00 00로 알려져 있습니다. 단일 암호화 핸드셰이크를 관찰하면 빠른 키 복구나 검증이 가능합니다.
• 일부 제어 메시지(예: MSG_REPORT_SESSION_READY)는 앱 전반에 공유되는 라이브러리 하드코딩 키로 항상 암호화됩니다.

2. Registration “encryption” – PPPP_CRCEnc

• 이름과 달리 CRC가 아닙니다. 4바이트 패딩 체크(인증되지 않음)가 있는 고정 반복 XOR 키스트림입니다.
• LookCam 네트워크는 일반적으로 장치 → 서버 등록(MSG_DEV_LGN_CRC)에 대해서만 CRCEnc를 사용합니다. 나머지 대부분의 트래픽은 평문으로 유지됩니다.

Simple keystream recovery for 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 자료는 기밀성(confidentiality)보다는 가짜 디바이스 등록을 통한 DoS 방지에 초점을 맞춘다. 이것이 등록(registration)만 선택적으로 “encryption”되고 비디오/컨트롤은 선택적이거나 cleartext로 남아 있는 이유를 설명한다. 과거 PPPP 서버들은 rate limiting이 없어 대규모 brute-force/abuse가 가능했다.

Control Plane: JSON Commands and Auth Bypass

많은 PPPP 카메라 펌웨어는 세션이 수립되면 JSON 메시지를 주고받는다. 예: 클라이언트가 보내는 “login”:

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

Common vulnerability in LookCam-class devices:

• 펌웨어가 LoginDev 흐름과 요청별 pwd 필드를 모두 무시함 (CWE-287, CWE-306). 장치는 비밀번호를 검증하지 않고 운영 명령을 수락함.
• Exploitation: LoginDev를 보내지 않거나 그 결과를 무시하고 명령을 직접 전송.

Useful commands observed:

• searchWiFiList – iwlist를 호출함; 원시 출력은 /tmp/wifi_scan.txt에 남음.
• DownloadFile – 경로 제한 없이 임의 경로 읽기 primitive.

Workflow to deanonymize location via transient artifacts:

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

Memory-Safety to RCE on Embedded Firmware

Typical unsafe pattern (pseudocode from handlers):

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

• Trigger: any cmd string > 255 bytes causes a 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

Cloud Storage Abuse (HTTP, Device-ID only)

많은 LookCam 브랜드 펌웨어가 녹화물을 api.l040z.com (BHCC의 경우 apicn.l040z.com)으로 HTTP만 사용해 업로드합니다. 관찰된 점:

• 펌웨어에 TLS 없음; 전송은 평문 HTTP.
• API "authentication"은 device-ID만 사용: ID를 알고 있으면 녹화물을 가져올 수 있음.
• 5 MiB 단위 청크가 하드코딩되어 있음.
• 원격 활성화: 부팅 시 장치는 http://api.l040z.com/camera/signurl 를 호출하고, 서버 응답이 업로드 시작 여부를 결정함. 모바일 앱은 업로드가 발생해도 cloud “disabled”로 표시될 수 있음. 제3자가 피해자 ID에 대해 cloud를 구매/활성화하면 무단으로 영상 수집이 가능함.

이는 classic cleartext sensitive transmission (CWE-319)이며 서버 측 authZ 부재가 문제입니다.

Device-ID Enumeration and Guessing

• ID 형식: PREFIX-######-CCCCC 및 앱 단축형 (예: GHBB-000001-NRLXW → G000001NRLXW).
• Prefix 계열: BHCC (hekai servers), FHBB 및 GHBB (mykj servers). 각 prefix는 HA용으로 세 개의 rendezvous 서버에 매핑됨.
• 5자 검사자(verifier)는 22개의 대문자 알파벳을 사용 (A, I, O, Q 제외) → 22^5 ≈ 5.15M 조합/숫자 기반.
• 이전 연구에서 서버 측 rate-limiting이 없는 것으로 관찰되어 분산 추측이 실용적임. verifier 알고리즘은 맞춤형이며 앱/펌웨어 리버싱으로 추측하거나 얻을 가능성이 높음.

실무적 ID 출처:

• 공식 앱 전반에 표시되며 사용자 스크린샷/비디오에서 자주 leaked.
• AP 모드 SSID가 device ID와 동일; 많은 장치가 온보딩 중에 오픈 AP를 노출함.

Forcing Remote Reachability

일부 펌웨어는 rendezvous 서버에 도달할 수 있을 때까지 재부팅 루프에 들어갑니다. egress가 차단되면 장치는 재부팅 사이클에 남아 소유자가 장치를 인터넷에 연결하게 강제하고 PPPP rendezvous에 노출되게 됩니다.

Practical Exploitation Playbook (for repro/defense testing)

1. Obtain device ID

• 앱 UI 또는 AP SSID에서; 그렇지 않으면 PREFIX+number를 열거하고 22^5 verifier 공간을 브루트포스.

2. Establish PPPP session

• CS2 PPPP client 또는 커스텀 코드 사용; 앱 init 문자열에서 서버 IP 목록과 init keys를 추출; UDP hole punching 시도; 실패하면 relay로 폴백.

3. Bypass auth

• LoginDev를 건너뛰거나 결과를 무시; 운영용 JSON을 직접 전송.

4. Exfiltrate files / geo-locate

• Send {"cmd":"searchWiFiList"}; 그런 다음 DownloadFile "/tmp/wifi_scan.txt"; BSSIDs를 geolocation API에 제출.

5. Achieve RCE

• cmd > 255 bytes를 보내 스택 오버플로우를 유발; ROP/ret2libc를 구성하거나 shellcode를 주입(스택 canary/DEP/ASLR 없음).

6. Cloud access

• device ID만으로 api.l040z.com 엔드포인트와 상호작용; 5 MiB 청킹 유의; cloud 활성화는 앱 UI 상태와 무관하게 /camera/signurl로 제어됨.

Related Protocols/Services

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