cam-mitm/SECURITY_PAPER.md

# Security Analysis of Cloud-Connected IoT Cameras: A Case Study on the UBIA/UBox Ecosystem

**Setec Labs Research**
**By: sssnake**
**Date: March 2026**

---

## Abstract

This paper presents a security analysis of a consumer-grade cloud-connected IP camera sold under multiple brand names (Javiscam, Funstorm, and others) that relies on the UBIA Technologies "UBox" platform and ThroughTek Kalay P2P SDK. Through passive network analysis, API reverse engineering, and mobile application decompilation, we identified ten distinct vulnerabilities ranging from plaintext credential exposure in API responses to disabled SSL certificate validation. The camera's cloud-first architecture — with zero inbound network services — creates a false sense of security while introducing systemic risks through its vendor cloud dependency. All testing was performed on equipment owned by the researcher using custom tooling developed for this analysis.

---

## 1. Introduction

The global IP camera market has seen explosive growth, with millions of low-cost WiFi cameras entering homes and businesses. Many of these devices are manufactured by a small number of Chinese ODMs and sold under dozens of brand names through Amazon, AliExpress, and similar marketplaces. Despite different branding, they often share identical hardware, firmware, and cloud infrastructure.

This presents a compounding risk: a vulnerability in one "brand" affects every device built on the same platform. This paper examines one such platform — UBIA Technologies' UBox ecosystem — and documents the security posture of a camera sold as a "Javiscam" (also marketed under the "Funstorm" brand) that uses ThroughTek's Kalay P2P SDK for cloud connectivity.

### 1.1 Scope

This research was conducted on a single camera owned by the researcher:

| Property | Value |
|----------|-------|
| Vendor Marketing Name | Javiscam |
| Alternate Brand | Funstorm |
| Model Number | 2604 |
| Product ID | 1619 |
| Firmware Version | 2604.0.29.8 |
| MAC Address OUI | 14:92:F9 (TP-Link chipset) |
| Mobile Application | UBox (cn.ubia.ubox) v1.1.360 |
| Cloud Platform | UBIA Technologies (ubianet.com) |
| P2P SDK | ThroughTek Kalay IOTC/AVAPI |
| IOTC Device UID | J7HYJJFFFXRDKBYGPVRA |

### 1.2 Methodology

The analysis was performed in four phases:

1. **Passive Network Analysis** — ARP spoofing to capture all camera traffic, identifying cloud endpoints, protocols, and communication patterns
2. **Application Reverse Engineering** — Decompilation of the Android UBox APK using jadx to extract API endpoints, authentication flows, and protocol definitions
3. **API Security Testing** — Direct interaction with the UBIA cloud API, enumeration of endpoints, and analysis of data leakage
4. **Automated Fuzzing** — Custom tooling for endpoint discovery, parameter mutation, and authentication bypass testing, integrated with AI-assisted analysis via REST API

### 1.3 Tools

All primary tooling was developed specifically for this research and is released as the "SetecSuite Camera MITM Framework":

- **ARP/DNS Spoofing** — Python raw socket implementation for MITM positioning
- **Protocol Capture** — Multi-protocol listener (HTTP, HTTPS, UDP, raw packets)
- **API Client** — Authenticated UBox cloud API interaction
- **API Fuzzer** — Endpoint discovery, parameter mutation, auth bypass testing
- **Packet Injector** — Raw frame crafting for UDP, ARP, DNS
- **REST API** — External integration interface enabling AI-assisted automated analysis

Third-party tools used: nmap (initial discovery), jadx (APK decompilation), tcpdump (packet capture validation).

---

## 2. Architecture Analysis

### 2.1 Network Architecture

The camera employs a **cloud-first architecture with zero inbound services**. All 65,535 TCP and UDP ports were found to be filtered — the device accepts no incoming connections from the local network.

All communication is outbound, initiated by the camera:

| Protocol | Port | Destination | Purpose |
|----------|------|-------------|---------|
| UDP | 10240 | Tencent Cloud (43.x.x.x) | P2P master/relay service |
| UDP | 123 | AWS EU, Alibaba | NTP time synchronization |
| TCP | 443 | portal.ubianet.com | API/portal communication |
| TCP | 443 | *.aliyuncs.com | Alibaba OSS (firmware, photos) |
| TCP | 443 | *.amazonaws.com | AWS (accelerator) |
| TCP | 20003 | UBIA push servers | Push notification service |
| TCP | 80 | Various CDNs | Connectivity checks |

### 2.2 Connectivity Checks

The camera performs HTTP connectivity checks against:
- `www.microsoft.com`
- `www.amazon.com`
- `www.apple.com`
- `www.qq.com`

The inclusion of `www.qq.com` (Tencent/QQ) confirms the firmware's Chinese origin. These checks use plaintext HTTP (port 80), not HTTPS.

### 2.3 P2P Communication

The camera uses ThroughTek's Kalay P2P platform for all video streaming and device control. The app and camera both connect to P2P master servers (`m7.ubianet.com`, `m8.ubianet.com`) which broker a direct P2P tunnel or provide relay services through Tencent Cloud infrastructure.

The P2P protocol uses UDP port 10240 with 72-byte outbound packets and 180-byte inbound packets. The IOTC UID format (`J7HYJJFFFXRDKBYGPVRA`) serves as the device's unique identifier on the P2P network.

### 2.4 Cloud Infrastructure

The following infrastructure was identified through DNS analysis and APK decompilation:

**API Servers:**
- `portal.ubianet.com` — Primary API (global)
- `api.us.ubianet.com` — US region
- `api.cn.ubianet.com` — China region
- `pay.ubianet.com` — Payment processing
- `wx.ubianet.com` — WeChat integration

**Object Storage:**
- `ubiaota.oss-cn-shenzhen.aliyuncs.com` — Firmware OTA (Alibaba OSS, Shenzhen)
- `uboxphoto-us.oss-us-west-1.aliyuncs.com` — User photos (Alibaba OSS, US West)
- `ubiaota-us-1312441409.cos.na-siliconvalley.myqcloud.com` — Tencent COS backup
- `ubiaota-cn-1312441409.cos.ap-guangzhou.myqcloud.com` — Tencent COS China

**P2P Master Servers:**
- `m7.ubianet.com`
- `m8.ubianet.com`

**SIM Management:**
- `118.178.150.203:9001`
- `api.iot400.com`

---

## 3. Vulnerability Findings

### V1: Plaintext Device Credentials in API Response

**Severity: CRITICAL**
**CVSS 3.1: 9.1 (Critical)**

**Endpoint:** `POST https://portal.ubianet.com/api/user/device_list`

The device list API response includes the camera's authentication credentials in plaintext:

```json
{
  "cam_user": "admin",
  "cam_pwd": "yyc1G::HPEv7om3O",
  "device_uid": "J7HYJJFFFXRDKBYGPVRA"
}
```

These credentials are used for IOTC P2P authentication. Any attacker who can intercept or access this API response — through a compromised account, session hijacking, or MITM — obtains full device control credentials.

**Impact:** Complete device takeover including live video/audio access, file download, configuration changes, and firmware manipulation.

**Recommendation:** Never include device credentials in API responses. Use session-based tokens with limited scope and expiration.

---

### V2: API Key Leakage in Login Response

**Severity: HIGH**
**CVSS 3.1: 7.5 (High)**

**Endpoint:** `POST https://portal.ubianet.com/api/v3/login`

The login response includes internal cloud service credentials:

```json
{
  "app_config": {
    "android_private_config": {
      "ucon": {
        "GoogleAPIKey": "AIzaSyD_oOWY67gLDTUdezW9UTlTfwTidR9itXA",
        "AMapAPIKey": "5c32ed9e0ebea43b41496713e259a895"
      }
    }
  }
}
```

Additionally, the user's avatar URL contains a pre-signed Alibaba OSS URL with embedded access credentials:

```
uboxphoto-us.oss-us-west-1.aliyuncs.com/...?x-oss-credential=LTAI5tGDU3y7P6YtDzmb1dDL...
```

**Impact:** Exposed API keys enable unauthorized use of mapping and cloud services. The OSS access key ID (`LTAI5tGDU3y7P6YtDzmb1dDL`) could be used to enumerate or access cloud storage if combined with other vulnerabilities.

**Recommendation:** Serve API keys only to authenticated clients via secure channels. Use short-lived pre-signed URLs without exposing access key IDs.

---

### V3: Weak Password Hashing (HMAC-SHA1 with Empty Key)

**Severity: MEDIUM**
**CVSS 3.1: 6.5 (Medium)**

**Source:** `LoginViewModel.java:276`

```java
loginJsonBean.setPassword(
  new HttpClient().get_replace_str(
    new String(Base64.encode(hmac_sha1.getHmacSHA1(str2, "")))
  )
);
```

User passwords are hashed using HMAC-SHA1 with an **empty string as the key**, then Base64 encoded with character substitutions (`+` -> `-`, `/` -> `_`, `=` -> `,`). HMAC-SHA1 with an empty key is functionally equivalent to unsalted SHA1 hashing.

**Impact:** User passwords can be reversed via rainbow tables or brute force. No per-user salt means identical passwords produce identical hashes across all accounts.

**Recommendation:** Use bcrypt, scrypt, or Argon2 with per-user salts and appropriate work factors.

---

### V4: SSL Certificate Validation Disabled

**Severity: HIGH**
**CVSS 3.1: 7.4 (High)**

**Source:** `NewApiHttpClient.java:1053`

```java
MySSLSocketFactory mySSLSocketFactory = new MySSLSocketFactory(keyStore);
mySSLSocketFactory.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
```

The mobile application accepts **any SSL certificate** without validation. This enables trivial MITM attacks against all API communications, including the login flow (exposing credentials) and device list (exposing device access tokens).

**Impact:** An attacker on the same network can intercept all cloud API traffic, steal authentication tokens, and obtain device credentials (V1) by presenting a self-signed certificate.

**Recommendation:** Implement proper certificate validation. Consider certificate pinning for critical API endpoints.

---

### V5: ThroughTek Kalay P2P SDK (Known Vulnerabilities)

**Severity: CRITICAL**
**CVSS 3.1: 9.6 (Critical)**

The camera uses ThroughTek's Kalay IOTC/AVAPI SDK for P2P communication. This SDK has multiple disclosed critical vulnerabilities:

| CVE | Description | CVSS |
|-----|-------------|------|
| CVE-2021-28372 | Improper access control, remote camera/audio access | 9.6 |
| CVE-2023-6321 | OS command injection (root access) | 9.8 |
| CVE-2023-6322 | Stack-based buffer overflow | 7.2 |
| CVE-2023-6323 | Insufficient verification (AuthKey leak) | 4.3 |
| CVE-2023-6324 | Insufficient entropy in DTLS setup | 5.9 |

CVE-2023-6323 and CVE-2023-6324 can be chained with CVE-2023-6321 to achieve remote root access from the local network (Bitdefender Labs, 2024).

The SDK version in use was not definitively determined during this analysis. ThroughTek patched affected SDK versions by April 2024, but the firmware version analyzed (2604.0.29.8) shows no evidence of recent SDK updates.

**Impact:** Depending on SDK version, an attacker could remotely access camera feeds, audio, and execute arbitrary commands as root.

**Recommendation:** Update to the latest patched ThroughTek SDK. Implement SDK version checking in firmware update flows.

---

### V6: Firmware Updates via HTTP

**Severity: HIGH**
**CVSS 3.1: 8.1 (High)**

Network captures show the camera initiating HTTP (not HTTPS) connections to CDN endpoints (Akamai, Tencent Cloud) on port 80. The firmware update mechanism sends the download URL to the camera via IOTC command 4631:

```java
// AdvancedSettings.java
UpdateReq.setFile_url(resultBase.getData().getResult().getHost().getFilename().getBytes());
```

If the firmware URL uses HTTP, the download is unencrypted and subject to MITM replacement.

**Impact:** An attacker in a MITM position can intercept firmware download requests and serve malicious firmware, achieving persistent device compromise.

**Recommendation:** Use HTTPS exclusively for firmware downloads. Implement cryptographic signature verification of firmware images before flashing.

---

### V7: IOTC Command Set Enables Full Device Control

**Severity: HIGH**
**CVSS 3.1: 8.0 (High)**

Decompilation of the UBox APK revealed the complete IOTC command set (defined in `AVIOCTRLDEFs.java`). With valid credentials (obtainable via V1), an attacker can:

| Command ID | Function |
|------------|----------|
| 768/769 | Start/stop live audio |
| 816/817 | Get device info |
| 896/897 | Format SD card |
| 4631/4632 | Push firmware update |
| 4864/4865 | List files |
| 4866/4867 | Download files |
| 4868/4869 | Upload files |
| 4874/4875 | Delete files |
| 8482/8483 | Capture picture remotely |
| 241/242 | Set device UID |

Command 241 (`IOTYPE_UBIA_SET_UID_REQ`) is particularly dangerous — it allows changing the device's P2P identifier, potentially hijacking it from the legitimate owner.

**Impact:** Full device takeover, data exfiltration, evidence destruction (SD card format), and device identity theft.

**Recommendation:** Implement command-level access control. Critical commands (firmware update, UID change, format) should require additional authentication or user confirmation via a separate channel.

---

### V8: Cloud Infrastructure Enumeration

**Severity: INFORMATIONAL**
**CVSS 3.1: N/A**

The complete cloud infrastructure is discoverable through APK decompilation and DNS analysis. The firmware OTA bucket (`ubiaota.oss-cn-shenzhen.aliyuncs.com`) was confirmed to exist and contain firmware files, though access is restricted to signed URLs.

This level of infrastructure visibility, combined with the leaked OSS access key ID (V2), could facilitate further attacks against the cloud backend.

---

### V9: No Local Network Services

**Severity: INFORMATIONAL (Architectural Observation)**

The camera exposes zero inbound ports. While this prevents traditional network-based attacks (port scanning, brute force), it creates complete dependency on the vendor's cloud infrastructure. If the cloud service is compromised, discontinued, or suffers an outage, the device becomes non-functional and there is no local fallback.

This also means the device owner has no local control mechanism — all interaction must route through vendor servers in China, raising privacy concerns for users outside that jurisdiction.

---

### V10: Multi-Brand Obfuscation

**Severity: INFORMATIONAL**

The same hardware/firmware/cloud platform is sold under multiple brand names:

- Javiscam
- Funstorm
- (likely others sharing UBIA/UBox platform with product IDs in the 1600+ range)

The TP-Link MAC OUI (14:92:F9) further obscures the actual manufacturer. Users cannot easily determine that their "Javiscam" and a neighbor's "Funstorm" share identical firmware, cloud infrastructure, and vulnerability surface.

---

### V11: Improper Use of HTTP Status Codes for Authentication

**Severity: MEDIUM**
**CVSS 3.1: 5.3 (Medium)**

**All Endpoints**

The API returns HTTP 200 for all requests regardless of authentication status. Authentication failures are communicated only through the JSON response body (`{"code": 10004, "msg": "token不能为空"}`). The API never returns HTTP 401 or 403.

This was discovered during automated fuzzing: every endpoint returned HTTP 200 with any token, no token, invalid tokens, and SQL injection payloads in the token field. Manual verification confirmed that the application-level `code` field correctly rejects unauthenticated requests (code 10004), but the HTTP transport layer provides no indication of failure.

**Impact:** 
- Standard security tooling (WAFs, API gateways, SIEM, monitoring dashboards) that relies on HTTP status codes will not detect or alert on authentication failures
- Rate limiting rules based on 401/403 response codes will never trigger
- API monitoring cannot distinguish between successful and failed auth attempts from HTTP logs alone
- Automated scanners and vulnerability tools may report false positives (as observed during this assessment)

**Recommendation:** Return HTTP 401 for authentication failures and HTTP 403 for authorization failures, in addition to the application-level error codes. This provides defense-in-depth and enables standard security infrastructure to function correctly.

---

### V12: Unauthenticated Firmware Version Check

**Severity: MEDIUM**
**CVSS 3.1: 5.3 (Medium)**

**Endpoint:** `POST https://portal.ubianet.com/api/user/check_version`

Automated fuzzing with application-level response code verification confirmed that `user/check_version` returns `{"code": 0, "msg": "success"}` without any authentication token. This was the only user-scoped endpoint (out of 27 discovered) that returned a successful application-level response without credentials.

While the endpoint returned empty data in our tests (the correct internal parameters were not determined), the lack of authentication means an attacker could potentially:
- Enumerate device firmware versions if the correct parameter format is discovered
- Obtain firmware download URLs for specific device models
- Determine which devices are running outdated/vulnerable firmware

Additionally, several PTZ snapshot endpoints (`user/del_ptz_snap`, `user/confirm_ptz_snap`, `user/put_ptz_snap`) returned `code: 0` with authenticated requests using empty parameters — suggesting these operations may execute without requiring valid target parameters.

**Recommendation:** Enforce authentication on all endpoints consistently. Validate that required parameters are present before processing requests.

---

### V13: Endpoint Enumeration via Consistent Error Responses

**Severity: LOW**
**CVSS 3.1: 3.7 (Low)**

Automated endpoint fuzzing revealed that the API returns distinguishable responses for existing vs. non-existing endpoints: existing endpoints return HTTP 200 with application-specific error codes (e.g., `{"code": 10001, "msg": "invalid params"}`), while non-existing endpoints return HTTP 404. This allows an attacker to enumerate all valid API endpoints without documentation.

27 active endpoints were confirmed through this method, including undocumented ones not referenced in the mobile application's current version.

**Recommendation:** Return consistent error responses for both invalid endpoints and valid endpoints with bad parameters. Consider rate limiting API requests to slow enumeration.

---

## 4. Attack Scenarios

### 4.1 Local Network Attacker

1. Attacker joins the same WiFi network as the camera
2. ARP spoof to MITM the camera's traffic
3. DNS spoof `portal.ubianet.com` to attacker's server
4. Due to disabled SSL validation (V4), the camera connects to the fake server
5. Attacker captures IOTC credentials from the handshake
6. Using those credentials, attacker connects to camera via P2P for live video/audio

### 4.2 Cloud API Attacker

1. Attacker compromises a UBox user account (weak password hashing, V3)
2. Calls `user/device_list` to obtain camera credentials in plaintext (V1)
3. Connects to camera via ThroughTek P2P using leaked `cam_user`/`cam_pwd`
4. Full device access: live video, audio, file access, firmware push

### 4.3 Firmware Supply Chain Attack

1. Attacker performs MITM on camera's network
2. Camera checks for firmware update via HTTP (V6)
3. Attacker intercepts the firmware URL and serves malicious firmware
4. Camera flashes the malicious firmware (no signature verification)
5. Attacker achieves persistent root access

---

## 5. Disclosure

This research was conducted on hardware owned by the researcher for educational purposes. No unauthorized access to third-party devices or accounts was performed.

Findings are being documented for coordinated disclosure to:
- UBIA Technologies Co. (vendor)
- ThroughTek Co., Ltd. (P2P SDK vendor)
- CISA (for CVE coordination if applicable)

---

## 6. Conclusion

The UBIA/UBox camera ecosystem demonstrates a pattern common across low-cost IoT devices: a polished user experience masking fundamental security failures. The cloud-first architecture with no inbound ports creates an illusion of security, while the cloud API freely distributes device credentials in plaintext. Disabled SSL validation makes MITM attacks trivial. The use of a P2P SDK with known critical vulnerabilities compounds the risk.

The multi-brand sales strategy means these vulnerabilities affect an unknown — but likely large — number of devices across brands that consumers cannot easily correlate.

The most impactful finding is V1: the cloud API returns camera admin credentials (`cam_user`/`cam_pwd`) in every device list response. This single design decision means that any cloud-side breach, account compromise, or API interception immediately yields full access credentials for every camera on the account.

For consumers: these cameras should not be used in any context where privacy is critical. Network isolation (dedicated VLAN with no internet access) would mitigate cloud-based attacks but render the camera non-functional due to its cloud dependency.

For manufacturers: the recommendations in each vulnerability section should be implemented. The highest priority items are removing credentials from API responses (V1), enabling SSL certificate validation (V4), and updating the ThroughTek SDK to the latest patched version (V5).

---

## 7. References

1. Bitdefender Labs. "Notes on ThroughTek Kalay Vulnerabilities and Their Impact on the IoT Ecosystem." May 2024.
2. CISA. "ThroughTek Kalay P2P SDK." Advisory ICSA-21-229-01. August 2021.
3. Unit 42, Palo Alto Networks. "CVE-2021-28372: How a Vulnerability in Third-Party Technology Is Leaving Many IP Cameras Vulnerable." 2021.
4. Nozomi Networks. "New IoT Security Risk: ThroughTek P2P Supply Chain Vulnerability." 2021.
5. ThroughTek. "About ThroughTek's Kalay Platform Security Mechanism." 2024.
6. OWASP. "IoT Security Verification Standard." 2024.

---

## Appendix A: Network Capture Summary

| Source | Destination | Protocol | Port | Description |
|--------|-------------|----------|------|-------------|
| Camera | Tencent Cloud (6 IPs) | UDP | 10240 | P2P relay |
| Camera | AWS Frankfurt | UDP | 123 | NTP |
| Camera | Alibaba Cloud | UDP | 123 | NTP |
| Camera | Akamai CDN | TCP | 80 | Connectivity check |
| Camera | Tencent Cloud | TCP | 80 | Connectivity check |
| Camera | Router (DNS) | UDP | 53 | DNS queries |
| Camera | 10.0.0.27 | ARP | - | Phone (ubox app) |
| Camera | 10.0.0.243 | ARP | - | WireGuard host |

## Appendix B: IOTC Command Reference (Partial)

Extracted from `AVIOCTRLDEFs.java`:

| ID | Name | Direction |
|----|------|-----------|
| 241 | SET_UID_REQ | App -> Camera |
| 768 | AUDIOSTART | App -> Camera |
| 769 | AUDIOSTOP | App -> Camera |
| 816 | DEVINFO_REQ | App -> Camera |
| 896 | FORMATEXTSTORAGE_REQ | App -> Camera |
| 4629 | FIRMWARE_UPDATE_CHECK_REQ | App -> Camera |
| 4631 | FIRMWARE_UPDATE_REQ | App -> Camera |
| 4864 | FILE_LIST_REQ | App -> Camera |
| 4866 | FILE_DOWNLOAD_REQ | App -> Camera |
| 4868 | FILE_UPLOAD_REQ | App -> Camera |
| 4874 | FILE_DELETE_REQ | App -> Camera |
| 8482 | CAPTURE_PICTURE_REQ | App -> Camera |

## Appendix C: API Endpoint Map

Discovered via APK decompilation:

| Endpoint | Auth | Method | Purpose |
|----------|------|--------|---------|
| `/api/v3/login` | No | POST | Authentication |
| `/api/user/device_list` | Yes | POST | List devices + creds |
| `/api/v2/user/device_list` | Yes | POST | Device list v2 |
| `/api/user/families` | Yes | POST | Account groups |
| `/api/user/cloud_list` | Yes | POST | Cloud recordings |
| `/api/user/event_calendar` | Yes | POST | Event history |
| `/api/user/get_cloud_video_url` | Yes | POST | Video URLs |
| `/api/user/qry/device/device_services` | Yes | POST | Service status |
| `/api/user/qry/device/check_version/v3` | Yes | POST | Firmware check |
| `/api/user/check_version` | Yes | POST | Version check (legacy) |
| `/api/temp_token` | No | POST | Temporary token |
| `/api/reset_pwd` | Yes | POST | Password reset |
| `/api/send_code` | No | POST | Verification code |

---

*This document is the intellectual property of Setec Labs. Distribution is authorized for the purpose of improving IoT security through responsible disclosure and education.*