32100/UDP - Pentesting PPPP (CS2) P2P カメラ

Reading time: 14 minutes

概要

PPPP（別名 “P2P”）は、CS2 Network が開発した独自のデバイス接続スタックで、低価格のIPカメラやその他のIoTデバイスに広く組み込まれています。ランデブー、NAT traversal（UDP hole punching）、UDP 上に構築されたアプリ層の「信頼できる」ストリーム、およびIDベースのアドレッシングを提供し、モバイル/デスクトップアプリがデバイスIDだけでインターネット上のどこにあるデバイスにも到達できるようにします。

攻撃者に関連する主な特徴:

• デバイスはIDプレフィックスごとにベンダー運用のランデブーサーバー3台に登録します。クライアントは同じサーバーにクエリを投げてデバイスの外部/リレーアドレスを取得し、UDP hole punching を試みます。NAT traversal に失敗した場合はリレーにフォールバックします。
• デフォルトのサーバーリスナーは UDP/32100 で到達可能です。最小限の "hello" プローブでサーバーや一部デバイスのフィンガープリントが可能です。
• オプションのブランケット暗号と特別な "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 のスクリプトを使用してください:
• https://github.com/pmarrapese/iot/tree/master/p2p/lansearch

注:

• アプリにはサーバーIPリストやプロトコルキーを難読化した "init strings" が埋め込まれており、これらは Android/iOS/Windows クライアントから容易に抽出でき、多くの製品ラインで再利用されることが多いです。

NAT Traversal and Transport

• ランデブーサーバーは、デバイスからの定期的なキープアライブでデバイスのパブリックマッピングを学習します。クライアントはサーバーにマッピングを問い合わせ、その後 hole punching による直接UDPフローを試みます。NAT traversal が失敗した場合は、指定された PPPP リレーホストがトラフィックを中継します。
• アプリケーションの「ストリーム」は UDP 上に独自の ACK/再送ロジックを実装しており、再送ループが多くのコードパスで重複しているため、損失の多いリンクでフラッドを引き起こすことがあります。

Weak “Encryption” and Key Recovery

CS2 スタックには効果の薄いメカニズムが2つ存在します:

1. ブランケット暗号（オプション） – P2P_Proprietary_Encrypt

• LookCam を使用する OEM では通常無効化されています。
• アプリ側の "init string" がキー素材を供給し、それは実効的に 4 バイトのキー（約 2^32 の空間）まで縮小されます。
• 実用的な既知平文: UDP/32100 への MSG_HELLO の最初の4バイトは既知で F1 00 00 00 です。単一の暗号化されたハンドシェイクを観測するだけで、キーの高速な回復や検証が可能です。
• 一部のコントロールメッセージ（例: MSG_REPORT_SESSION_READY）は常にライブラリにハードコードされたキーで暗号化され、アプリ間で共有されます。

2. 登録の「暗号化」 – PPPP_CRCEnc

• 名前に反して、これは CRC ではありません。4バイトのパディングチェック（認証なし）を伴う固定の繰り返し XOR キーストリームです。
• LookCam ネットワークでは通常、CRCEnc はデバイス→サーバーの登録（MSG_DEV_LGN_CRC）にのみ使用され、その他のトラフィックの多くは平文のままです。

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” され、video/control が任意または cleartext のままになる理由を説明する。過去の PPPP サーバーはレート制限を設けておらず、大規模な brute-force/abuse を可能にしている。

Control Plane: JSON Commands and Auth Bypass

多くの PPPP カメラのファームウェアは、セッション確立後に JSON メッセージを交換する。クライアントが送る例の “login”:

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

LookCamクラスのデバイスに共通する脆弱性:

• ファームウェアは LoginDev フローとリクエストごとの pwd フィールドの両方を無視します (CWE-287, CWE-306)。デバイスはパスワードを検証せずに操作コマンドを受け付けます。
• Exploitation: LoginDev を送らないかその結果を無視し、コマンドを直接送信します。

観測された有用なコマンド:

• searchWiFiList – iwlist を呼び出し、/tmp/wifi_scan.txt に生の出力を残します。
• DownloadFile – パス制限のない任意パス読み取りプリミティブ。

一時的アーティファクトを用いて位置を特定するワークフロー:

1. {"cmd":"searchWiFiList"} を送信する。
2. DownloadFile を使って /tmp/wifi_scan.txt を読む。
3. BSSID MAC をジオロケーション API (例: Google Geolocation API) に送信して、カメラを数十メートルの精度で特定する。

Memory-Safety から組み込みファームウェア上の RCE へ

典型的な安全でないパターン（handlers からの擬似コード）:

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

• トリガー: any cmd string > 255 bytes がスタックバッファオーバーフローを引き起こす (CWE-120/121)。
• 保護: no stack canary; DEP/NX と ASLR はこれらのビルドで一般的に無効化されている。
• 影響: デバイスの CPU (例: ARM) 上での single-stage shellcode または標準的な ROP/ret2libc による完全な侵害と LAN ピボットが容易。

See also:

Stack Overflow

Ret2lib

Cloud Storage Abuse (HTTP, Device-ID only)

多くの LookCam ブランドのファームウェアは録画を api.l040z.com (BHCC は apicn.l040z.com) に対して HTTP でのみアップロードする。観察点:

• ファームウェア内に TLS はなく、トランスポートは平文の HTTP。
• API の「認証」は device-ID のみ: ID を知っていれば誰でも録画を取得できる。
• 5 MiB のチャンク分割がハードコードされている。
• リモート有効化: 起動時にデバイスは http://api.l040z.com/camera/signurl を呼び出し、サーバの応答がアップロード開始を決定する。モバイルアプリは cloud が「無効」と表示していてもアップロードが行われる場合がある。第三者が被害者の ID に対して cloud を購入/有効化すると、映像を黙って収集できる。

これは典型的な平文による機密送信 (CWE-319) かつサーバ側の authZ 欠如のケースである。

Device-ID Enumeration and Guessing

• ID 形式: PREFIX-######-CCCCC とアプリ短縮形 (例: GHBB-000001-NRLXW → G000001NRLXW)。
• プレフィックスファミリ: BHCC (hekai servers)、FHBB と GHBB (mykj servers)。各プレフィックスは HA のために 3 つの rendezvous servers にマップされる。
• 5 文字の verifier は 22 文字の大文字アルファベットを使用 (A, I, O, Q を除外) → 22^5 ≈ 5.15M の組み合わせが各数値ベースに対して存在。
• 先行研究ではサーバ側のレート制限が見られず、分散推測が実用的であることが示された。verifier アルゴリズムは独自実装で、アプリ/ファームウェアのリバースで推測または取得可能であると考えられる。

実用的な ID の入手源:

• 正式アプリ上の表示やユーザのスクリーンショット/ビデオに頻繁に露出している。
• AP モードの SSID がデバイス ID と一致する; 多くのデバイスはオンボーディング時にオープンな AP を露出する。

Forcing Remote Reachability

一部のファームウェアは rendezvous servers に到達可能になるまでループで再起動を続ける。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 string から server 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 をジオロケーション API に提出。

5. Achieve RCE

• Send a cmd > 255 bytes でスタックオーバーフローを誘発; ROP/ret2libc を構築するか shellcode をドロップして RCE を達成 (no canary/DEP/ASLR)。

6. Cloud access

• device ID のみで api.l040z.com エンドポイントと対話; 5 MiB チャンク分割に注意; cloud の有効化は /camera/signurl によって制御され、アプリ UI の状態に依存しない。

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